同一包多次出现且autoload路径不同，是多层嵌套autoload冲突表象；实际生效的是vendor/composer/autoload_*.php中的注册逻辑，而非依赖树显示顺序。
composer show -t 里看到同一包出现多次，autoload 路径却不同
这是最典型的多层嵌套 autoload 冲突表象：比如 symfony/polyfill-mbstring 在依赖树中被 laravel/framework 和 phpunit/phpunit 分别拉入，但版本不同（如 1.28.0 vs 1.30.0），Composer 会选一个版本安装，而它的 autoload 规则（如 psr-4 映射或 files 引入）可能和另一个版本不一致，导致类找不到或函数重复定义。
关键不是“谁装了它”，而是“谁的 autoload 规则最终生效”。composer show -t 只显示理论依赖路径，不反映实际加载顺序；真正起作用的是 vendor/composer/autoload_*.php 文件里的注册逻辑。
- 运行
composer show symfony/polyfill-mbstring查看它当前实际安装的版本及其autoload块声明 - 用
grep -n "mbstring" vendor/composer/autoload_static.php定位该包的类映射是否被覆盖或重复注册 - 注意
files类型 autoload 会直接require_once，若两个版本都注册了同名全局函数（如mb_strlen补丁），就会报Cannot redeclare
composer dump-autoload --optimize 后 class not found
优化模式会把所有 PSR-4/PSR-0 映射合并进静态数组，跳过动态扫描。一旦某个嵌套依赖的 autoload 配置没被正确识别（比如用了 classmap 但路径不存在，或 exclude-from-classmap 误删了关键目录），就会漏掉类。
常见于私有包或 fork 包：它们的 composer.json 里写了 "autoload": {"psr-4": {"MyVendor": "src/"}}，但实际代码在 lib/ 下，或者 src/ 是空的——dump-autoload 不报错，但运行时找不到类。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先跑
composer dump-autoload -v，观察输出里是否跳过了你预期的目录 - 对比
vendor/composer/autoload_psr4.php和包内composer.json的映射是否一致 - 临时去掉
--optimize，用composer dump-autoload看是否恢复，确认是优化逻辑导致而非路径问题
私有包 require 了另一个私有包，两者 autoload 冲突
当 A 包 require B 包，且两者都声明了相同命名空间（如 "MyApp\": "src/"），Composer 默认不会合并它们的 autoload，而是按安装顺序注册——后安装的覆盖先安装的。但如果你手动改过 composer.lock 或用 composer require --no-update，就可能让 B 的 autoload 被 A 的覆盖掉。
更隐蔽的是 replace 字段：B 包如果写了 "replace": {"myapp/core": "self.version"}，而 A 包又 require myapp/core，Composer 会把 B 当作 myapp/core 的实现，但它的 autoload 规则未必匹配 A 的预期。
- 运行
composer show -t | grep -A5 "your-private-package"确认它是否真的被作为子依赖加载，而不是被replace掉 - 检查
vendor/your-vendor/your-package/composer.json里的autoload和replace是否自洽 - 避免在私有包间用相同命名空间；若必须，统一由顶层包声明 autoload，子包只提供代码，不声明 autoload
CI 环境下 vendor/autoload.php 加载失败，本地正常
根本原因常是 Docker 或 CI runner 用户权限导致的 autoload 文件生成不全，或 vendor/composer/installed.json 里记录的 autoload 类型（如 classmap）在构建时路径不可达。
例如：Dockerfile 中用 root 执行 composer install，但 PHP 进程以 www-data 运行，而 vendor/composer/autoload_classmap.php 里写的路径是 /root/project/vendor/xxx/src，非 root 用户读不到。
- CI 中加一步验证：
php -r "include 'vendor/autoload.php'; echo 'OK';" - Docker 构建时确保
USER www-data后再composer install，或用--no-scripts避免执行可能依赖用户环境的 autoload 生成脚本 - 禁用 classmap 缓存：
"autoload": {"psr-4": {"": "src/"}}比"classmap": ["src"]更可靠，因前者不依赖文件系统路径快照
vendor/autoload.php 是否真包含了你要的映射，再查版本。 
