PSR-0 已废弃，Composer 2.0+ 彻底移除支持，仅旧版 Composer 1.x 或自定义加载器下可能“生效”，但存在安全与性能风险；应统一迁移到 PSR-4。
PSR-0 已废弃，不建议在新项目中使用；Composer 2.0+ 甚至已移除对它的支持。
为什么 psr-0 配置现在基本无效
Composer 自 2.0 版本起彻底删除了 psr-0 加载器逻辑。如果你用的是较新版本的 Composer（执行 composer --version 显示 v2.x），运行 composer dump-autoload 时不会处理 "psr-0" 字段，也不会报错——它直接被忽略。
- PHP 5.3+ 早已普及，
psr-4能更好匹配命名空间与目录结构，性能也更高 - 所有主流框架（Laravel、Symfony、Yii）早在 2015 年后就全面迁移到
psr-4 - 如果你在旧项目里看到
"psr-0"，大概率是为兼容 PHP 5.2 写的，而这类环境现在极难维护
遇到 Class not found 却配置了 psr-0 怎么办
先确认是否真因加载规则失效：执行 composer show --platform 看 PHP 版本，再运行 composer dump-autoload -v（加 -v 查看详细日志）。如果日志里完全没提 psr-0，说明它没被读取。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查
composer.json是否把psr-0写在了错误位置（必须在"autoload"下，不是"autoload-dev"或顶层） - 确认类名是否严格符合 PSR-0 规则：下划线
_要转成目录分隔符，且首字母大写（如Vendor_Lib_ClassName→vendor/lib/ClassName.php） - 更简单的方法：直接改用
psr-4，一行就能覆盖原来逻辑（见下一条）
如何把 psr-0 快速迁移到 psr-4
不需要重命名文件或修改类定义，只需调整 composer.json 和目录结构。核心原则是：用命名空间代替下划线，路径与命名空间对齐。
- 原
"psr-0": {"MyLib_": "src/"}→ 新写为"psr-4": {"MyLib\": "src/MyLib/"} - 如果类名是
MyLib_Foo_Bar，PSR-0 期望它在src/Foo/Bar.php；PSR-4 则要求命名空间为MyLibFooBar，文件放src/MyLib/Foo/Bar.php - 迁移后别忘了删掉
psr-0字段，再执行composer dump-autoload - 若类中仍用
class MyLib_Foo_Bar而非namespace MyLibFoo; class Bar，那得同步改代码——这是最常卡住的地方
还有人在用 psr-0？那可能是 legacy 环境
仅在两类场景可能还“生效”：一是锁死了 Composer 1.x（如 composer self-update --1），二是用了自定义 Autoloader（比如自己写了 spl_autoload_register 回调去解析下划线）。
- Composer 1.x 最终版（1.10.22）虽支持
psr-0，但已停止维护，存在安全风险 - 即使能用，PSR-0 的自动转换逻辑比 PSR-4 慢约 20%（尤其类名长、下划线多时）
- 真正麻烦的不是配置，而是团队里有人照着过时机教程写
psr-0，却不知道 vendor 里的包（如 monolog/monolog）早就不提供 PSR-0 兼容的 autoload 了
所以别纠结怎么配对，先确认 Composer 版本和实际生效的 autoload 类型——composer dump-autoload -vvv 输出里出现 Generated autoload files 后的加载器列表，才是真相。
