vendor-dir 配置仅在首次安装或清空后重装时生效，需手动删除旧 vendor 目录并更新所有显式引用路径（如 autoload.php、scripts），且须检查 ide、ci/cd 等工具是否硬编码 vendor 路径。

vendor-dir 配置确实能改 Vendor 目录名，但只在项目初始化时生效

直接改 composer.json 里的 "vendor-dir" 并不会重命名已存在的 vendor 目录——Composer 只在首次运行 composer install 或清空后重新安装时读取该配置。已有的 vendor 不会自动迁移，也不会被删除。

常见错误现象：composer install 后目录名没变，或者报错 Could not delete vendor/autoload.php，本质是 Composer 仍试图往旧路径写文件。

• 必须先手动删掉现有 vendor 目录（或重命名备份）
• 确保 composer.json 的 config 区块已正确定义：

  "config": {
    "vendor-dir": "lib"
  }

• 再运行 composer install 或 composer update，新目录才会按配置创建

修改 vendor-dir 后，autoload 和脚本路径要同步调整

Composer 不会自动更新 autoload.php 中的路径引用，也不会改写第三方包里硬编码的 vendor/ 字符串。如果你把目录改成 lib，但代码里还写 require 'vendor/autoload.php'，就会报错 failed to open stream。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 所有显式引用 vendor/autoload.php 的地方，都要同步改成 lib/autoload.php
• 自定义的 scripts（如 post-install-cmd）中涉及 vendor 路径的命令，也要更新
• composer dump-autoload 生成的类映射仍正确，因为它是基于 vendor-dir 配置动态解析的，无需手动干预

全局配置 vs 项目配置：优先用项目级 config

虽然可以用 composer config -g vendor-dir /path/to/global/vendor 设置全局 vendor-dir，但这会影响所有项目，且与项目级配置冲突时行为不可控。实际项目中几乎不用全局改法。

• 项目级配置写在 composer.json 的 config 下，作用范围明确、可版本控制
• 全局配置只适合极少数场景（例如 CI 环境统一缓存路径），且不能覆盖项目级 vendor-dir
• 执行 composer config vendor-dir（无参数）可查看当前生效值，确认是否读取到了预期配置

某些工具链会硬依赖 vendor 目录名，改名需谨慎

不是所有生态组件都尊重 vendor-dir 配置。比如某些 IDE（PHPStorm）的自动补全、静态分析工具（Psalm、PHPStan）、甚至部分 Docker 构建脚本，可能默认查找 vendor/ 并硬编码路径。

• 改名前先检查 CI/CD 脚本、IDE 配置、部署工具是否含 vendor 字符串
• Laravel 的 artisan optimize（旧版）或 php artisan config:clear 不受影响，但自定义的 bootstrap/autoload.php 若存在，必须手动更新
• 如果只是想隔离依赖（比如多项目共享），更稳妥的方式是用 COMPOSER_VENDOR_DIR 环境变量临时覆盖，而非永久改名

改名本身很简单，难的是后续路径一致性——只要有一处漏改，就会在某个环境或某个命令里突然崩掉。建议改完立刻跑一遍完整流程：删 vendor → install → 执行 autoload → 运行一个带依赖的单元测试。