协程数量爆炸导致Fiber服务变慢的根本原因是handler内goroutine泛滥，而非Fiber框架本身；应使用semaphore限并发、异步buffer处理短任务、外层限流+有界任务队列防失控。
协程数量爆炸时 Fiber 服务变慢，根本原因不是框架
runtime.NumGoroutine() 持续 >10k 是明确信号：你没在控制并发，而是在放任 goroutine 泛滥。Fiber 本身不创建 goroutine —— http.ListenAndServe 启动后，每个请求由 net/http 底层触发一个 goroutine（Fiber 就是基于它封装的），真正失控点在 handler 内部。
- 别在循环里写
go handleItem(item)，尤其是处理 HTTP 请求体、数据库 rows、文件行这种批量输入 - 用
golang.org/x/sync/semaphore代替手写 channel 控制并发数，语义清晰且支持context.Context - 短生命周期任务（如打点、日志上报）走异步 buffer + 定期 flush，而不是每个动作启一个 goroutine
- 检查是否所有 goroutine 都在争抢同一个无缓冲
chan——这会让它们排队执行，本质是单线程
Fiber 路由匹配快，但 handler 一阻塞就全白搭
Fiber 的 Radix 树路由全程无锁、只读、O(k) 时间复杂度，匹配本身不会成为瓶颈。压测时 P95 延迟突增，99% 是 handler 里藏了隐式串行点。
- 未设
ReadDeadline的外部 HTTP 调用，或没用database/sql连接池而是直连 DB - 同步调用第三方服务时忘了加
ctx.Timeout(5 * time.Second) - 中间件或 handler 中修改了闭包捕获的全局
map或slice，触发fatal error: concurrent map writes - 用了
time.Sleep()模拟延迟——它会挂起整个 goroutine，调度器无法切走
限流必须放在协程池之前，顺序错了就等于没限
用 golang.org/x/time/rate.Limiter 做限流，但若把它放在协程池 submit 之后，等于先让请求挤进池子排队，再判断“该不该处理”。此时限流已失效，内存和队列都在涨。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 限流逻辑必须在最外层 handler 或中间件中完成：
if !limiter.Allow() { http.Error(w, "Too Many Requests", http.StatusTooManyRequests); return } - 协程池的任务 channel 必须设容量上限（如
make(chan Task, 1000)），并配合非阻塞提交：select { case pool.ch - 不同接口建议用
map[string]*rate.Limiter隔离，key 高并发读写时用sync.RWMutex或sync.Map
文件写入、日志、审计等 IO 任务别裸奔
Fiber 处理完请求很快，但如果你在 handler 里直接 file.Write 或 log.Println 写同一文件，多个 goroutine 会竞争系统调用偏移量，导致内容交错（比如 "req_id:123" 和 "status:200" 拼成 "req_id:st200"）。
立即学习“go语言免费学习笔记（深入）”；
- 唯一内核级安全方案是打开文件时带
os.O_APPEND，但它只适用于追加，不支持覆盖或随机写 - 通用解法是单 writer goroutine + 带缓冲 channel：
logCh := make(chan string, 1024)，业务方只logCh - 初始化文件用
os.OpenFile(name, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)，避免重复打开 - 若允许少量丢失（如 debug 日志），可去掉
file.Sync()，改用 buffer 阈值或定时 flush
真正难的不是堆多少 goroutine，而是识别哪些操作会把“并发”变成“串行”，以及哪些看似无害的共享变量会在高并发下突然崩掉。Fiber 的路由树很稳，但它的 handler 运行在你的代码上——那才是调度器真正要面对的战场。
