Kitex服务启动失败因未调用server.Run()；IDL修改后需手动重生成代码；客户端超时需同时设context.WithTimeout和client.WithRPCTimeout；依赖冲突应清缓存并使用真实版本号。
Kitex 服务启动失败：main.go 里 NewServer 调用后进程立即退出
Kitex 默认不阻塞主线程，NewServer 只是构造对象，没调 server.Run() 就会直接结束。常见于复制示例时漏掉这行。
- 必须显式调用
server.Run()，它内部会监听端口并阻塞 - 如果用了
kitex.WithExitOnErr(true)，任何初始化错误（比如端口被占、IDL 解析失败）都会导致进程静默退出，建议先关掉这个选项调试 - 检查
server.Run()是否被包裹在 goroutine 里——Kitex 的Run本身已处理并发，额外起 goroutine 反而可能让 main 线程提前退出
IDL 修改后，kitex 命令生成的代码不更新
Kitex 的代码生成是单次快照，不会监听文件变化。改了 .thrift 或 .proto 后必须手动重新执行 kitex 命令，否则 runtime 仍用旧结构体序列化，必然 panic 或字段丢失。
- 确认执行的是当前目录下的
kitex（不是全局旧版本），可用which kitex查看路径 - Thrift 场景下，若 IDL 中用了
include，需确保所有被 include 的文件都在-I指定路径下，否则生成器静默跳过，不报错但字段为空 - 生成目标目录默认是
kitex_gen，如果项目里已有同名目录且 git 忽略了部分文件，容易误以为“生成过了”，其实只是旧文件残留
Kitex 客户端调用超时，但 context.WithTimeout 没生效
Kitex 的超时控制分两层：客户端发起请求的 context 超时，和底层连接/读写的网络超时。只设 context.WithTimeout 不足以覆盖 TCP 层卡死场景。
- 必须同时配置
client.WithRPCTimeout(5 * time.Second)，这个值会透传给底层 net.Conn 的SetDeadline - 如果服务端处理慢但连接一直活着（比如卡在 DB 查询），仅靠 context 超时无法中断 socket 读，此时
WithRPCTimeout才真正起作用 - 注意
WithRPCTimeout是 per-request，不是 client 实例级；每次client.XXXService().YYYMethod(ctx, req)都要确保 ctx 带 timeout，Kitex 不会自动继承 client 构造时的 context
Go module 下 Kitex 依赖冲突：unknown revision v0.0.0-00010101000000-000000000000
这是 Go proxy 缓存了损坏的伪版本号，常见于从私有仓库 fork Kitex 后未正确打 tag，或 go.sum 中记录了不存在的 commit hash。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go clean -modcache清空本地 module 缓存，再go mod tidy - 检查
go.mod里 kitex 相关依赖是否写死了类似github.com/cloudwego/kitex v0.0.0-20230401020304-abc123...这种伪版本——应改为v0.7.0等真实 tag - 若公司内部镜像源同步滞后，临时加
export GOPROXY=https://proxy.golang.org,direct绕过，验证后再切回
Kitex 的隐性成本常藏在生成代码的耦合度和中间件链路的 context 传递上，比如自定义 middleware 里忘了把 parent ctx 传给 next，下游就收不到 cancel 信号——这种问题不会报错，但会让超时和链路追踪彻底失效。
