Composer install 不支持真正断点续传，因其本质是依赖解析与安装的组合流程，网络中断后需重新解析锁文件、校验哈希、解压未完成包；优化方式包括使用--no-scripts--no-plugins、确保lock完整、换国内镜像源、启用缓存、手动清理失败包目录及暂存vendor进度。
composer install 为什么不能真正断点续传
因为 composer install 本身不支持断点续传——它不是下载器，而是依赖解析 + 包安装的组合流程。网络中断后重跑，会重新解析 composer.lock、重新校验哈希、重新解压所有未完成的包，看似“继续”，实则重复大量工作，低带宽下反而更耗时。
用 composer install --no-scripts --no-plugins 缩短单次失败代价
跳过脚本和插件执行能显著减少非下载类耗时，尤其在 CI 或受限环境里。失败后重试时，只要 vendor/ 已部分存在，Composer 会跳过已成功安装的包（基于 composer.lock 和 vendor/composer/installed.json 的比对），只补漏没下完的。
- 务必先确保
composer.lock文件完整且未被修改 - 不要加
--prefer-dist（默认就是），避免意外触发--prefer-source导致 clone 大仓库 - 如果之前失败卡在某个包解压阶段，可手动删掉对应
vendor/<package-name></package-name>目录再重试
换国内镜像源 + 启用 cache-dir 是最有效提速手段
低带宽本质是下载慢，不是 Composer 逻辑卡顿。镜像源解决的是 DNS、路由、TLS 握手、CDN 距离三重瓶颈；本地缓存则让重复安装（如重装、切分支）直接复用，跳过网络环节。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 确认缓存启用：
composer config -g cache-dir，默认是~/.composer/cache，无需额外配置 - 注意：某些私有包若未同步到镜像，需单独配置
repositories，否则会回退到官方源导致卡住
实在要“暂停”，用 git stash + vendor/ 临时保留更可靠
与其等 Composer 自己恢复，不如主动保存进度：把已下载解压好的 vendor/ 打包压缩，或用 git stash --include-untracked 暂存（前提是 vendor/ 未被 .gitignore 排除）。下次恢复时，解压回原位，再跑 composer install --no-scripts --no-plugins 补全剩余。
- 慎用
composer dump-autoload在中断后单独执行——它不检查包完整性，可能掩盖依赖缺失 -
vendor/目录权限、符号链接、Windows 下长路径都可能让“续传”失败，比重新下载还麻烦
真正的瓶颈不在 Composer 命令本身，而在你连的是哪个源、缓存有没有生效、以及 vendor 目录是否被当成“中间产物”随意清理。
