Go 系统编程与并发原语开发短记：尾延迟先看等待，不只看 CPU

Go 系统编程与并发原语开发短记尾延迟先看等待不只看 CPUGo 服务出现尾延迟时CPU 利用率不高并不意味着运行时没有阻塞。请求可能在 mutex、channel、连接池、下游 RPC 或调度器队列里等待。先把慢请求按阶段分开才知道该抓哪种 profile。一次排查可以从应用指标开始记录入口排队、业务处理、数据库调用和响应写回的耗时。确认问题发生窗口后采集 goroutine、mutex、block 与 CPU profile采样前后要写下 Go 版本、GOMAXPROCS、容器配额和流量特征。不同窗口的 profile 混在一起火焰图很难说明问题。如果 block profile 指向 channel receive继续追查谁负责发送、是否存在取消分支未消费结果若 mutex profile 集中在连接池或缓存对象查看临界区是否包住了网络调用。CPU profile 不显著时runtime trace 还能显示 goroutine 是否长期处在 runnable 或 syscall 状态。修复不应一口气引入大量 worker。先用固定样本比较改动前后的等待时长、超时数和资源使用再逐步提高并发。对于连接池、队列长度和超时应保留能回退的配置。能解释“请求在哪里等”的证据比一句“服务卡住了”更适合写进复盘。采样接口本身也要受保护只允许内部网络调用采集结束后关闭或恢复鉴权。profile 可能暴露包路径和调用关系归档时应遵守与日志相同的访问控制。跨服务调用则附上 trace ID便于确认等待是否来自下游。比对时统一使用同一采样窗口。