Gin适合QPS<5k场景，兼容net/http生态；Fiber在高并发（≥10k）且内存敏感时更优，但不兼容标准库中间件，需适配器或替代方案。
选 Gin 还是 Fiber？看并发压测和标准库兼容性
如果你的接口 QPS 预期稳定在 5k 以下，Gin 是更稳妥的选择；一旦接近或超过 10k，并且对内存分配敏感（比如跑在低配容器里），Fiber 的 Fasthttp 底层会明显拉开差距。但要注意：Fiber 不兼容 net/http 的中间件生态——像 promhttp、httptrace 这类标准库工具无法直接复用，得找对应适配器或改用 Fiber 自带的 middleware.Metrics 等替代方案。
-
Gin的gin.Context是net/http的封装，调试时可直接用http.Request原生方法，日志、链路追踪埋点更顺手 -
Fiber的fiber.Ctx是独立抽象，ctx.Request().URI().String()这类写法看着像 net/http，但底层不走http.Handler接口，某些依赖http.ResponseWriter的库（如部分模板渲染器）会报错 - 本地开发调试阶段，
Gin的gin.DebugMode自动开启详细错误页，而Fiber默认静默失败，需手动加fiber.Config{DisableStartupMessage: false}才能看到启动提示
Beego 和 Kratos 不是“升级选项”，而是架构分水岭
Beego 和 Kratos 的适用场景和决策成本完全不同：前者适合单体快速交付，后者意味着你已决定采用 Protobuf + gRPC + OpenTelemetry 的标准化微服务基建。别因为项目初期想“一步到位”就硬上 Kratos——它强制要求先写 .proto 文件定义服务契约，所有 HTTP 接口都得通过 kratos transport 层转接，调试时多一层抽象，出错信息也常卡在 transport/http 或 transport/grpc 内部，而不是你的业务逻辑里。
-
Beego的bee new能一键生成 MVC 目录+ORM+Admin 后台，但它的orm.RegisterDriver对 SQLite 支持有隐式依赖，Linux 服务器上若没装gcc会编译失败，报错是undefined reference to sqlite3_*，不是包找不到 -
Kratos的kratos proto client生成代码后，必须配合kratos run启动，不能像go run main.go那样直跑——它依赖config.yaml中的server.transport配置项，缺字段就 panic，错误提示是key not found: "transport"，容易误判为配置文件路径问题 - 团队里有人刚从 Python/Java 转 Go，
Beego的控制器写法（func (c *MainController) Get()）比Kratos的func (s *UserServiceServer) CreateUser(ctx context.Context, req *v1.CreateUserRequest)更易上手
Go Modules 初始化不是“运行 go mod init 就完事”
很多项目在 go mod init 后跑不通，根本原因不是命令没执行，而是模块路径和实际目录结构不匹配。比如你在 /home/user/myapp 下执行 go mod init github.com/yourname/myapp，但代码里 import 了 "myapp/handler"，Go 就会报 import "myapp/handler": cannot find module providing package myapp/handler——它只认模块名开头的路径，不认本地相对路径。
- 正确做法是：确保
go.mod第一行的模块名，和所有import语句中的路径前缀完全一致，例如import "github.com/yourname/myapp/handler" - 如果项目要部署到私有 Git 仓库，模块名必须用真实可解析的域名（如
gitlab.example.com/team/project），不能用localhost或192.168.x.x，否则go build时会卡在verifying gitlab.example.com/team/project@v0.1.0 - 用
go list -m all检查依赖树时，若看到某行末尾带// indirect，说明该模块未被当前代码直接 import，只是被其他依赖间接引入——这种依赖容易在删掉某个中间件后突然失效，建议定期清理
部署时二进制体积和符号表取舍很实际
Go 编译出的二进制默认带调试符号，file ./myapp 显示 “not stripped”，上线前用 upx 压缩或 go build -ldflags="-s -w" 去符号能减掉 30%~50% 体积。但别一刀切：去掉符号后，pprof 的火焰图会丢失函数名，只显示 ???；线上 panic 日志里的栈帧也只剩地址，没有文件名和行号。
立即学习“go语言免费学习笔记（深入）”；
- 推荐做法：CI 流水线中用
-ldflags="-s -w"构建发布版，同时保留一份未 strip 的二进制存档，命名加-debug后缀，用于事后分析 - 若用
systemd托管，ExecStart路径必须写绝对路径，比如/opt/myapp/bin/myapp，不能写./myapp或myapp，否则 systemd 会报failed at step EXEC spawning - Docker 镜像里用
FROM golang:1.25-alpine编译，再COPY --from=0 /workspace/myapp /app/myapp到 scratch 镜像，最终镜像大小可压到 8MB 左右；但注意 Alpine 的 musl libc 和标准 Linux 的 glibc 不兼容，若二进制里调用了cgo（比如连 PostgreSQL），就得换debian:slim基础镜像
go mod 的路径解析规则、systemd 的工作目录继承逻辑、或者 Fiber 里一个没声明的 ctx.Next() 导致中间件跳过。这些细节不写进文档，只藏在某次 panic 的堆栈最底下。 
