ps显示RUNNING但HTTP无响应，是内核态I/O阻塞导致的不可中断睡眠（D状态），非进程崩溃；需通过top查%wa>30%、ps查D状态进程、cat /proc/PID/stack确认ext4/overlayfs等I/O路径、iotop定位高IO进程，并重点排查日志写满、容器磁盘饱和或CGO库引发的阻塞。
ps显示RUNNING但HTTP无响应，先看%wa和D状态
这不是进程崩溃，而是内核态I/O阻塞导致的不可中断睡眠（D状态）。Go runtime本身不主动刷盘，但只要调用了os.Open、log.Write、http.ServeFile或依赖CGO的库（如go-sql-driver/mysql、archive/zip），就可能卡在系统调用里。
执行top，重点盯住%wa列：超过30%就要警觉；再执行ps aux | grep yourbinary，如果看到进程状态是R或S但实际无响应，立刻补查ps -eo stat,pid,cmd | grep "^D"——有输出就基本坐实I/O假死。
-
cat /proc/$(pgrep -f yourbinary)/stack若出现__generic_file_read、ext4_file_read_iter或overlayfs，说明正卡在文件读路径上 -
strace -p $(pgrep -f yourbinary)大概率停在read()、write()或openat()上，不是CPU忙，是等磁盘回包 - 容器环境优先检查
/var/lib/docker所在分区，iostat -x 1看%util是否持续100%，同时await> 100ms
日志直写/dev/pts/0或单一大文件，是高频诱因
Go标准库log包不带轮转，很多服务直接log.SetOutput(&os.File)写到固定路径。一旦没配logrotate或应用自身没做切割，日志文件可能膨胀到几十GB。此时write()会因ext4 journal压力或磁盘空间不足而阻塞数秒以上。
紧急验证：df -h看根分区或/var/log挂载点是否≥95%；ls -lh /path/to/app.log若>2GB，基本就是它。
- 临时缓解：
truncate -s 0 /path/to/app.log（清空内容，不删文件，避免破掉文件描述符） - 根本解：改用
lumberjack或zerolog等支持轮转的logger，或把log.SetOutput指向os.Stderr并由容器运行时接管日志（如Docker的json-file驱动） - 警惕
log.SetOutput(os.Stderr)在容器中仍走/dev/pts/0——底层仍是磁盘缓存，尤其当宿主机IO已饱和时
用iotop -oP锁定真凶，别只信top的CPU%
top的%CPU对D状态进程完全失真，它们不占CPU但会推高load average。必须用iotop确认是不是你的Go进程在DISK READ/WRITE列排第一。
若iotop -oP没结果，说明要么IO负载还没打满，要么进程正卡在内核路径里没发出新IO请求（比如阻塞在openat()等待NFS响应）。这时要补查：
-
lsof -p $(pgrep -f yourbinary)看打开的文件是否集中在某个大日志、归档包或数据库文件上 -
cat /proc/$(pgrep -f yourbinary)/io重点关注read_bytes和write_bytes是否异常高（比如>100MB） - 容器内运行时，
docker stats --no-stream yourcontainer看blkio部分，和宿主机iostat比对是否一致
别忽略GODEBUG=madvdontneed=1和mysql驱动超时
某些内核版本下，GODEBUG=madvdontneed=1会让Go在GC后主动调用madvise(MADV_DONTNEED)，引发额外I/O抖动，尤其在SSD寿命衰减或云盘吞吐见顶时更明显。
而go-sql-driver/mysql的readTimeout/writeTimeout设得太长，网络卡顿会转成I/O等待——连接没断，但read()一直挂起，最终拖垮整个goroutine池。
- 临时关闭
GODEBUG：启动时去掉该环境变量，观察D状态是否减少 - MySQL连接字符串里显式加
timeout=5s&readTimeout=5s&writeTimeout=5s，避免单个慢查询拖死全局 - archive/zip解压时频繁
stat元数据也会触发大量小IO，考虑用io.Copy配合bufio.NewReaderSize(f, 1提升缓冲区
真正难排查的是那些不常写磁盘、但某次批量操作（如定时归档、大文件上传回调）突然触发I/O夯住的场景。这时候/proc/PID/stack和iotop -oP的时间窗口稍纵即逝，建议提前在关键路径加runtime/pprof.Lookup("goroutine").WriteTo快照，而不是等假死后再手忙脚乱。
