不能混用gin与go-zero，因go-zero的rest.server已完整接管http生命周期，手动启动gin.default()会导致限流失效、trace断链、context丢失，并引发端口冲突或svc.context为nil等错误。
别试图把 Gin 塞进 go-zero 里——它本身已经是完整 HTTP + RPC + 治理能力的云原生底座，强行混用只会让限流失效、trace 断链、context 丢失。
go-zero 不是“加个中间件就能用”的轻量框架
它从设计上就拒绝“拼凑式集成”：rest.Server 已接管整个 HTTP 生命周期，包括路由匹配、中间件链、panic 恢复、trace 注入和超时级联。你手动起 gin.Default()，等于在同一个进程里另开一个 HTTP server，但这个 server 完全不感知 svc.Context、jwt 中间件、甚至 logx 的 traceid 字段。
常见错误现象：
-
panic: http: Server closed或address already in use（两个服务争抢 8888 端口） - 请求能进 handler，但
svc.Context为nil，导致 db、redis 初始化失败 - 限流器配置写了，但实际没生效——因为 gin 的中间件没接入 go-zero 的限流 registry
goctl 生成的代码结构就是最佳工程约束
执行 goctl api new user-api 后生成的标准目录不是“建议”，而是 go-zero 运行时依赖的契约：
-
internal/handler只负责解析请求、调用 logic，不能写业务判断 -
internal/logic是纯业务逻辑层，必须接收ctx和req，返回resp和error -
internal/svc.ServiceContext是所有依赖（db、cache、rpc client）的统一注入点，由框架自动构造并传递 -
etc/user-api.yaml中的Timeout、MaxConns、Redis配置，会直接绑定到svc.Context实例
改结构？可以，但你要自己重写 NewServiceContext、手动传参、绕过框架的自动 reload 机制——得不偿失。
高并发防护能力是内置的，不是靠“再加个 middleware”实现的
go-zero 的限流、熔断、超时控制不是插件，而是嵌入在请求生命周期里的原子能力：
-
Timeout配置作用于整个 handler 调用链，包括 logic 层的 db 查询、rpc 调用，自动级联取消 -
Limit和Breaker在handler入口就触发，不需要你在 logic 里手动调limit.Allow() - 自适应熔断基于最近 10 秒的成功/失败率动态开关，无需配阈值；降载则在 CPU > 80% 时自动触发
- 所有这些都通过
rest.MustNewServer自动注册，你只要在.api文件里写@server(timeout = "3s")就生效
K8s 部署不是“最后一步”，而是从 goctl 就开始对齐
goctl 支持直接生成云原生交付物：
-
goctl docker -go ./user-api→ 生成标准Dockerfile，含多阶段构建、非 root 用户、health check -
goctl kube -go ./user-api -namespace default→ 输出带 readiness/liveness probe、resource limit、env 注入的deployment.yaml -
goctl rpc protoc user.proto --go_out=./ --go-grpc_out=./→ 自动生成 gRPC client/server，天然支持 etcd 服务发现
真正容易被忽略的是：所有生成的 YAML 和 Dockerfile 都默认启用 pprof 探针端口、暴露 /healthz、挂载 configmap，这些不是可选项，而是 go-zero 认为“生产环境必须有的基础设施”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
