PSR-4命名空间前缀重复时Composer仅保留第一个配置，后续同名前缀被忽略；若不同路径存在同名类，仅加载首个匹配项，易导致加载错类。
PSR-4 命名空间前缀重复会导致加载错类
Composer 不会合并或去重 PSR-4 映射，只要两个配置项的命名空间前缀相同（比如都配了 "App\": "src/" 和 "App\": "app/"），它会按 composer.json 中出现的顺序保留第一个，后面那个直接被忽略。更危险的是：如果两个不同路径下存在同名类（如 App\Http\Controller\Home 同时在 src/ 和 app/ 里各有一个），Composer 只加载第一个匹配到的——你根本不知道用的是哪个。
常见诱因：
- 多个第三方包都声明了相同的根命名空间（如
"MyLib\": "vendor/mylib/src/"和你自己写的"MyLib\": "lib/"） - 项目升级时遗留旧 autoload 配置没删干净
- 团队成员各自在
autoload和autoload-dev里重复加了同一前缀
验证方法：运行 composer dump-autoload 后，直接打开 vendor/composer/autoload_psr4.php，搜索你的命名空间前缀，看是否只出现一次、对应路径是否是你预期的那个。
classmap 和 psr-4 混用时类名被覆盖怎么办
如果你在 psr-4 下配了 "App\": "src/"，又在 classmap 里加了 "src/Utils/Helper.php"，而这个文件里写的是 class Helper（没 namespace），那 Composer 会优先走 PSR-4 规则——但它发现 Helper 不符合 App\ 前缀，就跳过；接着 classmap 虽然扫到了这个文件，但因为 PSR-4 已声明该类名“不属于我管”，classmap 的映射可能被跳过或不生效。
正确做法是隔离职责：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 有 namespace 的新代码 → 全部走
psr-4，且确保目录结构与声明完全一致 - 无 namespace 的老工具类 → 单独放进一个目录（如
legacy/），只用classmap扫描，别混进 psr-4 路径 - 全局函数文件（如
helpers.php）→ 放files数组，不是classmap
执行 composer dump-autoload -a 强制重扫 classmap，避免缓存残留。
ThinkPHP 或 CodeIgniter 里手动 require vendor/autoload.php 位置错了
框架自身可能已有自动加载逻辑（比如 CI3 的 $config['composer_autoload']），如果你在入口文件里又写了一次 require 'vendor/autoload.php'，而且路径写成 ../vendor/autoload.php 或漏掉 APPPATH，就会导致加载器注册两次，甚至覆盖框架原本的加载规则。
检查点：
- CI3：确认
application/config/config.php中$config['composer_autoload']是否开启，开了就别自己 require - ThinkPHP：TP6 默认启用 Composer 加载，不要在
public/index.php里额外 require，除非你明确要替换默认行为 - 所有框架：
vendor/autoload.php必须从项目根目录相对路径引入，不能靠__DIR__硬算，否则部署后路径偏移
新增类后还是 Class not found？先盯住这三个地方
90% 的“类找不到”不是 Composer 问题，而是环境链断在某个环节：
-
namespace声明末尾少了一个反斜杠（namespace App\Http❌ vsnamespace App\Http\✅） - Linux 服务器上目录名是
Http，但类文件里写的是namespace app\Http（小写app）→ 大小写敏感，直接不匹配 - 改完
composer.json没运行composer dump-autoload -o，或者跑了但没删掉vendor/composer/autoload_classmap.php就直接测试
最稳妥的验证方式：临时在出错脚本开头加一行 var_dump(class_exists('App\Http\Controller\Home'));，再配合 get_declared_classes() 查看当前已加载的类列表——如果类名压根不在里面，问题一定出在 autoload 配置或路径上，而不是业务逻辑。
