vendor目录不能被多个项目直接共用，因其autoload.php硬编码了单项目的路径、PSR-4映射、classmap及依赖相对路径，导致类冲突、命名空间错位和files路径失效；官方唯一支持方式是COMPOSER_HOME+全局config.json配置vendor-dir；符号链接方案更可控，通过ln -s复用已构建vendor，兼容IDE且不改Composer逻辑；但composer.lock仍按项目锁定，共享vendor仅在依赖树完全一致时安全。
不能直接“跨项目调用 vendor 目录”，但可通过共享 vendor + 符号链接或 COMPOSER_HOME 全局配置实现物理复用。
为什么 vendor 目录不能被多个项目直接共用
Composer 的 vendor/autoload.php 是为单个项目生成的：它硬编码了当前项目的 composer.json 路径、PSR-4 映射、classmap 扫描范围，以及所有依赖包的相对安装路径。如果 A 项目 require B 项目的 vendor/autoload.php，会出现：
- 类名冲突（比如两个项目都装了
monolog/monolog，但版本不同） - PSR-4 命名空间指向错误源码目录（
"App\": "src/"对 B 项目有效，对 A 项目是错的） -
files自动加载的脚本路径失效（路径相对于 B 项目的composer.json，A 项目根本找不到）
COMPOSER_HOME + 全局 config.json 是唯一受支持的跨项目 vendor 共享方式
Composer 官方只允许在全局配置层级（而非项目级 composer.json）指定统一的 vendor-dir。必须配合 COMPOSER_HOME 使用：
- Linux/macOS：执行
export COMPOSER_HOME="/opt/composer-global" - 然后在
/opt/composer-global/config.json中写入：{"config": {"vendor-dir": "/opt/shared-vendor"}} - 之后所有项目运行
composer install，依赖都会装进/opt/shared-vendor，且自动加载器会按该路径生成
⚠️ 注意：vendor-dir 放在项目 composer.json 里完全无效——这是 Composer 的硬性限制，不是配置没生效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
用符号链接模拟跨项目调用（更可控，推荐）
不改 Composer 行为，只改文件系统视图。适合 CI/CD 或容器部署中复用已构建的 vendor：
- 先在某处（如
/mnt/shared/vendor）完成一次完整安装 - 在每个项目根目录下执行：
rm -rf vendor<br>ln -s /mnt/shared/vendor ./vendor
- 确保
/mnt/shared/vendor的权限对 Web 进程或 CLI 用户可读 - 项目仍用标准
require 'vendor/autoload.php'，无需修改代码或 IDE 配置
这个方案绕过了 Composer 的路径绑定逻辑，IDE 和调试器也认得 vendor 名字，兼容性最好。
容易被忽略的关键点
无论用哪种方式，composer.lock 仍按项目锁定——共享 vendor 不等于共享版本一致性。如果 A 项目要求 guzzlehttp/guzzle:^7.0，B 项目要求 ^8.0，它们无法共存于同一 vendor 目录。真正安全的跨项目复用，只适用于完全相同的依赖树，或你主动约束所有项目使用统一的 composer.lock 快照。
