sublime中需通过protobuf插件+protoc/buf工具链实现.proto文件处理：安装protocol buffer插件（作者xwmx或bennettp123）确保语法高亮，配置build system调用protoc生成多语言代码或buf format格式化，且必须正确设置path、selector、working_dir及proto_path等参数。
protoc 不是 Sublime 插件，它是一个独立的命令行编译器；Sublime 本身无法“安装 protoc 插件”，只能通过构建系统（Build System）调用已安装的 protoc 可执行文件生成代码。想在 Sublime 里一键生成 .pb.go 或 _pb2.py，关键不是装错名字的插件，而是配对路径、语法识别和构建参数。
Protobuf 语法高亮必须装对插件，名字和路径一个都不能错
Sublime 默认完全不识别 .proto 文件，打开就是 Plain Text。生效的前提只有三个：Protocol Buffer（作者 xwmx 或 bennettp123）必须装进 Packages/Protocol Buffer/ 目录；.proto 扩展名要全局绑定到该语法；Sublime 必须重启或手动触发绑定。
- 别搜
Google Protocol Buffers或带Syntax字样的包——它们大多停更多年，不支持map<string int32></string>、optional已废弃等 proto3 新特性 - 装完后右下角点击当前语法名（如
Plain Text），选Protocol Buffer是临时切换；再点一次 →Open all with current extension as…→ 选Protocol Buffer，才算真正全局绑定 - 用
PackageResourceViewer: Open Resource确认插件是否真解压到了正确路径，而不是卡在下载中途或被防病毒软件拦截
Build System 调用 protoc 的核心是路径 + 参数 + 作用域
Sublime 的构建系统不会自动找 protoc，也不会猜你要生成什么语言。它只负责拼接命令并执行，所以 "cmd" 数组里的每一项都得写实、写准。
-
"cmd"中的protoc必须是可执行文件名（如"protoc"），不能写成"./protoc"或带空格的路径；若系统 PATH 找不到，得用绝对路径，比如"/usr/local/bin/protoc" -
"--proto_path=."是必须项，否则import "common.proto"会报错；多级依赖时，得拆成多个-I参数，例如"-I", "third_party/googleapis", "-I", "proto/common" -
"selector": "source.protobuf"很关键——它让 Ctrl+B 只在.proto文件里生效；漏掉这行，构建系统可能根本不会出现在菜单里 - Go 用户注意：
--go_out=paths=source_relative:./gen中的paths=source_relative必须显式写出，否则生成的包路径会错乱
常见失败现象和对应检查点
按下 Ctrl+B 后没反应、报错消失、生成空文件、字段类型不高亮……这些都不是随机问题，基本都能归因到几个固定环节。
- 终端能跑通
protoc --python_out=. user.proto，但 Sublime 构建失败 → 检查"working_dir": "${file_path}"是否缺失，或${file_path}展开后含中文/空格（macOS 尤其敏感） - 生成了
user_pb2.py，但 Python 导入时报ModuleNotFoundError→ 不是 Sublime 问题，是protoc输出路径和项目结构不匹配，比如没加--python_out=.而写了--python_out=./out -
google.protobuf.Timestamp类型不被高亮 → 这是正常现象，插件只高亮基础关键字和语法结构，不解析导入的外部定义；不影响编译和使用 - 构建成功但没生成
_grpc.pb.go→ 检查是否漏了--go-grpc_out参数，以及protoc-gen-go-grpc是否在 PATH 中且版本兼容（v24+ 需搭配google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest）
.proto 语法正确性，也不解析 import 路径有效性。它只是 shell wrapper。哪怕 import 写错了、字段名重复了、syntax = "proto3" 拼错成 proto3，构建也会“成功”——直到你运行生成的代码才暴露问题。所以高亮 + 构建只是第一步，后续还得靠 protoc --check_syntax 或语言服务器做静态检查。
