composer install 断网失败是因为默认需实时连接 packagist.org 校验元数据和签名；可靠离线方案是提前在有网环境完成安装并打包整个 vendor 目录，目标机解压后执行 composer dump-autoload。

composer install 为什么断网就失败？

因为默认行为是去 packagist.org 实时拉取包元数据和 ZIP 文件，哪怕 composer.lock 已存在，composer install 仍会尝试连接远程仓库校验签名、检查更新状态——这步一断网就卡住或报 Could not fetch https://repo.packagist.org/packages.json。

用 --no-interaction 和 --prefer-dist 强制走本地缓存

Composer 默认启用缓存（~/.composer/cache），但断网时它不会自动降级使用已下载的 dist 包。必须显式告诉它“别联网、信缓存”：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• composer install --no-interaction --prefer-dist --no-plugins --no-scripts 是最稳妥组合：跳过交互、强制用压缩包（而非 git clone）、禁用插件和脚本（避免触发额外网络请求）
• --prefer-dist 关键：它会让 Composer 优先查本地 dist 缓存目录，只要之前成功装过同一版本，就能直接解压复用
• 如果仍报错 Failed to download xxx, package is not available，说明该包从未被缓存过——只能靠提前备份或离线镜像

提前导出 vendor 到另一台机器做离线镜像

真正可靠的断网方案不是临时补救，而是把 vendor 目录本身当“二进制依赖”来管理：

• 在有网机器上跑完 composer install 后，直接打包整个 vendor/ 目录（含所有 .git 和 composer.json 元信息）
• 把压缩包拷到目标机器，解压覆盖空 vendor/，再执行 composer dump-autoload 重建自动加载映射
• 注意：不能只复制 vendor/autoload.php 或部分目录——很多包的运行时逻辑依赖 vendor/bin/ 下的可执行文件或 vendor/composer/installed.json 的精确版本记录

用 composer archive 打包指定包（适合 CI/CD 场景）

如果项目依赖固定、更新不频繁，可用 Composer 内置归档功能生成离线包：

• composer archive --format=zip --dir=./offline-packages laravel/framework 9.53.0 会把指定包及其依赖打成 zip
• 但这个命令只打包单个包，不递归解决全依赖树；实际要用还得配合 composer depends 手动理清依赖链
• 更实用的是用 composer create-project --repository-url=file:///path/to/local/repo 搭本地 JSON 仓库，但这需要预生成完整 packages.json 和所有 dist 文件——工程量接近自建私有源

断网恢复的关键不在“怎么让 Composer 联网失败后继续跑”，而在于接受一个事实：Composer 本身没有真正的离线模式。所有所谓“断网可用”方案，本质都是把网络依赖提前转成文件依赖——要么靠缓存命中，要么靠 vendor 目录搬运，要么靠人工维护的包归档。漏掉任何一层（比如没备份 composer.lock、缓存被清理、vendor 权限不对），就直接回到原点。