go mod download卡在ulimit的典型表现是报“too many open files”，需通过ps、/proc/PID/limits和lsof三步定位真实限制；临时解决用ulimit -n 65536后立即执行go mod download，永久方案须分层配置shell、systemd、Docker及K8s。
确认 go mod download 是否真卡在 ulimit 上
“下载中断”不等于“文件数超限”，先排除网络、代理、GOPROXY 或模块本身不可用等干扰。最直接的验证方式是手动触发并观察错误类型：go mod download -x 开启调试输出，若末尾出现 open /tmp/go-build...: too many open files 或类似路径报错，才真正指向 fd 耗尽；如果卡在 Fetching ... 无响应、或报 lookup proxy.golang.org: no such host，问题不在 ulimit。
查清当前 go 进程实际生效的文件数限制
go mod download 是由 shell 启动的子进程，它继承的是启动它的 shell 的 rlimit，而非当前终端的 ulimit 值（尤其在 IDE、CI 或 systemd 环境中容易误判）。执行以下三步定位真实限制：
- 运行
ps -o pid= -C go获取正在运行的 go 进程 PID - 用
cat /proc/<pid>/limits | grep "Max open files"</pid>查看该进程软硬限制（注意不是ulimit -n输出） - 对比
lsof -p <pid> | wc -l</pid>，若数值接近软限制（如 1024），基本坐实瓶颈
常见陷阱：CI 环境（如 GitHub Actions runner）默认 ulimit -n 为 1024，且不读 /etc/security/limits.conf；Docker 容器内未显式传 --ulimit，也会沿用宿主机 init 进程的低限制。
临时绕过限制快速恢复依赖下载
无需改系统配置，立刻让 go mod download 跑通的方法是重设当前 shell 的 soft limit 并确保 go 进程继承它：
立即学习“go语言免费学习笔记（深入）”；
- 执行
ulimit -n 65536（普通用户可提升 soft 限，无需 root） - 紧接着运行
go mod download—— 此时新 fork 的 go 子进程会继承该值 - 若用 Makefile 或脚本封装，务必把
ulimit -n和go mod download放在同一行或同一 shell 会话中，避免被子 shell 隔离
注意：ulimit -n 只影响后续 fork 的进程，对已运行的 go 进程无效；也不要在 Go 代码里试图用 syscall.Setrlimit 去“修复”，因为 go mod download 是独立二进制，你控制不了它的启动时机。
永久解决需分层加固，不能只改 limits.conf
很多团队只改了 /etc/security/limits.conf 就以为万事大吉，结果 CI 或容器里依旧失败。必须按层级覆盖：
- Shell 登录用户：确认
/etc/security/limits.conf中有* soft nofile 65536，且pam_limits.so已启用 - systemd 服务（如 Jenkins agent、GitLab Runner）：在对应 service 文件中加
LimitNOFILE=65536，然后systemctl daemon-reload && systemctl restart xxx - Docker 构建：在
docker build命令加--ulimit nofile=65536:65536，或在docker-compose.yml的ulimits字段声明 - Kubernetes Pod：通过
securityContext.ulimits（v1.29+）或 initContainer 执行prlimit --nofile=65536 --pid 1
真正容易被忽略的是：Go 模块下载过程会并发拉取大量 .zip 和 go.mod，每个 HTTP 连接 + 临时解压文件都占 fd；即使你把 ulimit 调到 65536，若同时跑多个 go mod download 实例（如并行构建多个服务），仍可能撞上限。这时候得靠外层调度器做串行化或资源配额隔离。
