go mod tidy 报 i/o timeout 或 write: no space left on device 是因磁盘空间不足导致，go 工具链在写入 go.sum、解压模块或生成临时文件时被系统拒绝，需检查 $gopath/pkg/mod、$gocache 和 /tmp 三处磁盘使用情况。
go mod tidy 报 I/O timeout 或 write: no space left on device
磁盘满时，go mod tidy 会卡住、静默失败，或报 write: no space left on device、I/O timeout、failed to write go.sum 等错误。这不是网络问题，也不是模块本身损坏，而是 Go 在写入 go.sum、缓存解压包、或生成临时校验文件时被系统拒绝——操作系统层面已无可用块空间。
关键点：Go 工具链在执行依赖操作时，会在多个位置写入数据，包括：
- 项目根目录下的
go.sum（追加/重写） -
$GOPATH/pkg/mod或$GOCACHE下的模块解压目录（需完整解压 ZIP 并校验） - 临时目录（如
/tmp）用于下载、校验、解包
任一路径所在分区满，都会导致失败，且错误提示往往不指向具体路径。
快速定位哪块磁盘被占满
别只看 df -h 的根分区，Go 依赖操作实际受三处空间影响：
-
df -h $GOPATH/pkg/mod—— 模块缓存主目录，默认在$HOME/go/pkg/mod -
df -h $GOCACHE—— Go 构建缓存，默认在$HOME/Library/Caches/go-build（macOS）或$HOME/.cache/go-build（Linux） -
df -h /tmp—— 下载和解包临时目录，尤其在代理慢或模块大时易堆积
常见陷阱：你清空了 ~/go/pkg/mod，但 /tmp 占用 98%，go mod tidy 仍失败；或者 $GOCACHE 被设到 SSD 小分区，而没意识到它默认每月不自动清理。
安全清理空间的实操步骤
不要直接 rm -rf $GOPATH/pkg/mod —— 这会丢掉所有缓存，下次 tidy 得全量重下；也不要只删 go.sum —— 它只是校验摘要，删了也没用。
- 先运行
go clean -cache清理构建缓存（$GOCACHE） - 再运行
go clean -modcache清理模块缓存（$GOPATH/pkg/mod），它比手动rm更安全，会跳过正在使用的条目 - 检查并清空
/tmp中以go-build、gomodcache开头的临时目录（注意：不要删整个/tmp，避免影响其他进程） - 若使用自定义
GOPROXY，确认其本地缓存目录（如goproxy.io的~/.goproxy）是否爆满
清理后，建议立即运行 go mod download（不带参数）验证能否拉取最小依赖集——它比 tidy 更轻量，能快速暴露残留空间问题。
预防下次再满：设置空间限额与自动清理
Go 本身不提供磁盘配额，但可通过环境变量和脚本控制增长：
- 限制模块缓存大小：设置
GOPATH到有足够空间的分区，并确保该分区有至少 5GB 可用（大型项目常需 10GB+） - 禁用构建缓存（仅调试时）：
go env -w GOCACHE=off，避免$GOCACHE无限膨胀 - 定期清理：在 CI 或本地开发机上加 cron / launchd 任务，每周运行一次
go clean -modcache -cache - 监控提醒：用
du -sh $GOPATH/pkg/mod | awk '{print $1}'配合阈值告警，比如超过 8GB 就发邮件
最易被忽略的一点：Go 在写入 go.sum 前会先写入临时文件（如 go.sum.tmp），再原子替换。如果磁盘只剩几十 KB，连这个临时文件都写不下，tidy 就会静默退出，不报错也不更新文件——此时必须人工检查磁盘，不能只等错误提示。
