kratos.new() 启动 panic 的根本原因只有三个：没加载配置、没创建 server 实例、没将 server 实例传入 server 参数列表；conf.load() 必须在 main() 第一行调用并显式传入 config.provider，grpc.newserver() 和 http.newserver() 必须非 nil 且一并传入。
kratos.New() 启动就 panic，不是框架有问题，而是初始化顺序和依赖没对齐——它不报错，直接崩溃，且错误信息极简，新手常卡在第一行。
kratos.New() 为什么一启动就 panic
根本原因只有三个：没加载配置、没创建 server 实例、没把 server 实例传进 kratos.New() 的 Server 参数列表。它不会提示“配置文件路径不对”，也不会说“gRPC server 没启”，而是直接 panic: no config provider registered 或更模糊的 nil pointer dereference。
-
conf.Load()必须在main()函数第一行调用，不能等日志、flag 或其他初始化做完再执行 -
conf.Load()需显式传入至少一个config.Provider，例如config.NewFile("configs/app.yaml")；os.Getenv("CONFIG_PATH")不会被自动解析，得自己拼进去 - 如果
configs/app.yaml不存在，c.Load()返回 error，必须检查，否则后续 panic 更难定位 -
grpc.NewServer()和http.NewServer()必须先实例化，且非 nil（比如 consul 连不上时consul.New()可能返回 nil + error，只判 error 会漏掉） - 这两个 server 实例必须一起传进
kratos.New(kratos.Server(httpSrv, grpcSrv))；漏掉任意一个，对应协议就完全不可用
proto 编译后缺 RegisterXXXServiceServer 怎么办
这不是代码写错了，是 protoc 插件链没配全。Kratos 的 gRPC 注册函数（如 RegisterDeviceServiceServer）不是 protoc-gen-go 生成的，必须用 protoc-gen-go-grpc（v2 版本）+ protoc-gen-go-http 两个插件协同生成。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 单独装
protoc-gen-go只生成*.pb.go，不含 gRPC Server 注册逻辑和 HTTP 路由映射 - 命令必须带
paths=source_relative，例如：protoc --go-grpc_out=paths=source_relative:. device.proto，否则生成路径错乱，import引用失败 - 确认
go.mod中google.golang.org/grpc/cmd/protoc-gen-go-grpc版本 ≥ v1.3.0（v2 接口要求），旧版插件不兼容 Kratos 生成规则 - 生成后检查输出文件是否含
func RegisterXXXServiceServer和func RegisterXXXHTTPServer，缺任一即说明插件未生效
transport/http 中间件为什么不能直接用 net/http 原生中间件
Kratos 的 http.Server 是封装层，它的 Handler 类型不是原生 http.Handler，上下文透传、traceID 注入、错误统一处理都走 Kratos 自己的 middleware.Middleware 接口。直接塞 func(http.Handler) http.Handler 会绕过整个上下文链，导致元信息丢失、日志无 trace、监控断点。
- 正确注册方式是用
transport.WithMiddleware()，参数类型必须是func(handler middleware.Handler) middleware.Handler - 已有中间件（如 CORS、JWT 验证）需用
transport.HTTPMW包装器转换，否则运行时报 panic - 常见错误：把
cors.New()直接传给transport.WithMiddleware()—— 它返回的是func(http.Handler) http.Handler，不是 Kratos 接受的签名 - HTTP 中间件里访问
transport.FromContext(r.Context())才能拿到 Kratos 封装的RequestInfo，原生r.Context()里没有这些字段
cmd 目录下没 main.go？这是结构强制约束，不是遗漏
Kratos 把启动入口收进 cmd 子目录（如 cmd/api/main.go），业务代码放在 internal 下，这是为多服务复用 infra（配置、日志、tracer）做的硬性结构设计，不是为了“看起来规范”。
- 这种结构让单元测试难 mock：因为
main()里耦合了conf.Load()、app.New()等初始化逻辑，无法干净隔离业务 handler - 模块复用受限：想把
internal/service直接 import 到其他项目时，可能因依赖cmd下的全局 logger 或 tracer 而编译失败 - 解决办法是把可复用逻辑下沉到
internal/biz和internal/data层，internal/service仅做 transport 绑定，避免引入 Kratos 特定 infra - 真正卡住人的地方不是语法，而是 Kratos 把“配置加载时机”“context 传播边界”“server 生命周期管理”这些隐性契约全写进了目录结构和接口签名里
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
