Composer vendor目录位置必须在项目composer.json中通过config.vendor-dir显式声明，环境变量COMPOSER_VENDOR_DIR仅在无composer.json时生效；修改后需手动删除旧vendor并刷新IDE库路径。
Composer 的目录位置不能靠全局配置一劳永逸地“固定”，必须在每个项目根目录下通过显式声明，否则默认始终落在当前目录下。
为什么
环境变量经常不生效
很多人试过在 shell 里执行
，却发现
还是把包装进当前
。这是因为：Composer 只在未找到项目级
时才退回到环境变量；一旦项目有
，它会优先读取其中的
，完全忽略环境变量。
环境变量仅对无
的临时场景（如全局 require）有效
CI/CD 中若用
，但容器内已挂载了含
的代码，则该变量被静默忽略
Windows 下用
后仍无效，大概率是这个原因
正确改 vendor 路径：只改
的
段
这是唯一稳定、可提交、可复现的方式。编辑项目根目录下的
，确保包含如下结构：
之后运行
或
，
就会创建在
下。注意：
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
路径是相对于
所在目录的，不支持绝对路径（如
会被当作相对路径处理，最终生成奇怪的嵌套目录）
修改后旧
不会自动删除，需手动
，否则 Composer 可能复用旧文件导致 autoload 错误
如果用了
或
，无需调整路径——Composer 自动生成的
会自动适配新位置
多项目共享 vendor？别硬改，用 symlink 或 workspace 更可靠
有人想让多个项目共用一个
目录来省空间或加速安装，但这会引发依赖冲突（A 项目要 guzzlehttp/guzzle:^7，B 项目要 ^8）。强行配置
在跨 Git 仓库时极易出错：
不同项目
冲突，
会相互覆盖
PHPStan / Psalm 等静态分析工具可能因路径不一致报错
部署时若只传单个项目，
根本不存在，直接崩
真正可行的做法是：
开发期用
+
repository 指向本地包，实现软链接式复用
Monorepo 场景用
（需插件如
）管理多
CI 缓存用
+ 缓存
，比共享
更安全
最常被忽略的一点：
改动后，IDE（如 PHPStorm）的自动导入和跳转会短暂失效，需要右键点击新
目录 → “Mark as → Libraries Root”，否则类型提示就断了。
vendorcomposer.jsonCOMPOSER_VENDOR_DIRexport COMPOSER_VENDOR_DIR=/path/to/vendorcomposer installvendor/composer.jsoncomposer.jsonconfig.vendor-dircomposer.jsondocker run -e COMPOSER_VENDOR_DIR=...composer.jsonset COMPOSER_VENDOR_DIR=...composer.jsonconfigcomposer.json
{
"config": {
"vendor-dir": "lib/vendor"
}
}
composer installcomposer updatevendorlib/vendor/composer.json/var/www/vendorvendor/rm -rf vendorautoload.filesautoload.psr-4vendor/autoload.phpvendor"vendor-dir": "../shared-vendor"composer.lockcomposer update../shared-vendorcomposer create-projectpathcomposer workspacebmitch/chiselcomposer.jsoncomposer install --no-interaction --prefer-dist~/.composer/cachevendorvendor-dirvendor