Composer 2.0+ 彻底移除 PSR-0 支持，psr-0 配置被静默忽略；必须改用 classmap 或手动注册 spl_autoload_register 实现兼容。
Composer 2.0+ 已彻底不支持 PSR-0 自动加载
直接说结论：composer install 或 composer dump-autoload 在 Composer 2.0 及以上版本中，完全忽略 "psr-0" 配置项——它不会生成任何映射逻辑，也不会报错（除非你写法错误导致 JSON 解析失败），只是静默跳过。这不是配置没写对，是标准已被移除。
原因很明确：PSR-0 在 2014 年就被 PHP-FIG 正式弃用，Composer 从 v2.0 起主动切断支持，避免遗留陷阱。如果你在 composer.json 里还留着 "psr-0" 块，它就是个摆设。
- 常见错误现象：
Class 'MyOrg_Utils_Helper' not found，但文件确实在vendor/myorg/utils/lib/MyOrg/Utils/Helper.php或vendor/myorg/utils/lib/myorg/utils/helper.php，且命名空间和类名完全匹配 PSR-0 规则 - 不是路径写错了，也不是没运行
dump-autoload，而是 Composer 根本没处理这一段 - 降级 Composer 到 1.x 或找“PSR-0 兼容插件”都不推荐——既引入安全风险，又拖慢生态演进
必须手动注册 PSR-0 加载器（spl_autoload_register）
唯一可靠的做法，是在项目入口（如 index.php、bootstrap.php）中，于 require_once 'vendor/autoload.php' 之后，用 PHP 原生机制补上 PSR-0 规则。
关键不是“能不能 require”，而是“是否严格遵循 PSR-0 的转换逻辑”：下划线 _ 必须转为目录分隔符，且所有字母转小写；多级前缀（如 MyOrg_Package_）要逐段拆解；必须检查文件存在性，否则会触发警告或致命错误。
- 示例片段（需按实际路径调整）：
require_once __DIR__ . '/vendor/autoload.php'; spl_autoload_register(function ($class) { if (false === strpos($class, '_') || class_exists($class, false) || interface_exists($class, false)) { return; } $parts = explode('_', $class); $file = __DIR__ . '/vendor/myorg/package/lib/' . strtolower(implode('/', $parts)) . '.php'; if (is_file($file)) { require_once $file; } }); - 注意：
$file路径中的myorg/package/lib/是硬编码的，必须与你实际类库的安装位置一致 - 别在
files中直接require_once类文件——这会破坏自动加载语义，且遇到同名类时触发Fatal error: Cannot declare class
更稳妥的选择：改用 classmap 显式声明
如果这个 PSR-0 类库结构稳定、文件数量少（比如就 3–5 个类），classmap 比手写 autoload 更简单、更健壮，也更容易调试。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
它的原理是让 Composer 扫描指定目录，生成一个静态的 class → file 映射表，运行时不依赖规则推导，只查表。没有命名空间解析歧义，也不怕下划线或大小写干扰。
- 在
composer.json中添加："autoload": { "classmap": ["vendor/myorg/package/lib/"] } - 然后执行：
composer dump-autoload -o（加-o生成优化版，性能更好） - 验证方式：打开
vendor/composer/autoload_classmap.php，确认你的类名已出现在数组中 - 适用场景：老项目迁移过渡期、第三方未维护包、CI/CD 中需要确定性行为
为什么不能混用 PSR-0 和 PSR-4？
Composer 明确禁止在同一个 "autoload" 块中同时声明 "psr-0" 和 "psr-4"——不是“配不好”，是设计上直接拒绝。即使你写了，Composer 也会静默忽略 psr-0，只生效 psr-4，并可能抛出弃用警告。
更隐蔽的问题是：一旦某个命名空间前缀被 PSR-4 规则覆盖（例如 "MyLegacy\": "src/legacy/"），哪怕你另配了 "MyLegacy_Foo_Bar": "vendor/oldlib/"，所有以 MyLegacy 开头的类都会走 PSR-4 查找，根本不会进 PSR-0 流程。
- 不要试图用路径隔离来绕过——只要命名空间前缀重叠，PSR-4 就会拦截全部请求
- 正确做法是把遗留类库完全隔离：用
classmap或files单独加载，不参与主 autoload 命名空间体系 - 如果类名无法修改（比如 Swiftmailer v5.x 的
Swift_Mime_SimpleMessage），就别碰它，用classmap包住整个vendor/swiftmailer/swiftmailer/lib/classes/
真正麻烦的从来不是“怎么配”，而是得想清楚：这个类库是否真的必须用 PSR-0 方式加载？有没有可能用 classmap 一劳永逸？手写 spl_autoload_register 时，路径拼接逻辑是否覆盖了所有嵌套层级？这些细节，往往比配置本身更消耗时间。
