离线环境下唯一可靠方式是提前在composer.json中写死config.vendor-dir且确保vendor不存在、composer.lock一致；COMPOSER_VENDOR_DIR和命令行参数均不可靠，必须用项目级静态配置，安装后需同步更新所有require语句和环境路径。
离线环境下，Composer 无法通过网络拉取插件或校验配置，所以唯一可靠的方式是提前在 composer.json 中写死 config.vendor-dir，且必须确保 vendor 目录不存在、composer.lock 与配置一致。
离线时 config.vendor-dir 是唯一生效路径配置
离线状态下，COMPOSER_VENDOR_DIR 环境变量和命令行参数（如 -d）都不可靠——前者在 Composer 2.x 中已被弃用，后者只改查找位置、不改安装路径。你只能依赖项目级静态配置：
-
composer.json必须位于项目根目录，且config.vendor-dir字段要写在最外层config对象下，值为相对路径（如"lib/vendor"），不能以/开头 - 离线前必须已执行过
composer install --no-scripts或完整安装，生成匹配该路径的composer.lock - 离线机器上首次运行
composer install前，务必确认当前目录下没有vendor文件夹，否则 Composer 会跳过安装或报路径冲突
离线安装后 autoload.php 报 Class not found 怎么办
不是 Composer 没装对，而是 PHP 还在找旧路径。因为 vendor/autoload.php 是生成时硬编码路径的入口文件，离线重装不会自动更新你代码里的 require 语句：
- 所有
require 'vendor/autoload.php'都得手动改成require __DIR__ . '/lib/vendor/autoload.php'（推荐用__DIR__而非固定字符串，避免部署层级变动） - 如果用了
include_path或open_basedir（常见于共享主机），需确认新路径（如/var/www/myapp/lib/vendor）已被显式加入白名单 -
composer dump-autoload在离线时无效——它不重建 autoload.php 入口文件，只刷新类映射；必须重装才能生成适配新路径的完整结构
为什么离线时 installer-paths 很可能失效
installer-paths 依赖 composer/installers 插件运行，而该插件本身也是个包，需要被安装并加载。离线时若未提前把 composer/installers 及其依赖打包进 vendor，整个机制就卡住：
- 即使
composer.json里写了extra.installer-paths，只要composer/installers不在vendor/里（或版本低于^2.0），Composer 会静默忽略该配置 - 目标包（如
wpackagist-plugin/akismet）还必须声明"type": "wordpress-plugin"，且该 type 被composer/installers支持——离线环境无法动态校验或补全这些元数据 - 验证是否生效的最直接方式：删掉
vendor和composer.lock，在离线机上跑composer install -vvv，观察输出中是否有Installing ... to [path]的重定向日志
离线场景下，路径配置的脆弱点不在“怎么写”，而在“谁来保证路径一致性”——composer.lock、autoload.php、PHP require 语句、bin 脚本调用、IDE 索引，全部必须同步对齐，漏掉任意一环都会导致运行时报错，且错误信息往往不指向真实原因。
