最可靠方式是修改composer.json的config.vendor-dir为相对路径（如"libs"），并确保父目录存在、删除旧vendor后重装；或用composer_vendor_dir环境变量临时覆盖，但需同步更新autoload引用及ide配置。
改 vendor 目录位置只有两种真正可靠的方式：写死在 composer.json 的 config.vendor-dir 里，或者用 COMPOSER_VENDOR_DIR 环境变量临时覆盖。其他方法（比如改名、软链接、全局配置）要么失效，要么埋雷。
怎么在 composer.json 里永久改 vendor 路径
直接编辑项目根目录下的 composer.json，在顶层 config 字段里加 vendor-dir：
{
"config": {
"vendor-dir": "libs"
}
}
注意这几点：
-
vendor-dir值必须是相对路径（不能以/或./开头），也不能含..；libs会解析为项目根目录下的libs/ - 父目录（比如
libs）得提前存在，否则composer install报错Could not create directory - 改完必须手动删掉旧
vendor目录，再跑composer install或composer update—— Composer 不会自动迁移或清理旧文件 -
composer.lock文件本身不记录 vendor 路径，但队友拉代码后若没同步这个composer.json修改，composer install仍会生成到默认vendor/，导致两边路径不一致
怎么用环境变量临时换 vendor 路径
适合 CI/CD、Docker 或多环境切换场景，优先级高于 composer.json 配置：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：
COMPOSER_VENDOR_DIR=packages composer install - Windows CMD：
set COMPOSER_VENDOR_DIR=packages && composer install - PowerShell：
$env:COMPOSER_VENDOR_DIR="packages"; composer install - Dockerfile 中推荐用
ENV COMPOSER_VENDOR_DIR=/app/deps，避免污染镜像
关键提醒：
- 这个变量只影响当前命令执行过程，不写入任何配置文件，对其他项目完全无感
- 它只改安装位置，不影响
autoload.php生成逻辑——但你代码里require 'vendor/autoload.php'得同步改成require $_ENV['COMPOSER_VENDOR_DIR'] . '/autoload.php'或类似动态拼接 - IDE（如 PHPStorm）不会自动感知这个变量，得手动在
Settings → PHP → Include Paths中添加新路径
改了 vendor 路径后，autoload 和 bin 怎么跟上
vendor/autoload.php 是硬编码路径的，不是“智能”文件。路径一变，它里面所有 require __DIR__ . '/xxx' 就全指向错地方：
- 删旧
vendor后跑完整composer install，不是composer dump-autoload—— 后者只刷新类映射，不重建autoload.php文件头 - 检查新生成的
autoload.php文件第一行，确认它引用的是正确子路径，例如：require __DIR__ . '/libs/composer/autoload_real.php'; -
vendor/bin/下的可执行脚本（如phpunit）也会移到新路径下，比如变成libs/bin/phpunit；CI 脚本里所有调用都得更新路径 - 如果项目用了
autoload-dev或自定义 PSR-4 映射，不用改composer.json里的 autoload 配置——那些路径始终相对于项目根目录解析
哪些做法看起来省事，实际千万别碰
这些操作短期看似成功，长期必出问题：
- 手动把
vendor/改名或移动：autoload 机制依赖目录名和内部路径一致性，改名后Class not found是大概率事件 - 用软链接（symlink）指向新路径：Docker 容器内、Windows 子系统或某些 IDE 对符号链接支持不稳定，
getcwd()和__DIR__行为可能错乱 - 在全局配置里设
composer config -g vendor-dir /path：所有项目被强制统一路径，协作时极易因本地全局配置差异导致vendor冲突、autoload 失败 - 在
composer.json顶层写"vendor-dir": "libs"（不套config）：这是旧版废弃语法，新版 Composer 直接忽略
最麻烦的不是路径本身，而是那些散落在代码、CI 脚本、IDE 设置、Dockerfile 里的硬编码引用——它们不会随 vendor-dir 自动更新，得人工逐个核对。漏掉一个，就卡在 Class not found 上半天。
