应降级 Composer 至 1.10.25 版本，因 Composer 2.x 移除了全局 ClassLoader 类，导致旧项目 autoload 失败；需用 composer self-update 1.10.25（Linux/macOS 可加 php 前缀，Windows 用包管理器），并确保项目中只引入 vendor/autoload.php 而非子文件。
composer 2.x 报错 “Class 'Composer\Autoload\ClassLoader' not found” 怎么办
这是典型的 Composer 2.x 与旧项目 autoload 机制不兼容的表现。不是所有项目都能直接升级，尤其依赖老旧插件（如 fxp/composer-asset-plugin）或自定义 autoloader 的 PHP 5.6/7.0 项目。根本原因在于 Composer 2.x 彻底移除了 Composer\Autoload\ClassLoader 的全局可用性，改用更严格的命名空间隔离和加载时机控制。
临时解法是降级到 1.x，但要注意：这不是“回滚修复”，而是绕过兼容问题的权宜之计。
用 composer self-update 降级到 1.10.25（最后一个稳定 1.x 版）
Composer 官方支持通过 self-update 指定版本降级，但必须指定带完整补丁号的版本 —— 直接写 1.10 或 1.x 会失败。
-
composer self-update 1.10.25是目前最稳妥的选择（2021 年发布的最终 1.x 版） - 执行前先确认当前版本：
composer --version - 若提示权限错误（如 Linux/macOS 下报
Permission denied），不要加sudo，改用：php /usr/local/bin/composer self-update 1.10.25（路径用which composer查） - Windows 用户若用 Scoop 或 Chocolatey 安装，需改用对应包管理器降级，
composer self-update可能无效
为什么不能只改 composer.json 中的 require？
因为 composer.json 里的 require 控制的是项目依赖，不是 Composer 自身。你无法靠它把全局的 Composer 二进制从 2.x 变成 1.x。
常见误解操作包括：
- 在项目里写
"composer/composer": "^1.10"→ 这只会安装一个 composer 的副本到vendor/，完全不影响全局composer命令行为 - 用
php composer.phar手动指定旧版 phar → 可行但难维护，每次都要带路径，且容易和系统 PATH 冲突 - 删掉
~/.composer/vendor/bin/composer后重新安装 → 不安全，可能破坏其他项目依赖
真正生效的只有修改全局可执行文件本身，即 self-update 或重装二进制。
降级后仍报 autoload 错误？检查你的 vendor/autoload.php 引入方式
即使 Composer 降级了，有些项目在 index.php 或测试入口里写了硬编码路径，比如：
require __DIR__.'/vendor/composer/autoload_classmap.php';
这类写法在 1.x 下可能侥幸工作，但在 2.x 下彻底失效；而降级后如果还沿用这种非标准引入，反而会因路径变动出新错。
正确做法始终是：
- 只引入根 autoload：
require __DIR__.'/vendor/autoload.php'; - 绝不直接 require
autoload_*.php子文件 - 检查是否有脚本在
composer dump-autoload -o后手动修改过vendor/autoload.php—— 这类魔改在降级后大概率崩溃
真正的兼容瓶颈往往不在 Composer 版本本身，而在那些被忽略的、写死的加载逻辑。
