如何利用Composer命令生成符合 PSR-0 标准的过时自动加载配置-composer-PHP中文网

composer 2.0+ 完全移除 psr-0 支持，psr-0 字段被静默忽略，dump-autoload 不处理、不报错、不生成 autoload_psr0.php；替代方案为 classmap 或手动 spl_autoload_register。

如何利用composer命令生成符合 psr-0 标准的过时自动加载配置

composer 命令在 2.0+ 版本中完全无法生成符合 PSR-0 标准的自动加载配置——不是操作不对，是底层代码已移除，psr-0 字段被静默忽略，连警告都不发。

composer dump-autoload 会处理 psr-0 吗

不会。执行 composer dump-autoload 或 composer install 时，Composer 2.0+ 直接跳过 "psr-0" 配置块，既不解析、也不写入 vendor/composer/autoload_psr0.php（该文件在 2.0+ 中已不存在）。你检查 vendor/autoload.php 的源码，也找不到任何 PSR-0 相关的 spl_autoload_register 调用。

即使 composer.json 里写了 "psr-0": {"MyLib_": "src/"}，运行后 get_declared_classes() 里依然没有这些类
composer dump-autoload -v 不会报错，也不会提示 “ignored psr-0” —— 它就当这行不存在
和 psr-4 共存时，psr-4 照常生效，psr-0 彻底失联

为什么不能降级 Composer 来启用 psr-0

技术上可行，但生产环境强烈不建议：

Composer 1.x 已停止维护，存在已知安全漏洞（如 CVE-2023-47263），PHP 8.2+ 兼容性差，部分扩展（如 ext-opcache）在高版本下触发 segfault
Laravel 11、Symfony 7、Drupal 10 等主流框架要求 Composer 2.2+，降级会导致 composer update 失败或依赖解析错误
你解决了一个加载问题，却引入了供应链风险和生态割裂

替代方案：classmap 比手写 autoload 更可靠

如果你的旧类库结构固定（比如只有 DB_Mysql.php、HTTP_Request.php 这几个文件），classmap 是最轻量、最稳定的解法：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

在 composer.json 中添加：

"autoload": {
  "classmap": ["vendor/pear/db/", "vendor/pear/http_request/"]
}

运行 composer dump-autoload -o（加 -o 生成优化映射，性能接近硬编码）
Composer 会扫描目录下所有 .php 文件，提取 class 和 interface 声明，生成精确的类名→路径映射，完全绕过命名规则
无需担心下划线、大小写、前缀是否匹配——它只认文件内容里的 class DB_Mysql

手动注册 spl_autoload_register 是唯一运行时补救方式

仅当 classmap 不适用（例如类文件分散、动态生成、或需兼容多个不同 vendor 结构）时才考虑。关键点不是“能加载”，而是“不破坏现有加载流程”：

必须放在 require_once __DIR__ . '/vendor/autoload.php'; 之后，否则会被 Composer 的 PSR-4 加载器抢先拦截并抛出 Class not found
必须检查 class_exists($class, false) 和 interface_exists($class, false)，否则重复 require 会触发 Fatal error: Cannot declare class
路径拼接不能靠猜：__DIR__ . '/vendor/swiftmailer/swiftmailer/lib/classes/' 是 Swiftmailer 4.x 的真实路径，写成 lib/ 或 src/ 就会失效
Linux/macOS 下严格区分大小写：文件是 Db_Mysql.php，但类声明是 class db_mysql → 加载失败

实际生效的最小补丁长这样（以 Swiftmailer 4.x 为例）：

require_once __DIR__ . '/vendor/autoload.php';
spl_autoload_register(function($class) {
    if (false === strpos($class, '_') || class_exists($class, false) || interface_exists($class, false)) {
        return;
    }
    $file = __DIR__ . '/vendor/swiftmailer/swiftmailer/lib/classes/' . str_replace('_', '/', strtolower($class)) . '.php';
    if (is_file($file)) {
        require_once $file;
    }
});

复杂点在于：每个 PSR-0 类库的安装路径、目录层级、文件后缀（有些用 .inc）都可能不同，没法写一个通用函数覆盖全部。你得为每个库单独写一段逻辑，且必须随 vendor 目录结构调整而同步更新。