Kratos项目wire_gen.go报错是因Go模块路径与Kratos版本不匹配，需检查go.mod模块名、执行go mod tidy并更新kratos/v2依赖。
kratos new 项目后为什么 wire_gen.go 报错找不到依赖
刚用 kratos new 生成项目，go run cmd/helloworld/wire.go 或 wire 命令直接失败，提示 cannot find package "github.com/go-kratos/kratos/v2" ——这不是你漏装依赖，而是 Go 模块路径和 Kratos 版本没对齐。
常见原因有三个：
-
go.mod里声明的github.com/go-kratos/kratos/v2版本低于你本地go install的 CLI 工具版本（比如 CLI 是 v2.11.0，但go.mod锁的是 v2.8.0）； - 项目模板生成时未触发
go mod tidy，或执行了但 GOPROXY 不稳定导致部分间接依赖没拉全； - 你手动删过
go.mod又没重跑go mod init，导致模块路径不匹配（例如写成helloworld而不是github.com/yourname/helloworld）。
实操建议：
- 进项目根目录，先跑
go mod tidy -v，观察是否卡在某个replace或require行； - 检查
go.mod第一行是否为module github.com/xxx/xxx（不能是裸名如module helloworld）； - 强制更新 Kratos 核心依赖：
go get github.com/go-kratos/kratos/v2@latest，再重试wire； - 如果仍失败，删掉
go.sum和vendor/（如有），再go mod tidy。
proto 文件改了，为什么 api/ 目录下没生成新代码
修改了 api/helloworld/v1/helloworld.proto，但运行 kratos proto client 或 make api 后，internal/service 或 api/helloworld/v1/ 下的 Go 文件完全没变——大概率是 protoc 插件没装全，或者 .proto 里用了不被 Kratos 默认支持的语法。
立即学习“go语言免费学习笔记（深入）”；
关键点：
- Kratos 默认只识别
option go_package = "github.com/xxx/api/helloworld/v1";这种格式，如果你写了option go_package = "./helloworld/v1";，生成器会静默跳过； -
protoc-gen-go-http/v2必须和protoc-gen-go-grpc版本一致（都用@latest安装），否则http.proto中的option (http.rule) = { ... };会被忽略； - 如果
.proto里新增了 message 但没在 service 方法中引用，kratos proto client默认不会生成对应结构体（这是 protoc 的默认行为，不是 bug）。
实操建议：
- 确认插件已安装：
which protoc-gen-go-http、which protoc-gen-go-grpc都应返回路径； - 在
.proto文件顶部加一句import "google/api/annotations.proto";，并确保third_party/google/api/目录存在（Kratos 模板自带，别删）； - 改完
.proto后，必须进api/目录再执行kratos proto client，不能在项目根目录运行； - 想强制全量生成？删掉
api/下所有*.pb.go和*_http.pb.go文件，再重跑。
启动时报错 “failed to resolve service: consul:8500”
服务启动时日志出现 failed to resolve service: consul:8500 或 registry: no endpoints available，说明服务注册环节断了。Kratos 默认用 Consul 做注册中心，但生产环境往往不用 Consul，或者压根没起 Consul 实例。
这不是配置写错了，而是「注册中心」和「服务发现」被当成一回事了。Kratos 的 registry 接口同时承担注册与发现职责，但实际部署中，这两者常解耦：
- 注册：服务启动时主动上报地址（需要 Consul agent 或 etcd server 在线）；
- 发现：客户端调用时查 registry 获取实例列表（可走本地缓存或直连 etcd）；
- 如果只是本地开发调试，完全可以关掉注册——把
kratos.Registrar(consulReg)这行注释掉，改用kratos.Discovery(discovery.NewNoopDiscovery())。
实操建议：
- 确认 Consul 是否真在运行：
curl http://localhost:8500/v1/status/leader应返回 IP； - 检查
consul.NewRegistry的WithAddress参数是否带协议（正确是"http://consul:8500"，不是"consul:8500"）； - 生产环境建议换 etcd：
github.com/go-kratos/kratos/v2/registry/etcd，它比 Consul 更轻、更易容器化； - 如果服务间调用走 gRPC 直连（比如 BFF 调下游），根本不需要注册中心，删掉
kratos.Registrar即可。
链路追踪 traceID 在 HTTP 和 gRPC 之间不传递
用 Jaeger 查看调用链，发现从 http://localhost:8000/helloworld 发起请求，到 grpc://localhost:9000 的下游服务，traceID 断了——这说明 OpenTelemetry 的上下文传播没生效，不是框架 bug，而是中间件加载顺序或 transport 配置问题。
根本原因是：Kratos 的 tracing.Server() 中间件必须放在最外层，且 HTTP/gRPC server 的拦截器链要一致。如果 HTTP server 加了 tracing，gRPC server 没加，或者反过来，跨协议链路必然断裂。
实操建议：
- 检查
http.NewServer和grpc.NewServer的Middleware参数，两者必须都包含tracing.Server()，且顺序相同（通常放第一个）； - 确认
tracing.Client()是否加在了调用方的 client 初始化里（比如http.NewClient或grpc.Dial时传入）； - HTTP header 中 traceID 默认从
traceparent字段读取（W3C 标准），而旧版 Jaeger 用uber-trace-id，需在 tracing 配置里显式指定：tracing.WithPropagators(propagators.NewJaegerPropagator())； - 如果用了 Fregata 网关，确保它转发时透传了
traceparentheader，否则 BFF 层收不到上游 trace 上下文。
真正容易被忽略的是：Kratos 的 tracing 中间件默认只注入 span，不自动传播 context 到业务 handler 的参数里。你要在 handler 函数签名中显式接收 context.Context，再用 otel.GetTextMapPropagator().Inject 手动注入 header——这点文档极少提，但线上排查时高频踩坑。
