在 composer.json 中通过 config.vendor-dir 指定新路径（如 "lib"），必须重新运行 composer install 才能更新 autoload.php；仅修改配置或重命名目录会导致类加载失败，且所有依赖 vendor 路径的环节（部署、IDE、服务器配置等）均需同步调整。
composer.json 里用 config.vendor-dir 指定新路径
Composer 默认把依赖装进 vendor 目录，改名最直接的方式是在项目根目录的 composer.json 里加配置。不是靠命令行参数或环境变量临时覆盖，而是写死在配置里，后续所有 composer install 或 composer update 都会生效。
常见错误是只改了 composer.lock 或手动重命名目录——这会导致 autoload 失败、类找不到，因为 Composer 的自动加载器（vendor/autoload.php）路径是生成时硬编码的。
- 在
composer.json的config字段下添加："config": { "vendor-dir": "lib" } - 路径支持相对路径（如
"lib"、"./packages"），不支持绝对路径（/var/www/vendor会被忽略） - 修改后必须重新运行
composer install（哪怕已有vendor），否则旧 autoload 文件不会更新 - 如果项目已提交
vendor到 Git，记得把旧目录从版本控制中删掉：git rm -r vendor
全局配置 vs 项目配置：优先级和适用场景
composer config --global 设置的 vendor-dir 对所有项目生效，但实际几乎没用——它只影响新初始化的项目（composer init），不影响已有项目的 composer.json 配置。真正起作用的是项目级的 config.vendor-dir。
- 全局设置示例：
composer config --global config.vendor-dir ./my-vendor→ 这个值仅在你新建项目且没写config时被读取 - 项目配置优先级永远高于全局，所以多人协作时，靠
composer.json统一声明才是可靠做法 - 某些 CI 环境会清空全局配置，导致行为不一致；项目内声明则稳定可预期
autoload 生成逻辑依赖 vendor-dir，改名后必须重生成
Composer 不是“把文件挪过去就完事”。它的 vendor/autoload.php 是根据当前 vendor-dir 值动态生成的，里面包含大量硬编码的路径字符串。比如 PSR-4 映射、classmap 路径、甚至 ClassLoader::setPsr4() 的参数都含目录名。
- 如果你只改了
composer.json但没运行composer dump-autoload或composer install，老 autoload 文件还在用旧路径，报错如：Class 'Foo\Bar' not found - 即使
vendor目录已重命名，也必须触发 autoload 重建——最稳妥就是跑一次composer install - 注意：某些 IDE（如 PHPStorm）缓存了 autoload 路径，改名后可能需要重启索引
自定义 vendor 目录对部署和 Docker 的影响
改名本身不改变依赖内容，但会影响构建流程。尤其当部署脚本或 Dockerfile 里硬编码了 vendor 路径时，容易出问题。
- Dockerfile 示例错误写法：
COPY vendor/ /app/vendor/
→ 应该用COPY lib/ /app/lib/或更推荐：不在镜像里 COPY vendor，改用composer install --no-dev在构建时安装 - 部署工具（如 Capistrano、Deployer）若依赖
vendor名字做符号链接，也要同步更新配置项，比如 Deployer 的shared_dirs列表 - PHP-FPM 的
open_basedir如果限制了/var/www/vendor，改名后要同步放开新路径，否则报failed to open stream: Operation not permitted
