PSR-4映射是配置composer.json中的命名空间到路径映射，需用"psr-4"字段、结尾带斜杠、命名空间末尾加反斜杠，改后必须执行composer dump-autoload更新vendor/autoload.php。
PSR-4 映射不是“写代码”，是配 composer.json
Composer 的 autoload 不靠手写加载器，靠的是你在 composer.json 里声明的命名空间到路径的映射。它本质是告诉 Composer：“App 开头的类，全去 src/ 下找”。你改了配置不运行命令，它就完全不生效。
- 必须用
"psr-4"字段，"psr-0"已废弃（2025 年起主流工具默认忽略） - 路径末尾要带斜杠，比如
"App\": "src/"，少一个/会导致文件路径拼错 - 命名空间结尾的反斜杠
是必需的，"App"和"App\"在 PSR-4 中含义完全不同 - 改完
composer.json后，必须执行composer dump-autoload，否则vendor/autoload.php里的映射表不会更新
vendor/autoload.php 是入口，不是你自己写的文件
项目里唯一该 require 的自动加载文件，只有 vendor/autoload.php。它由 Composer 自动生成，内部用 spl_autoload_register() 注册了多个 loader，其中 PSR-4 部分由 ComposerAutoloadClassLoader 实现——这个类做了路径缓存、前缀短路、文件存在性预检，比你手写 __autoload 或 set_include_path 快且稳得多。
- 别自己新建一个
autoload.php放在项目根目录，然后require它——这会绕过 Composer 的依赖图和优化逻辑 - 别在
index.php里写一堆require_once 'src/xxx.php'，那等于放弃自动加载的意义 - 如果发现类找不到，先确认是否已
require 'vendor/autoload.php'，再检查命名空间、文件路径、大小写是否完全一致（Linux 下大小写敏感）
类文件路径 = 命名空间去掉前缀 + 转 / + .php
PSR-4 加载不是“猜路径”，而是严格按规则拼：类名 AppControllerUserController，映射 "App": "src/"，就等价于加载 src/Controller/UserController.php。中间任何一环出错，文件就加载失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
namespace必须和文件路径严格对应，src/Controller/User.php里写namespace AppController;才对；写成AppControllers就找不到 - 类名必须和文件名完全一致，
UserController.php里只能定义class UserController，不能是UserCtrl或usercontroller - 子命名空间层级必须体现为子目录，
AcmeBlogPost对应lib/Blog/Post.php，不能压平成lib/Post.php
为什么 dump-autoload 有时不生效？
常见原因是缓存残留或路径配置冲突。Composer 生成的映射表存在 vendor/composer/autoload_psr4.php，但这个文件只在 dump-autoload 时重写——如果之前有手动修改过它，或者用了 --no-scripts 参数跳过脚本，就会导致内容陈旧。
- 遇到“明明改了配置却还是加载旧路径”，先删掉
vendor/composer/autoload_*.php全部文件，再跑一次composer dump-autoload - 多个 PSR-4 条目有前缀重叠（比如同时配了
"App\": "src/"和"App\Admin\": "admin/"），后者会被前者拦截，因为匹配是“最长前缀优先”，但实际加载器只取第一个匹配项 - 开发中频繁改命名空间？建议加
-o（optimize）参数：composer dump-autoload -o，它会生成静态映射数组，比动态扫描快不少
自动加载看着只是“少写几行 require”，但它把类定位这件事从运行时推到了配置期。一旦路径或命名空间有一处没对齐，报错信息往往只说“Class not found”，而真正卡住你的，常常是那个漏掉的反斜杠、多写的下划线、或没执行的 dump 命令。
