项目迁移后 Composer autoload 冲突主因是 vendor/autoload.php 中 DIR 指向旧路径、PSR-4 命名空间与文件声明不匹配、或 vendor 被跨项目复用；需验证 __DIR__、检查命名空间一致性、清空 COMPOSER_VENDOR_DIR 并重建 autoload。
项目迁移后 Composer autoload 冲突，90% 是因为路径映射失效或命名空间错位，不是代码问题，而是 vendor/autoload.php 里硬编码的 __DIR__ 指向了旧路径，导致 PSR-4 映射全部落空。
检查 vendor/autoload.php 的 __DIR__ 是否指向当前项目根目录
迁移后最常被忽略的一点：Composer 生成的 autoload.php 文件里有 __DIR__，它在生成时就被固化为绝对路径片段。如果项目从 /old/project 复制到 /new/project，但没重建 autoload，这个 __DIR__ 仍指向旧位置，所有 PSR-4 映射（比如 "App\": "src/"）都会基于错误根目录拼接，结果就是类文件根本找不到。
- 进入迁移后的项目根目录，运行：
php -r "echo __DIR__ . PHP_EOL; require 'vendor/autoload.php';" - 对比输出的
__DIR__路径是否与当前项目根目录一致；不一致就说明 autoload 是旧环境生成的 - 别信“我删过 vendor 重新
composer install”，如果执行命令时不在项目根目录下，或者设置了COMPOSER_VENDOR_DIR环境变量，依然会复用旧映射
PSR-4 命名空间与文件 namespace 不匹配（尤其 ThinkPHP 项目）
ThinkPHP 6 迁移时常见：文件放在 app/library/Payment.php，但类声明是 namespace library;，而 composer.json 里却配了 "applibrary": "app/library/"。Composer 会严格按前缀匹配，applibrary ≠ library，中间差一个 app，自动加载器直接跳过该文件。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 确认每个 PHP 文件顶部
namespace声明，必须与composer.json中 PSR-4 键的值**完全一致**，包括末尾反斜杠（如"App\": "src/"对应namespace App;） - TP5 升级到 TP6 时，原
thinkRequest已移到think acadeRequest，若自定义类还引用旧命名空间，autoload 找不到是必然的 - 检查
vendor/composer/autoload_psr4.php，搜索你的命名空间前缀，看对应路径是否真实存在且可读
vendor 目录被跨项目复用或软链接导致映射错乱
多个 ThinkPHP 项目共用同一份 vendor（比如通过软链接、Docker volume 共享、或误设 COMPOSER_VENDOR_DIR），是 autoload 失效的高发场景。因为 autoload_psr4.php 里记录的是相对于那个“原始生成 vendor 的项目”的路径，一换项目就全偏。
- 立刻检查系统环境变量：
echo $COMPOSER_VENDOR_DIR（Linux/macOS）或echo %COMPOSER_VENDOR_DIR%（Windows），如果非空，**必须清空** - 删除当前项目下的
vendor/和composer.lock - 确保在**当前项目根目录下**执行：
composer install --no-dev --optimize-autoloader - 完成后验证：
grep -A2 "think\" vendor/composer/autoload_psr4.php，输出值应为["vendor/topthink/framework/src/"]，而非其他路径
dump-autoload 后仍不生效？缓存残留比你想象的顽固
改完 composer.json 后只跑 composer dump-autoload -o 不够——旧的 autoload_*.php 文件可能还在内存或 opcache 里，甚至某些 CI 流程会跳过这步直接打包。
- 手动删掉
vendor/composer/autoload_*.php全部文件（保留installed.json） - 再执行：
composer dump-autoload -o --classmap-authoritative（--classmap-authoritative强制只走 classmap，绕过文件扫描，能快速暴露路径问题） - 如果用的是 Docker 或共享主机，确认 opcache 已清除：
opcache_reset()或重启 PHP-FPM - 测试时别只看 CLI，用 Web 请求触发，因为 CLI 和 Web 的 autoloader 加载路径可能不同
真正卡住人的从来不是“怎么配”，而是“谁在悄悄覆盖”。迁移后第一件事不是写代码，而是确认 __DIR__ 没骗你、namespace 没少写反斜杠、vendor 没被别的项目劫持——这些细节一旦错位，autoload 就变成盲人摸象。
