Composer报“无效路径”错误主因是COMPOSER_VENDOR_DIR环境变量、已废弃的config.vendor-dir字段与硬编码的require语句三者不一致；Composer 2.0+彻底废弃config.vendor-dir，仅COMPOSER_VENDOR_DIR生效且优先级最高，需同步更新require路径、IDE索引及部署脚本。
Composer 报“无效路径”错误，90% 不是路径本身非法，而是 COMPOSER_VENDOR_DIR 环境变量、废弃的 config.vendor-dir 字段、或 require 语句中硬编码的 vendor/autoload.php 三者不一致导致的加载断裂。换镜像解决不了这个问题，必须先理清路径控制权归属。
为什么 vendor 目录没按 composer.json 里写的路径生成？
Composer 2.0+ 已彻底废弃 config.vendor-dir 字段——即使你写了 "vendor-dir": "lib/vendor"，它只会警告 The "config.vendor-dir" option is deprecated，且完全不生效。
- 真正起作用的是环境变量
COMPOSER_VENDOR_DIR，优先级最高，覆盖所有配置 - 临时验证：运行
COMPOSER_VENDOR_DIR=./libs composer install，看./libs是否被创建；若成功，说明问题出在环境变量未设或设错 - 全局持久化：在系统级 shell 配置（如
/etc/profile或~/.bashrc）中加export COMPOSER_VENDOR_DIR="/path/to/vendor"，然后source生效 - 宝塔面板用户注意：网站计划任务、PHP 执行脚本默认以
www用户运行，需确保该用户环境也加载了该变量（比如写进/www/server/php/81/etc/php-fpm.d/www.conf的env[COMPOSER_VENDOR_DIR]）
require 'vendor/autoload.php' 报错却找不到文件？
这不是 Composer 没装好，而是代码里 require 语句写死了路径，和实际 vendor 位置脱节。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 如果用了
COMPOSER_VENDOR_DIR，所有require必须同步改成动态路径，例如：require __DIR__ . '/libs/autoload.php';（假设COMPOSER_VENDOR_DIR=./libs） - 不要依赖
composer dump-autoload来“修复路径”，它只重生成自动加载映射，不移动任何文件 - IDE（如 PHPStorm）可能缓存旧
vendor的符号索引，需手动执行 File → Reload project from Disk 或清空索引 - 部署脚本、CI 配置中硬编码的
vendor/autoload.php必须一并更新，否则运行时仍失败
换国内镜像后路径报错更频繁？
镜像源本身不改路径逻辑，但会放大配置冲突——因为换源常伴随 composer update 或 install，触发完整依赖重解析，暴露出原本被忽略的路径不一致问题。
- 确认镜像配置正确：运行
composer config -g repo.packagist，输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null或含packagist.org都说明镜像没生效 - 项目级镜像优先级高于全局，进项目目录后执行
composer config repo.packagist，若返回 URL，说明项目级配置已屏蔽全局设置 - 某些私有包或
path类型仓库会绕过镜像直连，但它们的安装路径仍受COMPOSER_VENDOR_DIR控制，不能混为一谈 -
composer.lock里记录的是原始 dist URL，执行composer update --lock可强制刷新为镜像地址，但不影响 vendor 目录位置
最易被忽略的一点：环境变量 COMPOSER_VENDOR_DIR 在宝塔、Docker、CI 中常被不同用户或进程隔离，必须逐层确认是否真正加载——不是“我设了”，而是“它读到了”。
