Composer不报错但运行时类找不到，根本原因是autoload配置失效或被覆盖，导致已安装包的类路径未注册到自动加载器。
依赖链断裂不是 Composer 报错，而是运行时类找不到、方法不存在、自动加载失败——它不拦在 composer install 阶段，却卡在 new SomeClass() 那一刻。根本原因只有一个：某个包被“解析进来了”，但它的 autoload 配置没生效，或被其他包的 autoload 覆盖/干扰。
为什么 composer show 能看到包，但 new 就报 Class not found
这说明包已安装（出现在 vendor/ 和 composer.lock），但自动加载器没注册它的类路径。常见原因：
-
composer.json里autoload字段写错命名空间或路径，比如"App\": "src/"写成"App\": "./src/"（多一个点） - 用了
path类型仓库，但本地路径下composer.json没配autoload，或配了却没运行composer dump-autoload - 多个包映射到同一命名空间（如两个包都声明
"MyLib\": "src/"），后加载的覆盖前一个，导致部分类失效 -
autoload-dev里误写了vendor/下的路径，让 Composer 认为你“依赖自己”，实际却没把该包的生产 autoload 加进来
composer dump-autoload -o 后还是找不到类？查 vendor/composer/autoload_classmap.php
优化模式（-o）会生成扁平 classmap，是运行时最可靠的加载依据。直接打开这个文件，搜你要用的类名：
- 如果没出现，说明该包的
autoload根本没被 Composer 读取——检查它自己的composer.json是否有语法错误，或是否被conflict规则排除 - 如果出现了，但路径指向错误目录（比如指向
../src/而当前项目结构里没有上层src），说明psr-4映射路径和实际文件位置不一致 - 如果路径正确，但类文件里实际没定义那个类（比如只定义了
MyLibFoo，你却在 newMyLibBar），那就是代码本身问题，不是 Composer 的锅
composer depends --tree 显示包存在，但 composer show 不显示它
这是典型的“只存在于 dev 依赖链，未进入生产依赖快照”现象。原因很具体：
- 该包只出现在
require-dev中，而你执行的是composer install --no-dev（CI 环境常用） - 某个
require-dev包（如infection/infection）在自己的composer.json里写了"autoload": {"psr-4": {"App\": "../src/"}}，把你的src/加进了它的加载路径——但它自己又没被安装（因为--no-dev），所以这条 autoload 实际没生效 - 你手动删过
vendor/但没清缓存，composer show读的是旧快照；运行composer clear-cache && composer install --no-dev才能重置
私有包 + path 仓库 + 命名空间冲突，怎么快速验证
当你用 "repositories" 配了本地 path 包，又发现类加载不稳定，优先做三件事：
- 进那个本地包目录，运行
composer validate—— 它只校验 JSON 格式，但能暴露autoload字段缺失或拼写错误 - 在主项目根目录运行
composer dump-autoload -v，看输出里有没有类似Adding from package myorg/mylib (dev-main): src/这样的提示；没有就说明 Composer 根本没识别到这个包的 autoload - 临时把该包从
repositories移到require，改用 Packagist 版本装一次，确认类能否正常加载——如果可以，问题 100% 出在 path 仓库的配置或本地包自身 autoload 上
最易被忽略的点：Composer 不校验命名空间语义，只按字符串匹配。两个包都声明 "App\": "src/"，它就真会把它们混在一起加载——哪怕一个是旧版 TP5，一个是新写的工具库。这种断裂不会报错，只会让你在某个深夜调试时发现 AppHelper 加载的是 A 包的，而 AppService 加载的是 B 包的。
