psr-0已被composer彻底弃用，新项目必须使用psr-4；错误[invalidargumentexception]源于psr-4前缀未以双反斜杠结尾，而非psr-0本身；psr-4路径映射更简洁，不冗余嵌套命名空间，且忽略下划线，要求文件名与类名严格一致。
PSR-0 已被 Composer 彻底弃用，任何新项目都必须用 PSR-4；强行保留 psr-0 配置会触发警告，且在 Composer 后续版本中将直接报错退出。
为什么 PSR-0 会报 [InvalidArgumentException] A non-empty PSR-4 prefix must end with a namespace separator
这个错误不是 PSR-0 引起的，而是你误把 PSR-4 的配置写错了——psr-4 的命名空间前缀（如 "App"）必须以反斜杠 结尾，且 JSON 中需写成双反斜杠 "App\"（实际解析为单个 ）。而 PSR-0 对结尾反斜杠无此要求，但它的存在本身已是历史残留。一旦你在 composer.json 里混用或漏删 psr-0 块，Composer 1.0+ 就会明确提示弃用，并可能跳过加载逻辑。
PSR-4 映射路径比 PSR-0 少一层目录，这是最直观的区别
假设你配置了 "App\": "src/"：
- PSR-4 下，
AppControllersHome→src/Controllers/Home.php - PSR-0 下，同样配置
"App\": "src/"，则AppControllersHome→src/App/Controllers/Home.php（多出App/子目录）
这种“冗余嵌套”正是 PSR-0 被淘汰的关键原因：它强制把命名空间全路径映射进文件系统，导致目录结构僵硬、迁移成本高。PSR-4 则剥离前缀后只映射剩余部分，更贴近现代项目组织习惯。
下划线 _ 在类名里有没有意义，是行为分水岭
PSR-0 把类名中的下划线当作目录分隔符处理：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
My_Class_Name→My/Class/Name.php - 哪怕命名空间是
App，最终路径仍是src/App/My/Class/Name.php
PSR-4 完全忽略下划线：
-
My_Class_Name就对应src/My_Class_Name.php（文件名必须与类名严格一致，含大小写） - 如果你真写了带下划线的类名，那它就是类名的一部分，不会被拆解
这意味着：迁移到 PSR-4 时，所有含下划线的旧类名要么重命名，要么确保文件名完全匹配——否则自动加载失败，且错误不报具体路径，只报 Class not found。
执行 composer dump-autoload 不生效？检查三个硬性条件
PSR-4 不是声明即生效，它依赖三件事同时满足：
-
composer.json中的psr-4键值对格式正确："App\": "src/"（不是"App": "src/"，也不是"App/": "src/"） -
src/是相对于项目根目录的路径，不能是绝对路径（如/var/www/myapp/src/），也不能漏引号 - 修改后必须运行
composer dump-autoload，仅composer install或update不会重新生成 autoload_static.php
最容易被忽略的是最后一项：很多开发者改完配置就直接跑代码，结果类还是找不到——因为 Composer 没刷新自动加载映射表。
