最推荐且稳定的方式是在 composer.json 顶层配置 "vendor-dir": "lib/vendor"，删旧 vendor 后运行 composer install；环境变量和命令行参数仅适合临时场景，且需同步更新 autoload 路径与 IDE 配置。
composer.json 里用 vendor-dir 指定路径最直接
修改 vendor 目录名，本质是告诉 Composer 把包装到哪去，不是后期重命名文件夹。唯一推荐、稳定生效的方式是在项目根目录的 composer.json 中配置 vendor-dir 字段。
常见错误是改完 vendor 文件夹名字后运行 composer install，结果被清空重建回默认名——因为 Composer 根本没被告知要换地方。
- 在
composer.json的顶层（和require同级）加一行："vendor-dir": "lib/vendor"（路径可自定义，支持相对路径） - 删掉现有
vendor目录（如果已存在） - 运行
composer install或composer update，新目录会按配置创建 - 注意：该配置只对当前项目生效，不污染全局
全局配置 COMPOSER_VENDOR_DIR 环境变量也行，但慎用
环境变量方式适合 CI/CD 流水线或临时调试，不适合长期项目维护。它会覆盖所有项目的 vendor-dir 配置，容易引发意外行为。
比如你在 shell 里执行 export COMPOSER_VENDOR_DIR=../shared-vendor，接着进不同项目跑 composer install，所有项目都会往同一个地方写包——冲突风险高。
- Linux/macOS：在终端执行
export COMPOSER_VENDOR_DIR="my-vendor"再运行 Composer 命令 - Windows（CMD）：用
set COMPOSER_VENDOR_DIR=my-vendor - 该变量优先级高于
composer.json中的vendor-dir，但低于命令行--vendor-dir参数 - PHP 代码里读不到这个变量，
__DIR__ . '/vendor'这类硬编码依然会失效，需同步调整自动加载逻辑
composer install --vendor-dir 是一次性覆盖方案
命令行参数适合单次操作，比如部署脚本中临时指定路径，避免改配置。但它不会写入 composer.json，下次不加参数就回归默认。
典型误用场景：有人想“先试试”，执行了 composer install --vendor-dir=ext，之后直接跑 composer update，结果包又装回 vendor ——因为 update 没带参数，也不读上次的临时设置。
- 必须每次需要时都显式加上
--vendor-dir，例如：composer update --vendor-dir=libs - 参数值不支持波浪号（
~）或环境变量展开，只能写实际路径，如./packages - 搭配
--no-scripts使用时要注意：某些包的安装脚本可能硬依赖vendor/autoload.php默认位置，路径一变就报错
改完路径后 autoload 和 IDE 支持要手动跟上
Composer 只管装包，不负责通知其他工具。路径一变，vendor/autoload.php 就不在原来位置了，所有依赖它的代码、测试、IDE 自动补全都会断。
最常踩的坑是：改了 vendor-dir，但 index.php 里还是 require 'vendor/autoload.php'，直接 Fatal error: require(): Failed opening required。
- 检查所有
require/include语句，把'vendor/autoload.php'改成新路径，如'lib/vendor/autoload.php' - PHPStorm 等 IDE 不会自动识别新 vendor 路径，需在
Settings > PHP > Include Paths中手动添加对应目录 - 运行
composer dump-autoload确保 autoloader 生成在新位置；若用classmap，记得确认映射路径是否仍有效 - Git 用户注意：
vendor/通常在.gitignore里，新目录名（如lib/vendor）也要加进去，否则可能误提交
路径改起来很快，但上下游联动的地方散落在代码、配置、工具链里，漏掉任意一处都会让项目跑不起来。尤其当团队协作或持续集成时，vendor-dir 必须显式声明在 composer.json 中，不能靠环境变量或口头约定。
