必须用fiber.new()而非fiber.default()——后者自动挂载logger、recover、requestid中间件,导致敏感头泄露、ttfb增加0.3–0.8ms;strictrouting默认开启使/users与/users/视为不同路径而404;basicauth需显式返回401并return,不可依赖自动拦截。

直接跑不起来、启动就 panic、请求 404 或静默失败——Fiber 的多数报错不是框架本身坏了,而是初始化方式、中间件顺序或类型桥接没对上。下面几个是真实部署中最高频、最易卡住人的点。
fiber.New() 和 fiber.Default() 混用导致日志压垮 I/O 或敏感信息泄露
fiber.Default() 自动挂了 Logger、Recover、RequestID 三个中间件,开发时方便,但上线后每秒打几百条含 Authorization、Cookie 的完整日志,SD 卡 I/O 直接拉满,TTFB 增加 0.3–0.8ms。更危险的是,Logger 默认打印所有请求头,可能把 token 泄露到日志文件里。
- 生产环境必须用
fiber.New()初始化,再按需手动加中间件 - 如需日志,改用采样式:只记录
ctx.Status() >= 400的请求,或对接systemd-journald - 关掉启动 banner:在
fiber.Config中设DisableStartupMessage: true - 别用
fiber.Logger()做生产日志;可用fiber.New().Config().DisableStartupMessage = true静默启动
BasicAuth 中间件注册后完全没效果或全站 401
fiber.BasicAuth() 只解析 Authorization 头、提取 username/password,**不自动返回 401,也不拦截后续 handler**。常见错误是注册完就以为万事大吉,结果请求照常往下走;或者校验失败后没 return,又调了 c.Next(),导致响应已发、后续 handler 还在执行。
- 必须在中间件函数内显式处理失败分支:
c.Status(401).SendString("Unauthorized"); return - 放行才调
c.Next();别在失败路径里调它 - 别全局
app.Use(fiber.BasicAuth(...)),改用分组:auth := app.Group("/api", fiber.BasicAuth(...)) - 密码比对务必用
subtle.ConstantTimeCompare,别用==或strings.EqualFold
反向代理转发失败:Body 为空、Header 丢失、连接数暴涨
有人试图用 http.Client.Do() 手动转发请求,结果 c.Body() 被读过一次就变空、Authorization 等关键 header 没透传、压测几秒就报 dial tcp: too many open files。这不是 Fiber 的问题,而是绕过了 fasthttp 的连接复用机制。
- 正确做法是用标准库的
httputil.NewSingleHostReverseProxy,Fiber 只做路由和限流 - 必须用
http.StripPrefix剥离前缀,否则后端收到的路径带/api/xxx - 每个后端服务配独立
*httputil.ReverseProxy实例,并自定义Transport控制连接池 - 千万别在
Director函数里做耗时操作(如查 DB),它在每次请求时同步执行
静态文件加载后树莓派 OOM、SD 卡写爆
在 Pi Zero 2W 或 Pi 3B 上跑 Fiber,app.Static("/static", "./public") 默认启用内存缓存(CacheDuration: 10 * time.Second),加载几个 MB 的前端资源后 RSS 内存飙升至 400MB+,触发内核 OOM killer 杀死进程。同时 fiber.Logger() 高频写 SD 卡,寿命骤减。
- 禁用静态文件内存缓存:
app.Static("/static", "./public", fiber.Static{CacheDuration: 0}) - 关掉默认 logger:
app.Use(fiber.Logger())必须删掉,改用systemd journal统一收日志 - 构建时显式指定平台:
GOOS=linux GOARCH=arm64 go build -o server .,避免 CGO 引入额外依赖 - 若用 TLS,别监听
127.0.0.1:443—— 树莓派无硬件加速,纯软件 RSA 握手会吃光 CPU
这些报错背后几乎都指向同一个事实:Fiber 是个轻量壳子,它不替你做决定,也不兜底。你得清楚每个中间件的职责边界,尤其是那些“看起来能用、其实要桥接”的地方——比如 fasthttp.ReverseProxy 必须用 fiber.WrapHandler,http.Handler 不能直接塞进 app.Get()。漏掉这一层包装,就是静默失败的开始。











