应安装Protocol Buffer（作者xwmx或bennettp123）插件，它更新勤、proto3兼容好，能正确高亮message、enum、repeated及syntax = "proto3";；安装后须重启Sublime并执行“Open all with current extension as…”全局绑定.proto扩展名，否则仍显示Plain Text。
装哪个插件才真正生效
想让Sublime Text读懂你的.proto文件，第一步就是找个靠谱的语法高亮插件。这里有个小坑：名字相似的插件，效果可能天差地别。
目前来看，Protocol Buffer这个插件（作者是xwmx或bennettp123）是相对稳妥的选择。它更新比较勤快，对proto3的兼容性也做得不错，像message、enum、repeated这些关键字，以及声明syntax = "proto3";都能被正确识别并高亮。相比之下，一些名字里带Google Protocol Buffers或者Syntax字样的老插件，很多已经年久失修，连map这种基础结构都未必能处理好。
插件安装成功后，务必重启一次Sublime Text。否则，你新建一个.proto文件，右下角可能依然显示为Plain Text。重启之后，才能看到高亮效果初步显现。
为什么 .proto 文件还是没高亮
如果重启后打开.proto文件，依然是一片“素颜”，那问题很可能出在“绑定”这一步。安装插件只是给它上了户口，还得告诉Sublime：“以后所有.proto文件都归这个插件管”。
具体操作分两步走：
- 首先，在当前打开的.proto文件右下角，点击显示的语言模式（比如
Plain Text），在弹出的列表里选择Protocol Buffer。但这只对当前文件生效。 - 关键的一步来了：再次点击右下角的语言模式，这次选择菜单里的
Open all with current extension as…，然后依然选中Protocol Buffer。这个操作才是全局绑定，意味着之后所有.proto文件都会默认使用这个语法高亮方案。
如果操作无误还是没效果，可以检查一下插件的安装路径。通过PackageResourceViewer: Open Resource这类工具看看，插件是否完整解压到了Packages/Protocol Buffer/目录下，而不是卡在了下载缓存里，或者被误装到了Packages/User/目录。
假如连message、package这样的核心关键字都没颜色，那可能是插件本身的语法定义文件损坏了。这种情况下，重装插件或者尝试另一个作者的版本，往往比反复调试更省时间。
proto3 中 optional 被高亮了，正常吗
这是正常现象，不必担心。在proto3语法中，optional关键字确实已经被废弃了，但很多语法插件（包括前面推荐的xwmx版本）为了保持对proto2文件的兼容，仍然把它保留在了关键字列表里。所以，你在proto3文件里写optional，它依然会着色。
这纯粹是编辑器层面的展示行为，并不会影响实际的编译。当你用protoc编译器去处理这个文件时，该报的错它一个都不会少。因此，完全没必要去手动修改插件的语法规则来移除optional的高亮，原因有三：
- 下次插件一更新，你的修改就被覆盖了。
- proto2文件里
optional是合法关键字，移除高亮会误伤。 - 高亮归高亮，它和
protoc --python_out=.这类代码生成命令是两套互不干扰的体系。
格式化 .proto 文件不能只靠高亮
语法高亮解决了“看得清”的问题，但在实际团队协作中，我们往往还需要解决“写得齐”的问题——比如缩进混乱、字段命名风格不统一。这时候，就需要专门的格式化工具上场了。
prototool是一个功能强大的选择，它不仅能格式化，还能进行Lint检查和生成代码。安装之后（例如通过go install），在项目根目录创建一个prototool.yaml配置文件，加入类似format: { transform: snake_case }的规则，它就能在格式化时自动将字段名转换为下划线风格。
更进一步，你可以在Sublime里配置一个Build System，将格式化命令集成进来：
- 新建一个文件，输入：
{ "cmd": ["prototool", "format", "$file"] } - 保存为
ProtobufFormat.sublime-build，放到你的User配置目录下。
之后，编辑.proto文件时按Ctrl+B，就能一键完成格式化。当然，也有人尝试用clang-format并借用C++规则来格式化Protobuf，但这对于map这类嵌套的尖括号支持并不稳定，有时反而会把格式弄乱，所以并不推荐作为首选。
