kratos proto client/server生成代码的前提是.proto文件满足三重硬约束：必须置于api/子目录下、package声明与目录结构严格一致（如api/user/v1/user.proto对应package user.v1;）、option go_package须显式声明且格式正确（如"user/api/user/v1;v1"）；任一不满足则命令静默跳过，不报错也不生成文件。
kratos proto client 和 kratos proto server 能生成代码，但前提是 proto 文件本身必须满足三重硬约束：路径在 api/ 下、package 与目录结构严格一致、go_package 配置正确。不满足任一条件，命令都会静默跳过，不报错也不生成任何文件。
proto 文件必须放在 api/ 子目录下
kratos 的代码生成工具只扫描 api/ 目录及其子目录，其他位置一律忽略：proto/、internal/api/、项目根目录下的 user.proto 全部无效。
常见错误现象：
- 执行
kratos proto client api/user/v1/user.proto后无输出、无文件生成 -
internal/service/user_service.go不存在，或内容为空
确认方式：直接 ls api/user/v1/，确保 user.proto 真实存在且路径层级清晰。
package 声明必须逐级匹配目录结构
例如文件路径是 api/user/v1/user.proto，则 package 必须写成 package user.v1;（注意末尾分号），不能是 package user;、package v1; 或 package api.user.v1;。
为什么这样做：
-
kratos proto server依赖该声明推导 Go 包路径和 import 路径 - 写错会导致生成的
pb.RegisterUserServiceServer参数类型不匹配，服务注册时 panic - wire 注入会因接口类型无法识别而失败
容易踩的坑：用 IDE 自动生成 package 名时带上了模块名（如 github.com/xxx/kratos），这是错的——proto 的 package 是逻辑命名空间，不是 Go module 路径。
go_package 必须显式声明且含分号
option go_package = "user/api/user/v1;v1"; 这种写法才是合规的。左侧是 import 路径（应与文件物理路径相对应），右侧是生成代码的 Go 包名（用于避免同目录多 proto 冲突）。
参数差异：
- 只写
option go_package = "user/api/user/v1";（无分号）→ 生成的 Go 文件包名为v1，但实际落在user/api/user/v1/目录下，Go 编译器报错：expected package user - 右侧别名写成
user_v1→ 后续所有 import 都得用"user/api/user/v1"，但包内定义的 struct 又在user_v1包里，类型引用断裂
性能 / 兼容性影响：go_package 错误不会影响 protoc 执行，但会让整个生成链下游全部失效——编译失败、wire 构建中断、gRPC 注册 panic。
HTTP 映射必须 import annotations.proto 并配 option
要让 kratos proto client 生成 HTTP 路由绑定代码，proto 文件开头必须有：
import "google/api/annotations.proto";
并在 RPC 方法中添加：
rpc SayHello(HelloRequest) returns (HelloReply) {
option (google.api.http) = { get: "/hello/{name}" };
}
为什么这样做：
- 缺
import行，option (google.api.http)整行被 protoc 忽略，生成的 HTTP handler 完全为空 - kratos 的
protoc-gen-go-http插件依赖这个 import 才能注入绑定逻辑 - 不加该配置，
kratos proto client仍会生成 pb.go，但不会生成http_*.go文件
容易被忽略的地方：这个 annotations.proto 文件必须已安装到 $PROTOC_INCLUDE 或通过 go install google.golang.org/api/annotations@latest 提前拉取，否则 protoc 报错 File not found。
