kratos.new() 初始化失败因未注册config.provider，需在main开头调用conf.load()并传入config.newfile等源；service.register()报错因未启用grpc server；proto生成缺失register方法因未安装protoc-gen-go-grpc和go-http插件；中间件取ctx.value失败因transport.context封装单向且http/grpc提取方式不同。
kratos.New() 初始化失败，panic: no config provider registered
这是 Kratos 启动时最常遇到的报错，kratos.New() 内部会尝试加载配置，但默认不带任何配置源。没注册 config.Provider 就调用它，直接 panic。
解决方法不是“先看文档”，而是立刻补上基础配置初始化：
- 必须在
main()开头调用conf.Load()（来自github.com/go-kratos/kratos/v2/config），否则kratos.New()无配置可用 -
conf.Load()需要传入一个config.Provider，比如config.NewFile("app.yaml")或config.NewJson("{"name":"demo"}") - 别用
os.Getenv()手动拼接配置路径——conf.Load()不自动识别环境变量，得自己传进去
示例片段：
func main() {
c := conf.New(conf.WithSource(
config.NewFile("configs/app.yaml"),
))
if err := c.Load(); err != nil {
log.Fatal(err)
}
app, _ := kratos.New( // 这里才安全
kratos.Name("demo"),
kratos.Version("v1.0.0"),
)
// ...
}
service.Register() 报错：rpc error: code = Unavailable desc = connection closed
Kratos 默认用 gRPC 启动 HTTP/GRPC 混合服务，但很多人只启了 HTTP server（http.NewServer()），却忘了注册 gRPC server（grpc.NewServer()），导致 service 注册时连不上本地 gRPC endpoint。
关键点在于：service.Register() 是向本进程内 gRPC server 注册的，不是发请求给别的服务——它依赖本进程已存在且运行中的 grpc.Server 实例。
- 检查是否调用了
grpc.NewServer()并加入app.Run()的 server 列表 - 确认
grpc.Server的监听地址没被占用，或没写成localhost:9000（某些容器环境解析失败） - 如果压根不用 gRPC，就别调
service.Register()；Kratos 的 HTTP 路由完全独立，不需要它也能跑通 REST 接口
proto 文件生成后，xxx.pb.go 里没有 RegisterXXXServiceServer 方法
这是 protobuf 编译配置漏了 Kratos 插件导致的。Kratos 的 gRPC 代码生成不是靠原生 protoc-gen-go，而必须用 protoc-gen-go-grpc + protoc-gen-go-http（后者用于生成 HTTP 映射）。
常见错误是只装了 protoc-gen-go，结果生成的文件只有基础结构体，没有服务注册函数，后续 grpc.RegisterXXXServiceServer() 直接报未定义。
- 确保安装了
protoc-gen-go-grpc（Go 官方 gRPC 插件）和protoc-gen-go-http（Kratos 自研插件） - 执行命令中必须显式指定两个插件：
protoc --go-grpc_out=. --go-http_out=. xxx.proto - 注意
go-http插件要求 proto 中有option (google.api.http) = { ... };，否则不生成 HTTP 路由代码
中间件里取不到 ctx.Value()，或者 transport.ContextFromRequest() 返回 nil
Kratos 的 transport 层（HTTP/gRPC）会把原始请求上下文包装成 transport.Context，但这个过程只在框架入口处做一次。如果你在中间件里用 context.WithValue() 往 ctx 里塞东西，下游 handler 能拿到；但反过来，想从 handler 往外传值到更外层中间件，不行——因为 ctx 是单向传递的。
更隐蔽的问题是：gRPC 和 HTTP 的上下文提取方式不同，不能混用。
- HTTP 中间件应优先用
transport.FromContext(r.Context())（r *http.Request） - gRPC 中间件应使用
transport.FromContext(ctx)（ctx context.Context） - 别试图在 HTTP handler 里调
transport.GinContext()或类似 Gin 特有方法——Kratos 不依赖 Gin，也没有这个函数 - 需要跨层传参时，建议用结构体字段或全局状态管理，而不是强依赖 ctx.Value
ctx.Value 是易出错的隐式通道，尤其在多中间件嵌套时，谁 set、谁 get、生命周期是否匹配，很容易漏掉一环。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
