Prefork 仅在单进程CPU≥95%、≥6物理核、SSD IO充足时可能提升QPS；否则易因fork开销、资源争抢或配置错误导致QPS下降。
Prefork 开启后 QPS 反而下降，先查物理核数和连接模型
开 Prefork: true 不等于自动变快。它只在单进程 CPU 持续 ≥95%、机器有 ≥6 物理核、SSD IO 充足时才可能带来收益。压测发现 QPS 下降，大概率是场景不匹配：比如单核机器硬开 Prefork，或短连接密集型服务（如大量 HTTP/1.1 小请求），fork 开销反而盖过并行收益。
验证方式很简单：
-
top -H看单个 fiber 进程的 CPU 占用 -
lscpu | grep "CPU(s)"查物理核数（注意不是逻辑线程数） - 用
wrk -t12 -c400 -d30s http://localhost:3000/模拟中等并发，观察整体吞吐变化
每个子进程必须独立初始化 DB 和 Redis 客户端
没做资源隔离就开 Prefork，app.Shutdown() 会失效，子进程残留成僵尸进程；更常见的是 DB 连接池被多个 worker 抢，引发超时或 panic。
常见错误是把 gorm.Open() 放在 main() 开头，结果所有 worker 都复用同一份配置。正确做法是：
- 把 DB 初始化逻辑放进
fiber.New()后、app.Listen()前 - 每个子进程调用自己的
gorm.Open()，配独立连接池（如MaxOpenConns: 20） - Redis 客户端同理，别用全局单例，改用
redis.NewClient()每进程一份 - 加
DisablePrint: true，否则每个 worker 都打印启动 banner，日志混杂难排查
StrictRouting 必须保持 true，但得统一处理尾部斜杠
Fiber 默认 StrictRouting: true，这不是 bug，是契约：/users 和 /users/ 是两条完全不同的路由。关掉它看似省事，但会导致 /users/123 被 /users 错误捕获，c.Params("id") 拿不到值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推荐做法是显式重定向，而不是关闭 StrictRouting：
- 在所有路由前加中间件：
if strings.HasSuffix(c.Path(), "/") && c.Path() != "/" { c.Redirect(strings.TrimSuffix(c.Path(), "/"), 301) } - 上线前同步检查前端 SDK、OpenAPI spec、Postman 集合是否全用无尾斜杠路径
- 别写
app.Get("/users/")重定向 handler 再手动跳转——多一次 roundtrip，TTFB 增加
Prefork 必须前置 Nginx/Traefik，否则长连接会卡死单个 worker
Prefork 依赖内核 SO_REUSEPORT 实现端口共享，但它的负载均衡策略是“连接级”而非“请求级”。一个 WebSocket 或 HTTP/2 流始终绑定到固定 worker，无法动态迁移。当某 worker 因慢查询卡住，新连接仍可能被内核分给它。
所以生产环境必须前置反向代理，做两件事：
- 终结 TLS，卸载加密开销（
ListenTLS在 Prefork 下每个 worker 都重复加载证书） - 用 upstream 的
least_conn或ip_hash做更可控的分发，避免单点阻塞放大 - 健康检查探针也得配在 proxy 层，别直接探
:3000，否则 probe 请求也会被轮到卡死的 worker
最易被忽略的一点：Prefork 下每个 worker 的日志、panic 捕获、信号监听都得单独处理，不能靠主进程兜底——哪怕只漏一个 os.Interrupt 监听，shutdown 就会卡住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
