PSR-4 默认不支持多级命名空间映射到同一目录，因其采用严格前缀匹配而非通配符；例如"App\": "src/"要求AppFooBar对应src/Foo/Bar.php，而AppFooBazQux必须对应src/Foo/Baz/Qux.php，不会fallback至src/下查找。
PSR-4 自动加载为什么默认不支持多级命名空间映射到同一目录
Composer 的 psr-4 映射是“前缀→路径”的严格前缀匹配，不是通配符或模糊匹配。比如你写 "App\": "src/"，那 AppFooBar 会去找 src/Foo/Bar.php，但 AppFooBazQux 也必须落在 src/Foo/Baz/Qux.php —— 它不会因为 AppFoo 没单独声明，就 fallback 到 src/ 根下找 Foo.php。
常见错误现象：Class AppFooBar not found，但你确认 src/Foo/Bar.php 存在且类名正确。问题往往出在 composer.json 中漏写了 App\ 后的反斜杠，写成 "App": "src/"（少一个 ），导致前缀解析失败，整个映射被忽略。
- PSR-4 要求命名空间末尾必须带反斜杠
，否则视为 PSR-0 兼容模式（已废弃） - 路径必须是真实存在的相对路径（相对于
composer.json），不支持通配符或变量 - 多个前缀可共存，但顺序无关——Composer 内部按长度倒序排序，优先匹配更长前缀
PSR-0 已废弃，但 legacy 项目里还可能触发它的加载逻辑
PSR-0 允许下划线转目录、支持多级嵌套映射（如 Vendor_Lib_ClassName → lib/Vendor/Lib/ClassName.php），但它依赖类名中的下划线，并且对命名空间支持不一致。Composer 从 2.0 开始完全移除 PSR-0 支持，但如果你在 composer.json 里写了 "psr-0" 字段，Composer 会报错退出；如果没写但用了老式类名（比如 MyPackage_Core_Utils），而你又没启用 classmap 或 files 加载，那类就真的找不到。
实际场景：升级 Laravel 5.5 → 9.x 时，有些插件仍用 Some_Vendor_Something 风格类名，又没补 classmap，结果在 PHP 8+ 下直接 Class not found。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 不要在新项目中使用 PSR-0，也不要在
composer.json中保留已注释掉的"psr-0"块（Composer 会警告） - 遗留类名无法改写时，用
"classmap": ["legacy/"]扫描生成静态映射，比 PSR-0 更可靠 - PSR-0 和 PSR-4 不能混用于同一命名空间前缀——Composer 只认其中一个
autoload-dev 和 autoload 的区别不只是“开发时才加载”
autoload-dev 声明的路径，只会在执行 composer install --dev（默认）或 composer dump-autoload 时写入 vendor/autoload.php 的加载逻辑；但关键点在于：它生成的 autoloader 是和 autoload 分开注册的，且优先级更低。这意味着，如果同一个类同时被 autoload 和 autoload-dev 覆盖（比如都映射了 Tests\），运行时只会走 autoload 的规则（因为先注册），autoload-dev 的映射被静默忽略。
典型误用：把测试工具类（如 TestsTestCase）放在 autoload-dev 里，却在 phpunit.xml 中 require 了 vendor/autoload.php，结果测试跑不起来——其实是因为 TestCase 没被主 autoload 覆盖，而 autoload-dev 又没生效（比如 CI 环境跑了 composer install --no-dev）。
-
autoload-dev不是“仅开发环境可用”，而是“仅当启用了 dev 包时才注册” - 执行
composer dump-autoload --optimize时，autoload-dev的路径不会进入优化后的classmap - 若需确保测试类始终可加载，建议统一用
psr-4映射到tests/，并放入autoload（只要不影响生产部署即可）
dump-autoload 的 --classmap-authoritative 和 --apcu 选项影响真实行为
--classmap-authoritative 表示“所有类都必须出现在 classmap 中，否则直接抛错，不再尝试其他 autoload 规则”。这能提升性能（跳过 PSR-4 文件系统查找），但也意味着：哪怕你只是临时加了个新类文件，没重新 dump-autoload，就会 Class not found。它适合部署环境，不适合本地快速迭代。
--apcu 是把生成的映射缓存在 APCu 中，避免每次请求都解析 vendor/composer/autoload_*.php。但它要求 APCu 扩展已启用，且注意：APCu 缓存是 per-process 的，PHP-FPM 下每个 worker 进程有独立缓存，所以更新后需要 reload FPM 或清空 APCu。
composer dump-autoload --classmap-authoritative --apcu
- CI/CD 流水线中建议加
--classmap-authoritative，配合classmap+exclude-from-classmap精确控制 -
--apcu对 CLI 脚本无效（除非你手动启用 APCu CLI 模式），只对 Web SAPI 生效 - 这两个选项叠加使用时，APCu 中缓存的是权威 classmap，一旦缓存命中失败，就不会 fallback —— 错误更“硬”，排查要更准
