根本原因是手动重复引入 vendor/autoload.php，导致 Composer 自动加载器重复注册 PSR-4/ClassMap 映射，类被两次定义。常见于 phpunit.xml 与测试文件中同时加载、artisan 命令中二次 require 等场景。
为什么 require_once('vendor/autoload.php') 会报错“Cannot redeclare class”
问题根源其实不在于 require_once 这个指令本身失效了。真正的原因在于，你手动写了不止一次的 require_once('vendor/autoload.php')，而且其中至少有一次，发生在 Composer 的自动加载机制已经启动之后——比如在测试文件、命令行脚本或者框架入口文件里重复引入了。要知道，Composer 自己的 autoload.php 内部确实使用了 require_once 来加载各种映射文件，但它的核心初始化逻辑是一次性的。当你额外再手动调用一次时，就会导致 PSR-4 和 ClassMap 的映射关系被重复注册。结果就是，当某个类第一次被自动加载触发时，PHP 会尝试去定义它两次——这才是那令人头疼的 Fatal error: Cannot redeclare class 的真正来源。
- 典型踩坑场景：在
phpunit测试文件里手动写了require_once 'vendor/autoload.php'，但同时phpunit.xml配置文件里又设置了bootstrap="vendor/autoload.php"。 - 另一个高频雷区：在 Lara vel 的
artisan命令或者 Symfony Console 命令的__construct()或handle()方法里，又“画蛇添足”地补了一句require_once。 - 关键提醒：
require_once只能保证同一个文件路径不被包含多次，但它阻止不了 Composer 内部自动加载器（autoloader）的重复初始化逻辑——这恰恰是很多人误以为“加了 once 就万事大吉”的认知盲区。
如何确认是不是 vendor/autoload.php 被重复加载
最直接有效的诊断方法，是加一句简单的输出。你可以临时修改 vendor/autoload.php 文件的顶部（注意，仅用于调试，不要提交此改动）：
echo "[Autoload loaded at " . microtime(true) . "]";
然后，再去运行那条报错的命令，比如 php artisan tinker 或者 phpunit。观察终端输出，看看那句提示是否打印了两次或以上。如果出现了两次，那就铁证如山，确实有外部代码主动触发了第二次加载。
- 别依赖 IDE 的“跳转到定义”——很多集成开发环境会错误地把 Composer 自动生成的
autoload_static.php这类文件当作入口。 - 检查所有进程调用：仔细排查代码中的
php -f、exec()、shell_exec()调用，它们可能会隐式地启动一个新的 PHP 进程，从而再次加载 autoload。 - 部署脚本也是重灾区：像 Capistrano、Deployer 这类部署工具，可能在 post-deploy 阶段先执行
composer install，随后又去require某些文件，同样容易触发重复加载。
正确做法：只让 Composer 控制 autoload 初始化时机
说实话，绝大多数现代 PHP 项目，你根本不需要自己手写那句 require_once('vendor/autoload.php')。主流框架、命令行工具、测试套件都已经内置了自动加载的引导逻辑。你要做的核心动作其实是“做减法”：删掉所有手动的 require，把控制权彻底交还给项目生态本身。
- Lara vel 项目：入口文件
public/index.php和artisan里已经包含了require __DIR__.'/../vendor/autoload.php';。其他地方，一律禁止再写。 - PHPUnit 测试：删掉测试文件顶部的那句
require_once。确保phpunit.xml配置文件里，通过bootstrap属性正确指向它即可。 - 独立纯脚本（比如
scripts/deploy.php）：如果脚本需要独立运行，可以用#!/usr/bin/env php开头，并在紧接着的第一行后立刻引入require 'vendor/autoload.php';—— 记住，有且仅有这一处。 - 绝对要避免：在循环、条件分支、trait 或者 __autoload 函数里动态地去 require autoload.php，这等于自找麻烦。
真需要动态加载？用 Composer 提供的正式 API
当然，存在一些极少数场景，比如开发插件系统、或者在运行时需要切换依赖版本，确实需要对自动加载进行干预。但即便如此，也绝不能简单粗暴地硬 require。正确姿势是使用 Composer 官方提供的 API：
$loader = require 'vendor/autoload.php';
// 后续可以安全地调用：
$loader->add('MyPlugin\\', __DIR__ . '/plugins/myplugin/src/');
$loader->register(true); // 参数 true 表示 prepend，可以避免与主 autoloader 冲突
这里获取到的 $loader 是 ComposerAutoloadClassLoader 的实例，它允许你安全地追加命名空间映射，而不会破坏已有的、由 Composer 生成的核心映射关系。
- 别自己造轮子：不要试图自己去
new ClassLoader()然后手动调用setPsr4。那样会缺失 Composer 生成的优化映射（比如autoload_classmap.php），不仅性能差，还极易遗漏类的加载。 - 注意优化转储：如果项目使用了
composer dump-autoload --optimize命令，那么autoload_files.php里列出的文件会被预加载。此时再手动 require，就会直接导致函数或常量的重复声明错误。 - 线上环境尤其要小心：有些 Dockerfile 的构建步骤，在
RUN composer install之后，又执行COPY . . && php index.php。如果 index.php 里还有一句require_once，就会撞上容器内已经初始化好的 autoload 状态，从而引发错误。
说到底，这类问题的麻烦之处，从来不是 require_once 这个语法怎么写才对，而是你很难一眼看出自动加载机制在哪一层、被谁悄悄地、提前启动了。所以，查日志、打时间戳、理清进程的生命周期，这些基本功往往比死记硬背几条命令要重要得多。
