Composer缓存必须完整迁移files/、repo/、archived/三部分，缺一不可；需配合COMPOSER_DISABLE_NETWORK=1、--prefer-dist及--no-scripts--no-plugins使用，并确保两端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 主动发起的请求被阻断。
工作流任务拆解与模型编排技能。使用场景：(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/目录迁移方案，绕过缓存机制本身
