composer install 离线失败是因为默认需联网校验 composer.lock 中包的元数据；可靠离线方案是：有网时执行 composer install --no-dev --prefer-dist --no-scripts --no-plugins 下载 ZIP 到缓存，再复制 vendor/ 和 composer.lock 到离线机并重跑该命令。
composer install 为什么离线会失败？
因为默认行为会访问 packagist.org 拉取 composer.lock 里记录的包元数据（比如哈希、版本约束），即使所有 ZIP 文件已缓存，composer install 仍会尝试联网校验。错误典型表现为：Could not fetch https://repo.packagist.org/packages.json 或 Failed to decode response。
真正能离线运行的是 composer install --no-scripts --no-plugins，但前提是：本地已有完整缓存 + composer.lock 未被篡改 + 所有依赖 ZIP 已提前下载好。
怎么提前把所有依赖 ZIP 下载到本地缓存？
关键不是靠 composer install，而是用 composer archive 或第三方工具批量拉取。最稳妥的方式是：在有网环境执行：
composer install --no-dev --prefer-dist --no-scripts --no-plugins
这会让 Composer 把所有 dist 包（ZIP/TAR）下进 vendor/composer/cache/，且不执行任何脚本或插件——避免触发意外网络请求。之后复制整个 vendor/ 和 composer.lock 到离线机即可。
-
--prefer-dist强制走 ZIP 下载，比--prefer-source更易缓存 -
--no-dev减少非必要包数量，降低缓存体积和校验负担 - 别用
composer update离线前生成 lock，它一定会联网
离线验证 checksum 是否匹配？
Composer 本身不提供独立校验命令，但它的完整性检查逻辑是：读取 composer.lock 中每个包的 dist.shasum 字段，跟本地解压前的 ZIP 文件做 SHA256 对比。你可以手动复现：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
进入缓存目录（如 ~/.composer/cache/files/vendorn/name/），找到对应 ZIP，运行：
shasum -a 256 vendor-name-package-1.2.3.zip
结果应与 composer.lock 里该包的 dist.shasum 值完全一致。注意：
- Windows 用户需用
certutil -hashfile xxx.zip SHA256替代shasum - 如果 ZIP 被解压过，校验值就失效了——必须校验原始 ZIP
-
composer install --dry-run在离线时会报错，不用于校验，仅用于模拟安装路径
为什么 vendor 目录复制过去还报 hash 不匹配？
常见原因不是网络问题，而是文件系统或时区导致的解压行为差异。例如：
- macOS 上 ZIP 默认保留扩展属性（xattr），解压后可能多出隐藏文件，影响
vendor/整体哈希 - 某些 CI 环境用
unzip -o强制覆盖，但没清空旧文件，残留的 .git/ 或测试文件干扰了 Composer 的包扫描 -
composer.lock里记录的是 dist 包的 shasum，但你复制的是已解压的vendor/—— 这个目录本身没有校验机制，Composer 不会去算整个 vendor 的哈希
所以离线部署唯一可靠路径是：带缓存 ZIP + 带 lock 文件 + 在目标机上跑一次 composer install --no-dev --prefer-dist --no-scripts --no-plugins。
真正容易被忽略的点是：composer.lock 必须由同一版本 Composer 生成并消费，低版本 Composer 可能无法识别高版本新增的 lock 字段（比如 platform-check），直接拒绝执行——离线前务必确认两端 Composer 版本一致。
