测试数据集不应放入 autoload-dev，因其非类文件，autoload-dev 仅处理类、接口、trait 和函数声明；纯数据文件需通过显式加载或专用加载器按需读取。
这里有个核心原则得先明确：测试数据集不该进 autoload-dev，更不该指望通过自动加载机制来“加载数据”——它压根不是类，自然不参与 PHP 的类加载流程。
为什么用 autoload-dev 加载测试数据会失败
道理其实很简单。Composer 的 autoload-dev 设计初衷，只处理 class、interface、trait 和 function 这些声明。对于纯数据文件，比如 JSON、YAML、CSV 或者只返回数组的 PHP 脚本，它完全“无感”。一个常见的误区是，把类似 "files": ["tests/data/fixtures.php"] 这样的配置塞进 autoload-dev，结果就是每次自动加载被触发时，这个文件都会被无条件执行一次。这会导致什么？重复定义、变量污染，甚至直接抛出致命错误。
- 关键在于，
files配置项的行为是“每次请求都执行”，而不是“按需加载”。只要 Composer 的自动加载器被调用，列表里的文件就会被 include。 - 测试数据的需求恰恰相反：需要的是按需读取、解析、可能还要缓存，而不是在全局范围内一次性注入。
- 试想，如果数据文件里写的是
return ['user' => [...]];，autoload 机制根本不会把它识别为一个可加载的单元，最终要么报错，要么就静默地失败了。
autoload-dev 里只放真正需要“类自动加载”的测试支撑代码
那么，autoload-dev 应该用来做什么？答案是：存放那些真正需要被自动加载的测试辅助类。比如 tests/Support/DatabaseTestCase.php 或者 tests/Support/ApiMockClient.php 这类带有明确命名空间和 class 声明的文件。
- 推荐的做法是使用 PSR-4 映射：
"autoload-dev": { "psr-4": { "Tests\\Support\\": "tests/Support/" } }。 - 同时确保你的
tests/Support/DatabaseTestCase.php文件以namespace Tests\Support;开头。 - 记住一个关键点：不要把
tests/data/这样的纯数据目录加到任何 autoload 配置里——它不包含类，也不应该被 autoloader 扫描。 - 如果非要用 PHP 文件来存储数据（例如
tests/data/user-fixtures.php），正确的做法是让测试基类在合适的时机进行require_once，或者用include_once来精确控制加载时机。
大型项目中测试数据集的合理组织方式
说到底，数据本身应该和加载逻辑分离开。autoload 只负责管“类”，而数据加载这件事，应该交给测试生命周期来管理。
- 利用好
tests/bootstrap.php进行统一初始化：这个文件应该先require dirname(__DIR__).'/vendor/autoload.php';，然后在这里注册你的数据加载器或者设置测试环境。 - 数据文件可以规整地放在
tests/data/目录下，但通过一个专用的类（比如Tests\Support\FixtureLoader）来按需读取。这个加载器可以集成缓存、自动识别格式（JSON/YAML）、解析路径等功能。 - 要避免在每次测试的
setUp()方法里都去执行file_get_contents，可以考虑采用延迟加载（lazy load）配合静态缓存来提升性能。 - 还有一个安全提醒：敏感数据（比如 API 密钥）绝对不要硬编码在数据文件里。应该通过
$_ENV或者专用的.env.testing文件来管理，可以使用像vinkla/lara vel-dotenv-editor这样的包，或者自己写一个简单的加载器。
最后，特别容易忽略的一点是：autoload-dev 的路径映射只影响类的查找逻辑，并不保证文件的存在性。也就是说，即使你配置了 "Tests\\Data\\": "tests/data/"，tests/data/user.json 这个文件依然不会被自动加载——原因很简单，JSON 不是 PHP 类。所以，别指望 Composer 能替你解决数据加载的问题，这本来就是测试框架或者你自己编写的 FixtureLoader 的职责所在。
