修改.proto文件后必须重新生成客户端和服务端代码，否则会导致编译失败或运行时panic；需确认proto路径在api/下且package声明与目录严格匹配；执行kratos proto client和server两步重生成；手动同步biz/service等业务层字段；最后运行go generate并编译校验。
在Kratos项目中修改.proto文件的字段后，必须重新生成客户端和服务端代码，否则编译会失败或运行时出现类型不匹配、字段丢失、gRPC调用panic等严重问题，因为Go结构体与协议定义已脱节。
确认proto文件位置与package声明是否合规
打开你的.proto文件，检查它是否位于api/xxx/xxx.proto路径下——例如api/user/v1/user.proto；若放在proto/、internal/api/或根目录，kratos proto命令将静默跳过，不报错也不生成任何代码。
检查package声明是否与目录严格对应：比如文件路径是api/user/v1/user.proto，则必须写package api.user.v1;。不一致会导致生成的Go包路径错误，后续import全部失效，【wire注入和gRPC注册会因类型不匹配而panic】。
执行字段变更后的两步强制重生成
第一步：生成客户端stub（含pb.go与http映射）→
执行kratos proto client api/user/v1/user.proto。
第二步：生成服务端骨架（含service.go模板）→
执行kratos proto server api/user/v1/user.proto -t internal/service。
注意：这两条命令必须按顺序执行，且不能省略任意一条。只跑client会导致service结构体未更新，方法签名仍为旧字段；只跑server则HTTP网关路由、客户端调用方结构体缺失新字段，请求直接反序列化失败。
手动同步业务层代码以适配新字段
方法一：更新internal/service/user_service.go
找到新生成的RPC方法签名，例如CreateUser(ctx context.Context, req *pb.CreateUserRequest) (*pb.CreateUserReply, error)，检查req结构体内新增字段是否已在uc.Create()等业务调用中被读取和使用。
方法二：检查internal/biz/user.go中的领域模型
若proto中新增了email string字段，但biz.User结构体没有对应Email string字段，gRPC请求解码后该值会被丢弃——你得手动补上字段并同步赋值逻辑。
这一步不可跳过。生成工具只更新协议层和骨架，【不会触碰biz、data、handler等业务代码，字段空转会导致前端传了但后端完全收不到】。
触发依赖注入与类型断言校验
运行go generate ./，确保wire.go和wire_gen.go被刷新；该命令会重新扫描所有internal/下的结构体注册，把新字段带入DI容器。
打开刚生成的internal/service/user_service.go，确认顶部存在类似var _ pb.UserServiceServer = (*UserService)(nil)的断言行。它会在编译期强制校验你是否实现了全部RPC方法——如果删了这行，又漏实现某个新增方法，服务启动时才会panic，而不是编译失败。
编译项目：go build -o ./bin/app ./cmd。若出现undefined field或cannot use ... as ...类错误，说明某处业务代码还没适配新字段，立即返回上一步排查。
