composer diagnose 不检测 ulimit 限制，因其仅做静态检查（启动、配置、网络、权限），不模拟 install 的并发下载负载；而 composer install 并行请求会瞬间耗尽文件描述符，导致 curl error 23 或静默卡死，需手动执行 ulimit -n 验证并调高软硬限制。

composer diagnose 不会检测 ulimit 限制，它压根不碰系统资源配额——这是你看到 diagnose 显示 [OK] 却在 install 时卡住、报错或静默中断的最隐蔽原因之一。

为什么 ulimit 问题完全逃过 diagnose 检查

composer diagnose 只验证 Composer 自身能否启动、配置是否合法、基础网络是否通、文件权限是否可写。它不发起并发 HTTP 请求，也不 fork 子进程下载包，更不检查 ulimit -n（打开文件数）或 ulimit -u（最大进程数）这类系统级限制。

而 composer install 在解析依赖后，会并行发起数十个 cURL 请求（尤其用 --prefer-dist 时），每个请求都占用一个文件描述符。一旦超出 ulimit -n，就会出现：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• cURL error 23: Failed writing body（写入响应体失败）
• file could not be downloaded（但实际是连接建立后无法接收数据）
• 部分包下载成功，部分超时/中断，vendor/ 目录残留半截文件
• 无明确错误，命令卡死在 Downloading... 阶段

如何确认是不是 ulimit 导致的失败

别猜，直接测：

• 运行 ulimit -n，如果输出 ≤ 1024（尤其常见于 Docker 容器、CI runner 默认值），基本就是它
• 临时调高测试：ulimit -n 65536 && composer install —— 如果立刻变正常，就坐实了
• 看系统日志：dmesg | tail -10，若有 open files limit reached 或类似提示，就是 ulimit 触发内核拒绝
• Docker 中检查：docker exec -it your-container sh -c 'ulimit -n'，很多基础镜像默认设为 1024

在不同环境里怎么改 ulimit

改完要重新启动 shell 或容器，否则无效：

• Linux/macOS 本地终端：在 ~/.bashrc 或 ~/.zshrc 加一行 ulimit -n 65536，然后 source ~/.zshrc
• Docker（非 root 容器）：启动时加 --ulimit nofile=65536:65536；若用 docker-compose.yml，写：

  ulimits:
    nofile:
      soft: 65536
      hard: 65536

• GitHub Actions：在 job 步骤前加：

  run: |
    echo "Setting ulimit..."
    sudo sysctl -w fs.file-max=2097152
    ulimit -n 65536

• GitLab CI：在 .gitlab-ci.yml 的 before_script 里加 ulimit -n 65536（需 runner 支持）

为什么不能只靠 diagnose 就断定环境 OK

因为 composer diagnose 是静态检查，而 install 是动态执行。它不模拟真实负载，所以：

• 即使 diagnose 说 [OK]，ulimit、内存不足、DNS 缓存污染、代理 TLS 握手瓶颈这些全都不在它的雷达里
• CI 环境尤其容易中招——容器默认 ulimit -n 是 1024，但 diagnose 在空项目里跑得飞快，根本暴露不出问题
• 一旦遇到下载中断又没报具体错误，先查 ulimit -n，比重装 Composer 或换镜像来得快得多