go语言死锁检测不触发文件系统卡死，因为os.file阻塞在syscall.read/write时goroutine状态为syscall而非waiting，checkdead()认为其仍可唤醒；需用strace、dmesg、lsof等系统工具诊断。
Go 语言运行时不会检测“文件系统死锁”，因为那不属于 Go 并发模型的管辖范围——open、read、write 等系统调用阻塞，只要底层 OS 还在处理（如 NFS 挂载卡住、ext4 journal hang、fuse 崩溃），Go runtime 就认为 goroutine 处于 syscall 状态，仍属 runnable，checkdead() 完全不触发。
为什么 fatal error: all goroutines are asleep - deadlock! 不会出现在文件系统卡死时
Go 的死锁检测只看 goroutine 状态，不看系统调用是否卡死：
- goroutine 调用
os.Open后陷入内核等待磁盘 IO 或网络存储响应 → 状态是syscall，不是waiting或semacquire→ runtime 认为它“随时可能醒来” - 哪怕 100 个 goroutine 全卡在
read()上，只要没进runtime.gopark（比如没等 channel、没等 mutex），checkdead()就直接跳过 - cgo 启用时（如
net/http、database/sql）进一步抑制检测，而文件操作本身常隐式触发 cgo（如 DNS 解析、getpwuid）
实际能用的文件系统阻塞诊断手段
这类问题本质是 OS 层面的挂起，需绕过 Go runtime，直接查系统状态：
- 用
strace -p <pid> -e trace=open,read,write,fsync</pid>看最后卡在哪条系统调用上，是否停留在read(3,或openat(AT_FDCWD, "/path", ... - 查挂载状态：
findmnt /your/mount/point看是否显示stale或timeout；NFS 用showmount -e server验证服务端可达性 - 检查内核日志：
dmesg -T | grep -i "nfs\|ext4\|fuse\|block"，常见线索如NFS: state manager: check lease failed或INFO: task XXX blocked for more than 120 seconds - 对 fuse 文件系统（如 gocryptfs、rclone mount），用
fuser -v /mount/point查谁在 hold fd，再结合lsof -p <pid></pid>看具体 fd 状态
pprof/block 和 go tool trace 在这里几乎无效
这两个工具依赖 Go runtime 的调度事件记录，但文件系统阻塞发生在内核态：
-
/debug/pprof/block只统计 Go 层同步原语（chan send、sync.Mutex.Lock、sync.WaitGroup.Wait）的阻塞，read()卡住不会出现在 block profile 里 -
go tool trace的 “Synchronization” 标签页也只展示 channel/mutex 相关事件，syscall.Read不会上报为阻塞点 - 唯一可能的间接线索：如果程序因文件阻塞导致 goroutine 积压，
/debug/pprof/goroutine?debug=2会显示大量syscall状态，但无法区分是磁盘慢还是真卡死
真正要定位文件系统级“假死”，得放弃 Go 工具链，回到 strace、dmesg、lsof 这套 Linux 基础组合 —— Go runtime 对此无感知，也无能力干预。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
