断网时composer必须依赖composer.lock、本地缓存files/目录zip包及composer_disable_network=1三者协同，镜像代理因不存zip且需联网转发而完全失效。
断网时 Composer 无法联网，靠本地镜像代理本身解决不了问题——镜像只是加速通道，不是离线缓存。真应急必须提前准备 composer.lock + 本地缓存 + 离线模式三者协同，否则换什么镜像都无效。
为什么“本地镜像代理”在断网时根本不起作用
所谓“本地镜像代理”，比如用 proxy 或 nginx 反向代理 https://packagist.org，本质仍是转发请求。一旦团队断网，代理服务本身也拿不到上游响应，所有 composer install 请求都会卡在 Resolving packages... 或直接报 cURL error 7。
- 镜像代理不保存 ZIP 包文件，只缓存元数据（
packages.json），而安装阶段必须下载 dist 文件 - Composer 不会从代理的磁盘目录读取 ZIP，它只认
dist.url字段指向的远程地址 - 即使你把阿里云镜像整个 rsync 下来，没配
repositories指向本地路径，Composer 也完全感知不到
断网应急真正依赖的三个硬条件
容灾不是临时起意换源，而是提前固化可执行路径。缺任意一个，composer install 就必然失败。
-
composer.lock必须存在且未被修改：它是唯一能跳过依赖解析、直接按哈希拉包的依据 -
~/.composer/cache/files/目录需包含全部包的 ZIP 缓存：Composer 离线时只从此处提取并校验 SHA256 - 启动
COMPOSER_DISABLE_NETWORK=1环境变量：强制跳过所有网络请求，否则仍会尝试连接
验证是否齐备：运行 COMPOSER_DISABLE_NETWORK=1 composer install --no-progress。成功则说明已就绪；若报 Could not find package xxx，说明对应 ZIP 缺失，需补缓存。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
如何提前构建可离线的 vendor 缓存池
不能等断网才行动。CI 流水线或日常开发中，应把缓存同步作为固定步骤。
- 在联网状态下，用
composer install --prefer-dist --no-scripts --no-plugins安装，确保全走 ZIP 而非 git clone - 将
~/.composer/cache/files/打包归档（如tar -czf composer-cache-202607.tgz -C ~/.composer cache/files），存到 NAS 或 Git LFS - 断网后，在目标机器解压覆盖：
tar -xzf composer-cache-202607.tgz -C ~/.composer - 配合
COMPOSER_DISABLE_NETWORK=1和原有composer.lock即可秒级恢复
注意：vendor/ 目录不可直接复制——autoloader 生成逻辑与 PHP 版本、扩展强相关，跨环境可能失效。
项目级配置比“本地代理”更可控的实操细节
与其搭一套脆弱的反向代理，不如把镜像源写进项目，让 composer.json 自带容灾语义。
- 执行
composer config repositories.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会向
composer.json写入"repositories": {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}} - Git 提交后，所有成员 clone 即生效，无需各自配全局，也避免宝塔、Docker 等场景下用户权限错位
- 若某天阿里云镜像也挂了，只需改 URL 提交新 commit，CI 拉代码后自动切到腾讯云镜像，不用登录每台机器手动切
最容易被忽略的是：这种配置只影响元数据获取，ZIP 下载仍可能走原始源。所以必须搭配 --prefer-dist 和预缓存，否则断网时照样失败。
