必须设置环境变量GODEBUG=mutexprofile=1才能开启pprof锁竞争检测，该变量需在go run或启动二进制前设置，代码内设置无效；开启后需足够锁争用（如压测）且仅统计阻塞超1ms的sync.Mutex/sync.RWMutex写锁。
怎么开启 pprof 的锁竞争检测
Go 自带的 runtime/pprof 在默认情况下不采集锁竞争数据，必须显式启用。这不是加个 flag 就行的事，得在程序启动时注入特定的运行时行为。
- 必须设置环境变量
GODEBUG=mutexprofile=1（注意是等号，不是空格），否则mutexprofile 始终为空 - 这个变量要在
go run或启动二进制前设置，写在代码里或os.Setenv里都无效 - 开启后，
<a href="https://www.php.cn/link/c43ccefdf21cc037c57d54db312648ff">https://www.php.cn/link/c43ccefdf21cc037c57d54db312648ff</a>才会有真实数据，否则返回 “profile is empty”
示例启动方式：
GODEBUG=mutexprofile=1 go run main.go
为什么 /debug/pprof/mutex 返回空或 “no data”
最常见原因是没触发足够多的锁争用——pprof 的 mutex profile 是采样型的，只记录实际发生阻塞且等待时间超过阈值的锁操作（默认 1ms），不是所有 sync.Mutex.Lock() 都会上报。
- 单次请求、低并发场景几乎看不到数据；需要持续压测（比如用
hey -z 30s -c 50 <a href="https://www.php.cn/link/cbb686245ece57c9827c4bc0d0654a8e">https://www.php.cn/link/cbb686245ece57c9827c4bc0d0654a8e</a>） - 如果用了
sync.RWMutex，注意它只在写锁冲突时计入 mutex profile，读锁竞争不统计 - 检查是否误访问了
/debug/pprof/block（那是 goroutine 阻塞，不是锁）或拼错了路径
怎么看懂 mutex profile 的火焰图和文本输出
go tool pprof 解析出来的结果，默认按“阻塞时间总和”排序，但真正关键的是 “fraction of time blocked” 和 “cum” 列，它们指出哪些调用路径贡献了最多锁等待。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go tool pprof <a href="https://www.php.cn/link/c43ccefdf21cc037c57d54db312648ff?debug=1">https://www.php.cn/link/c43ccefdf21cc037c57d54db312648ff?debug=1</a>获取原始采样数据 - 在交互式 pprof 中输入
top查看热点锁调用栈；输入web生成火焰图（需安装 graphviz） - 注意：火焰图中宽 ≠ 调用频次高，而是「该路径下所有锁阻塞时间之和」大；窄但高的帧，可能意味着某次锁等待极长
- 如果看到大量
runtime.semacquire1出现在顶层，说明锁争用严重，但具体位置得顺着调用栈往下翻
容易被忽略的陷阱：MutexProfile 不等于锁性能瓶颈的全部
pprof 的 mutex profile 只捕获 sync.Mutex 和 sync.RWMutex 的争用，对以下情况完全无感：
-
chan通信造成的 goroutine 阻塞（要看blockprofile） - 数据库连接池耗尽、HTTP client timeout 等外部依赖导致的“假锁”现象
- 使用了自定义锁逻辑（比如基于
atomic或unsafe实现的无锁结构），pprof 不会追踪 - MutexProfile 默认每秒只采样一次，高频短时争用（如微秒级等待）可能漏掉
真要定位瓶颈，得把 mutex、block、goroutine 三个 profile 对着看，再结合业务逻辑判断哪一层在拖慢吞吐。
