Composer如何利用缓存实现离线安装 Composer网络依赖管理-composer-PHP中文网

composer缓存必须完整迁移files/、repo/、archived/三部分，缺一不可；需配合composer_disable_network=1、--prefer-dist及--no-scripts--no-plugins使用，并确保两端composer主版本号一致。

composer如何利用缓存实现离线安装 composer网络依赖管理

缓存目录必须完整迁移，不能只拷`files/`子目录

Composer 缓存不是简单把 ZIP 包扔进 ~/.composer/cache/files/ 就完事。真正生效的缓存结构包含三个关键部分：files/（包压缩包）、repo/（元数据 JSON）、archived/（composer archive 生成的归档）。少任何一个，composer install --prefer-dist 都会 fallback 到联网尝试。

常见错误是只复制 files/，结果日志里仍出现 Fetching https://repo.packagist.org/packages.json —— 因为没 repo/，Composer 根本不知道某个包的 dist.shasum 对应哪个 ZIP 文件。

迁移前用 composer config --global cache-dir 确认真实路径（Linux/macOS 默认 ~/.composer/cache，Windows 是 %LOCALAPPDATA%\Composer\cache）
打包时必须包含整个缓存根目录，不要过滤或跳过隐藏文件
离线机上先运行 composer config --global cache-dir /path/to/restored/cache，再执行安装命令

`COMPOSER_DISABLE_NETWORK=1` 是硬性前提，不是可选项

即使缓存齐全、composer.lock 正确，不设 COMPOSER_DISABLE_NETWORK=1 仍会失败。Composer 在解析锁文件阶段就会尝试访问 repo.packagist.org 获取包元数据，哪怕最终不用下载——这是校验逻辑的一部分，不是优化开关。

典型报错：Could not fetch https://repo.packagist.org/packages.json 或静默卡在 Loading composer repositories。这不是网络慢，是 Composer 主动发起的请求被阻断。

Workflow Decomposer

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

下载

Linux/macOS：执行前加 COMPOSER_DISABLE_NETWORK=1 前缀，如 COMPOSER_DISABLE_NETWORK=1 composer install --no-interaction --prefer-dist
Windows CMD：先 set COMPOSER_DISABLE_NETWORK=1，再运行命令
PowerShell：用 $env:COMPOSER_DISABLE_NETWORK="1"

`--prefer-dist` 和 `--no-scripts --no-plugins` 缺一不可

--prefer-dist 强制走 ZIP/TAR 安装路径，这是缓存生效的唯一通道；而 --no-scripts 和 --no-plugins 是防止某些包的 post-install-cmd 或插件（如 hirak/prestissimo）内部触发 HTTP 请求——它们不走 Composer 主流程，COMPOSER_DISABLE_NETWORK=1 拦不住。

如果锁文件里有 "type": "git" 或 "source" 条目（比如用了 dev-master 或私有 Git 仓库），--prefer-dist 会直接失败，因为缓存里没有对应 source 包。这时只能换稳定版约束，或改用 path 类型本地仓库。

验证是否真走缓存：加 -v 参数运行，看到 Installing monolog/monolog (2.4.0): Loading from cache 才算成功
若看到 Downloading https://... 或 Cloning https://...，说明某处配置或锁文件内容破坏了离线链路
私有包必须提前注册到 repositories，否则缓存不会存它，离线时直接报 Package not found

缓存版本兼容性容易被忽略

Composer 2.4 和 2.5 的缓存目录结构、哈希算法、元数据字段不完全一致。用 2.4 机器生成的缓存，在 2.5 离线机上可能命中失败，表现为“包存在但校验不通过”或反复提示 Cache is corrupted。

这不是权限或路径问题，是底层格式变更。尤其当项目用了 composer-plugin-api 或自定义 installer 时，差异更明显。

两端务必运行 composer --version，确保主版本号（如 2.5.x）完全一致
不建议混用全局安装和局部 composer.phar：全局 Composer 版本由 composer self-update 控制，局部 phar 文件需单独校验
若必须跨版本，优先选择完整 vendor/ 目录迁移方案，绕过缓存机制本身