autoload冲突典型表现为运行时“class not found”或“cannot declare class x, because the name is already in use”，根源是composer.json中psr-4/classmap配置重叠、路径覆盖、命名空间重复映射或exclude缺失，需通过检查autoload_psr4.php和composer dump-autoload -v实证验证。

autoload冲突的典型表现是什么 执行 composer dump-autoload 或 composer install 时没有报错，但运行时抛出 Fatal error: Class 'X' not found，且该类明明在 src/ 或 lib/ 下存在；或者同一类被多次定义（Cannot declare class X, because the name is already in use）。这类问题往往不是新写的代码导致的，而是旧项目长期演进中积累的 autoload 配置叠加、覆盖或遗漏所致。

关键判断点：错误不来自 vendor，而是你自己代码的自动加载失效或错乱。此时不要急着改类名或路径，先确认 Composer 是否真的“看见”并“映射对了”你的类。

检查 composer.json 中的 autoload 字段是否重叠或冲突

多个 autoload 规则共存时，Composer 会按顺序合并，但 PSR-4 和 classmap 混用、相同命名空间映射到不同路径、或路径未排除 vendor 子目录，都可能引发覆盖或重复加载。

Discussion Composer

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

下载

• 检查是否有多个 psr-4 条目指向同一命名空间，例如：
  "App\": "src/" 和 "App\": "app/" 同时存在 → 后者会覆盖前者，但 Composer 不报错
• 确认 classmap 路径是否意外包含 vendor/ 目录（比如写成了 "classmap": ["."]）→ 可能把第三方类也扫进来，导致类重复定义
• 留意 exclude-from-classmap 是否缺失：若用了 classmap 扫描整个 src/，但其中混有测试文件（如 src/Tests/），又没 exclude，就可能把测试类也注册进去
• PSR-4 路径末尾是否多写了斜杠？"App\": "src//" 在某些系统下会导致映射失败，但不报错

验证 autoload 映射是否生效且无歧义

别依赖“看起来配置对了”，要用 Composer 自己的工具看它实际生成了什么。

• 运行 composer dump-autoload -v，观察输出中是否列出你预期的命名空间和路径；如果某条 psr-4 完全没出现，说明该规则被忽略（常见于语法错误或顶层键名拼错，比如写成 autoloader 而非 autoload）
• 查看生成的 vendor/composer/autoload_psr4.php，直接搜你的命名空间前缀（如 'App\' => array($baseDir . '/src')）→ 这才是 PHP 真正执行的映射
• 用 composer show --platform 确认当前环境是否启用 autoloader（极少见，但某些 CI 环境会禁用）
• 临时加一行 var_dump($loader->getPrefixesPsr4()); 到 vendor/autoload.php 开头，运行脚本看实际加载的映射数组 → 最直接，绕过所有缓存和配置解析层

历史遗留常被忽略的三个硬伤

很多 autoload 问题拖很久才暴露，是因为它们只在特定条件下触发：换 PHP 版本、升级 Composer、启用 OPCache、或部署到新服务器。以下三点最容易被跳过：

• autoload-dev 里的规则，在 composer install --no-dev 后完全不可见 → 如果你把核心类放进了 autoload-dev，生产环境必然 Class not found
• Git 忽略了 vendor/composer/autoload_*.php，但某次手动编辑过这些文件 → 它们是生成的，不应被提交，也不应被修改；一旦混入脏内容，autoload 就会行为异常
• 项目根目录下存在 composer.json 和同级的 composer.lock，但还有个子目录（如 packages/foo/）里也有自己的 composer.json → 若主项目通过 path 仓库引入该子包，它的 autoload 规则会被合并进来，可能与主项目冲突（尤其当子包也声明了 App\）

真正棘手的 autoload 冲突，往往藏在“它以前能跑”的假象里——不是配置错了，而是配置太多、太老、太分散，而 Composer 的合并逻辑又过于静默。动手前，先看 autoload_psr4.php，再比对 composer.json，最后用 var_dump 实锤，比猜快得多。