离线环境下composer install卡住主因是PHP进程超时而非网络问题；需同时设置process-timeout为0和php -d max_execution_time=0，因--no-network仅跳过远程请求，autoload生成、post-install-cmd脚本等本地操作仍受双重超时限制。
离线环境下，composer install 卡住不是因为网络慢，而是 Composer 仍会尝试解析依赖、生成 autoload、校验签名等——这些步骤本身可能超时，尤其当 vendor 目录结构复杂或 PHP 配置偏严时。
离线安装时为什么会触发超时？
即使设了 COMPOSER_DISABLE_NETWORK=1，Composer 仍会执行以下耗时操作：
- 递归扫描
vendor/下所有包的autoload规则（尤其含 symlink 或嵌套过深时） - 生成优化后的 autoloader（
composer dump-autoload --optimize行为） - 运行
post-install-cmd脚本（如php artisan config:cache），而这些脚本本身受 PHPmax_execution_time限制 - 某些版本在离线模式下仍会尝试访问本地缓存索引，I/O 延迟高时也可能被判定为超时
如何安全延长离线执行超时？
离线场景下，真正起作用的是两个独立层级的超时控制，必须同时处理：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
process-timeout：控制 Composer 主进程生命周期（如解析锁文件、生成 autoload 文件），推荐设为0（不限时）或至少1200（20 分钟）：composer config -g process-timeout 0 -
php -d max_execution_time：控制所有 PHP 脚本（包括post-install-cmd）执行上限，这是离线时最常被忽略的一层：php -d max_execution_time=0 composer install --no-network - 注意：离线时
--http-basic-timeout和http.timeout完全无效，不用配
为什么 --no-network 不等于“不超时”？
--no-network 只跳过远程请求，但以下行为仍会触发超时：
- Composer 默认对每个
scripts执行单独计时（5 分钟硬上限），不受process-timeout影响 - 若项目用了
fxp/composer-asset-plugin或自定义 installer，其内部逻辑可能自带超时判断 - PHP CLI 的
max_execution_time默认是 300 秒，一旦某个post-install-cmd脚本（比如生成大量缓存文件）跑满就会中断，报错类似Maximum execution time of 300 seconds exceeded - 某些 Docker 环境或 CI 平台（如 GitLab Runner）会在外部强制 kill 进程，此时 Composer 自身配置完全无效，得同步调高
timeout环境变量（如COMPOSER_PROCESS_TIMEOUT=0）
离线执行最易被忽略的点：不是网络超时，而是 PHP 进程自身被系统或 CLI 配置掐断。务必确认 php -d max_execution_time 和 process-timeout 同时生效，且脚本中没有硬编码的 set_time_limit(300) 类逻辑。
