需要自定义protobuf插件是因为protoc-gen-go仅生成标准结构体和序列化逻辑，无法满足crud方法生成、gorm/validate标签注入、http handler代码生成或内部rpc协议适配等定制需求；必须实现接收codegeneratorrequest并输出codegeneratorresponse的可执行程序，且命名须为protoc-gen-*前缀，通过--plugin显式调用。
为什么需要自己写 Protobuf 插件而不是用 protoc-gen-go
因为 protoc-gen-go 只生成标准 Go 结构体和序列化逻辑，没法满足定制需求：比如给每个 message 自动生成 CRUD 方法、注入特定 tag（如 gorm 或 validate）、生成 HTTP handler 框架代码，或者适配内部 RPC 协议格式。官方插件不支持这些，就得自己写插件——本质是实现一个接收 CodeGeneratorRequest、输出 CodeGeneratorResponse 的可执行程序。
如何让 protoc 正确调用你的 Go 插件
protoc 不认 Go 二进制的“名字”，只看 --plugin 参数后缀。比如你编译出的插件叫 protoc-gen-mycustom，必须以 protoc-gen- 开头，且 protoc 会自动在 PATH 中查找它。运行时命令得写成：
protoc --mycustom_out=. --plugin=protoc-gen-mycustom=./protoc-gen-mycustom *.proto
常见错误：
-
protoc-gen-mycustom没加可执行权限（Linux/macOS 下chmod +x） - PATH 里没包含插件所在目录，又没用
--plugin显式指定路径 - 插件 stdout 没按 protobuf 的
CodeGeneratorResponse格式输出（必须是二进制 protobuf，不是 JSON 或文本）
解析 CodeGeneratorRequest 的关键字段
输入是二进制序列化的 google.protobuf.compiler.CodeGeneratorRequest，Go 里用 proto.Unmarshal 解析。最常读取的字段有：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
request.FileToGenerate：要处理的 .proto 文件名列表（不是所有 import 都在这里） -
request.ProtoFile：所有已解析的FileDescriptorProto，含依赖项；需遍历找匹配FileToGenerate的那个 -
request.Parameter：命令行传入的参数，如paths=source_relative,with_gorm=true，需手动 parse（strings.Split+strings.SplitN）
注意：ProtoFile 里的 message_type 是扁平展开的，嵌套 message 的 name 是 Outer.Inner 形式，不是点号分隔的层级结构。
生成 Go 文件时的路径与包名处理
输出文件路径不能硬编码，必须按 request.Parameter 或约定推导。比如 paths=source_relative 时，输出文件应和 .proto 同目录；paths=import_path 则按 go_package option 决定。关键逻辑：
- 从
file.Options.GetGoPackage()提取包名（若为空，fallback 到文件名转小写） - 用
filepath.Join构造输出路径，避免直接拼字符串（Windows 路径分隔符问题） -
CodeGeneratorResponse.File中的name字段必须是相对于输出根目录的路径（如user/user.pb.go），且不能含../
容易漏掉的细节：如果 proto 文件用了 option go_package = "github.com/x/y/z";，但本地 GOPATH 或 module 路径不匹配，生成的 import 路径可能错，得靠用户自己确保一致性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
