psr-0已在composer 2.0+中彻底移除，配置无效；旧项目若需兼容，须用composer 1.x并严格遵循下划线转路径规则，但强烈建议迁移到psr-4以确保可持续维护。
PSR-0 已被废弃，别再用 psr-0 配置了
Composer 从 2.0 开始彻底移除了对 PSR-0 的自动加载支持；即使你在 composer.json 里写上 "psr-0" 字段，composer install 或 composer dump-autoload 也不会报错，但实际不会注册任何自动加载规则——类根本找不到。
如果你正在维护一个老项目（比如 Laravel 4.x、Symfony 2.0–2.7），它仍依赖 PSR-0 命名约定（如 VendorPackageClass_Name → src/Class/Name.php），那必须明确两点：
- 你用的是 Composer 1.x（
composer --version确认） - 你的
autoload配置不能混用 PSR-4 和 PSR-0 —— Composer 1.x 不支持混合自动加载类型共存于同一命名空间前缀下
composer.json 中正确写法（仅限 Composer 1.x）
PSR-0 要求命名空间前缀映射到磁盘路径，且类名下划线会被转为目录分隔符。配置时需注意路径结尾是否带 /、是否相对 vendor/ 根目录。
示例：想让 Acme_Foo_Bar 自动加载 src/Acme/Foo/Bar.php：
{
"autoload": {
"psr-0": {
"Acme_Foo_": "src/"
}
}
}
关键点：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"Acme_Foo_"后缀下划线是必须的，表示“以该前缀开头的类” -
"src/"是相对于composer.json所在路径的目录，不是 vendor 目录 - 如果类在
src/lib/Acme/Foo/Bar.php，则应写"Acme_Foo_": "src/lib/" - 多个前缀可并列，但不要重叠（如同时配
"Acme_"和"Acme_Foo_"容易冲突）
为什么 composer dump-autoload -o 后还是报 Class not found
常见原因不是配置写错，而是文件结构或类声明不匹配 PSR-0 规则：
- 类文件名含大小写错误（如
Bar.php写成bar.php，Linux 下直接失败） - 类定义里用了
namespace（PSR-0 不要求也不识别 namespace，只靠类名字符串拆解） -
Acme_Foo_Bar类实际定义在src/Acme/Foo/Bar.php，但文件里写的是class Bar { ... }—— 正确应为class Acme_Foo_Bar { ... } - 运行环境 PHP 版本 ≥ 7.2 且启用了 strict mode，而旧类中存在未声明返回类型的函数，导致解析失败（间接引发 autoload 失效）
迁移到 PSR-4 是唯一可持续方案
PSR-0 的下划线转路径逻辑早已被证明难维护、易出错。所有现代框架和库都已切换到 PSR-4。迁移成本其实很低：
- 把类文件按 namespace 重排目录（
AcmeFooBar→src/Acme/Foo/Bar.php） - 在每个类文件顶部加上
namespace AcmeFoo; - 把
composer.json中的"psr-0"换成：
{
"autoload": {
"psr-4": {
"Acme\Foo\": "src/Acme/Foo/"
}
}
}
注意双反斜杠转义和路径结尾的斜杠。改完后执行 composer dump-autoload 即可生效。
真正卡住人的往往不是技术细节，而是项目里散落的 require_once、__autoload 或自定义 loader —— 这些会和 Composer 自动加载打架，必须一并清理。
