pprof调试端口无数据需检查三件事：服务是否有真实请求、pprof服务是否在独立goroutine运行且主goroutine未退出、cpu profile是否满足30秒采样时长，可改用heap或goroutine接口即时查看。
pprof 调试端口没数据？检查这三件事
默认启用 net/http/pprof 并不等于能拿到有效 profile 数据——常见原因是服务未真正接收请求或采样时间太短。
- 确保 HTTP 服务已启动且有真实流量（
curl http://localhost:8080触发一次请求） -
http.ListenAndServe("localhost:6060", nil)必须在独立 goroutine 中运行，且不能被主 goroutine 提前退出中断 - 访问
/debug/pprof/页面时，若只看到空列表，大概率是 Go 进程尚未执行满 30 秒（CPU profile 默认需至少 30 秒采样才可下载）；改用/debug/pprof/heap或/debug/pprof/goroutine?debug=1可即时查看
sync.Pool 复用对象时为什么没效果？
不是所有对象都适合放进 sync.Pool，滥用反而增加 GC 压力和锁竞争。
- 只复用生命周期短、创建开销大、结构稳定的小对象（如
bytes.Buffer、HTTP header map、JSON decoder） - 避免存入含指针字段或外部引用的对象（比如带
http.Request引用的自定义结构体），否则可能引发内存泄漏 - 务必在
Get()后做类型断言和有效性校验，Put()前清空敏感字段（如重置Buffer的len而非只设cap） - 对比：fasthttp 直接复用
Request和Response对象；gin 默认不用sync.Pool，因上下文*gin.Context携带太多动态状态
Gin 路由匹配慢？别怪框架，先看你的写法
Gin 的 trie 路由本身极快，但错误注册方式会让它退化成线性遍历。
- 避免混用静态路径与通配符：比如
router.GET("/user/:id", ...)和router.GET("/user/profile", ...)写反顺序，后者会被前者拦截 - 不要在中间件里调用
c.Next()前修改c.Request.URL.Path，会破坏 trie 匹配缓存 - 大量参数路由（如
/api/v1/:a/:b/:c/:d/:e）会导致节点分裂过多，建议合并为单个参数 + 解析逻辑，或改用查询参数 - 实测：1000 条静态路由 vs 100 条带参数路由，前者匹配耗时稳定在 20ns 级，后者在极端嵌套下可达 200ns+
goroutine 泄漏比内存泄漏更难发现
pprof 的 /debug/pprof/goroutine?debug=2 输出的是完整栈，但关键不在数量，而在“停在哪”。
- 重点关注卡在
select{}、chan receive、time.Sleep或数据库QueryRow的 goroutine —— 它们大概率已脱离控制流 - 轮询场景（如每 5 秒查一次 DB）务必用
context.WithTimeout包裹 I/O 调用，否则超时连接会拖住整个 goroutine - 用
runtime.NumGoroutine()在健康检查接口中暴露当前数量，设置告警阈值（如 >5000 持续 1 分钟） - 注意：
time.Ticker不会自动 stop，必须显式defer ticker.Stop()，否则 goroutine 永久存活
go tool pprof -http=:6060 http://localhost:6060/debug/pprof/heap，盯着 top3 的分配源头看两分钟。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
