离线更新包不可行，但可通过预缓存依赖实现“伪离线”安装：需确保 composer.lock 存在且未修改，所有 dist 包已完整存在于 Composer 全局缓存中，并保持 php 与 Composer 版本一致。
离线更新包根本不可行，但可以“伪离线”完成 install
Composer 本身没有真正的离线模式，composer update 或 composer install 在运行时必须连接 Packagist（或你配置的镜像）来解析依赖、校验哈希、下载 ZIP 或 git 元数据。所谓“离线更新”，实际是提前把所有依赖及其完整历史版本缓存好，再断网执行 composer install —— 这个操作只依赖本地 vendor/ 和 composer.lock，不发起网络请求。
关键前提是：composer.lock 文件必须已存在且未被修改；且所有 dist 包（ZIP/TAR）已完整存在于 Composer 全局缓存中。
- 运行过一次
composer install或composer update的机器，其缓存路径（如~/.composer/cache/files/）里会存下所有下载过的包 ZIP - 缓存目录可整体拷贝到目标离线机的对应路径（注意用户权限和路径一致性）
- 确保离线机上 PHP、Composer 版本与原环境一致，否则可能因
composer.lock中的platform或content-hash不匹配而拒绝安装
如何导出完整依赖包供离线部署
用 composer archive 只打包当前项目，不包含依赖；真正可行的是用 composer install --no-dev --prefer-dist --dry-run 配合脚本提取所有 dist URL，再用 wget 或 curl 批量下载——但更可靠的是直接复用 Composer 自身缓存。
推荐做法：
- 在有网环境中，用目标 PHP 版本 + 目标 Composer 版本（建议锁定如
composer self-update 2.5.8）执行composer install --no-dev - 确认
vendor/已生成、composer.lock未改动，然后打包整个vendor/+composer.lock+composer.json - 离线机上无需 Composer 命令，直接
rsync或解压覆盖即可；若需重装（如清理 vendor），则必须先同步缓存目录 - 若必须用
composer install（例如要触发 autoload 生成或插件执行），则确保~/.composer/cache/已就位，并加--ignore-platform-reqs规避 PHP 扩展缺失报错（但慎用，可能引发运行时错误）
缓存路径与跨平台搬运注意事项
Composer 缓存位置不是固定的：linux/macOS 默认为 ~/.composer/cache/，windows 是 %appDATA%Composercache。不同 Composer 版本缓存结构也不同（v1 和 v2 的 files/ 下哈希目录层级不同），混用会导致“Package not found”错误。
- 检查缓存完整性：进入
~/.composer/cache/files/，每个包目录名是vendor/name的 SHA256，里面应有多个version-hash.zip文件 - 不要只复制部分包；一个包缺一个 ZIP，
install就会失败并尝试回退到源站（此时离线即中断） - 使用
composer clear-cache后重新install再打包，可确保缓存干净无冗余 - docker 场景下，把缓存挂载为 volume 并复用，比每次 build 都下载更可控
为什么 update 一定不能离线
composer update 的本质是重新解析依赖图、比对版本约束、计算最优解、校验所有候选包的 composer.json 元数据——这些数据只存在于远程仓库，本地缓存不保存元信息（只有 dist ZIP 和少量 packages.json 索引，且索引本身也需定期更新）。
- 即使开了
packagist.org镜像，镜像也是动态同步的；离线时镜像元数据就失效 -
composer update --lock仅更新 lock 文件时间戳，不改变依赖版本，不算真正 update - 想“固定升级”，唯一办法是在有网环境跑完
update，提交新的composer.lock，再走上面的 install 流程
最常被忽略的一点：团队协作中，有人本地改了 composer.json 但没提交 composer.lock，导致离线机上 install 因 lock 缺失而报错——lock 文件不是可选，是离线安装的唯一依据。