Go服务卡在D状态是内核态I/O阻塞导致的不可中断睡眠，非进程崩溃；需通过/proc/PID/stack、iostat -x和iotop定位磁盘IO瓶颈，常见于日志写满、overlay2损坏或大文件读写阻塞。
Go服务卡在D状态但ps显示RUNNING
这不是进程崩溃，而是内核态I/O阻塞导致的不可中断睡眠（D state）。Go runtime本身不直接触发磁盘I/O，但一旦调用os.Open、log.Write、http.ServeFile或依赖的CGO库（如SQLite、某些加密/压缩包）执行文件读写，就可能卡住。此时ps aux | grep yourapp看到的仍是RUNNING，但实际无法响应HTTP请求、docker exec卡死、kill -15无反应。
验证方法：cat /proc/$(pgrep -f yourbinary)/stack。如果输出中反复出现__generic_file_read、nfs_wait_bit_killable、overlayfs或ext4_file_read_iter，基本可锁定是磁盘I/O路径夯住。
- 别只看
top的CPU%，D状态进程不占CPU但会推高load average -
strace -p $(pgrep -f yourbinary)大概率卡在read()、write()或openat()系统调用上 - 若服务跑在Docker里，优先检查
/var/lib/docker所在分区的%util和await
查iostat -x 1时%util持续100%但r/s和w/s不高
这说明磁盘不是被高频小IO打满，而是被少量大块IO（如日志刷盘、备份归档、大文件上传）长期占用。尤其当await > 100ms、svctm接近await时，问题不在队列堆积，而在设备响应慢——可能是云盘吞吐打满、NFS服务器过载、或本地SSD寿命衰减。
Go服务常见诱因：log.SetOutput(os.Stderr)直连终端（容器中常为/dev/pts/0，底层仍走磁盘缓存）、io.Copy未加缓冲直接读写大文件、或使用archive/zip解压时频繁stat元数据。
- 用
iotop -o -P确认是不是你的Go进程PID在DISK READ或DISK WRITE列排第一 - 检查是否启用了
GODEBUG=madvdontneed=1，它会让Go在GC后主动madvise(MADV_DONTNEED)，某些内核版本下会引发额外I/O抖动 - 若用
go-sql-driver/mysql，注意readTimeout和writeTimeout设得太长，网络卡顿会转成I/O等待
日志轮转没生效，log.Fatal反复写满磁盘
Go标准库log包不带轮转功能。很多服务直接log.SetOutput(&os.File)写到一个固定文件，一旦没配logrotate或应用自身没做切割，单个日志文件可达几十GB。此时write()系统调用会因磁盘空间不足或ext4 journal压力而阻塞数秒甚至更久。
现象：df -h显示根分区或/var/log所在挂载点Use% ≥95%，同时ls -lh /path/to/app.log发现文件异常巨大（>2GB）。
- 紧急处理：
truncate -s 0 /path/to/app.log清空内容（不删文件，避免破坏Go程序持有的fd） - 长期方案：改用
lumberjack或zap等支持轮转的logger，明确设置MaxSize（如100 * 1024 * 1024）和MaxBackups - 避免在
log.Fatal里拼接大量上下文——它会一次性写入，易触发大块I/O；改用log.Printf+os.Exit
容器环境overlay2元数据损坏引发IO HANG
Docker使用overlay2存储驱动时，如果宿主机突然断电或/var/lib/docker所在分区只读，lowerdir的inode信息可能损坏。Go服务启动后尝试openat(AT_FDCWD, "config.json", ...)或读取/proc/self/exe符号链接时，就会卡在overlayfs内核函数里，表现为整个容器假死。
验证：sudo ls -la /var/lib/docker/overlay2/*/merged 2>/dev/null | head -5。若大量行显示?????????? ? ? ? ? ? merged，说明元数据已乱。
- 临时恢复：
sudo systemctl restart docker（会重启所有容器） - 根治：
docker system prune -a --volumes清理无用数据，再重建镜像（确保Dockerfile里COPY不包含超大二进制） - 预防：宿主机挂载
/var/lib/docker时加noatime,nobarrier选项，减少元数据写入
真正麻烦的从来不是%util数字本身，而是D状态进程无法被信号中断、无法被gdb attach、甚至kill -9都失效——这时候你得直奔/proc/PID/stack和iostat -x，而不是翻Go代码找goroutine泄漏。
