必须将 files 写在 "autoload": {"files": [...]} 中，路径相对于 composer.json 目录，需真实存在、为 PHP 文件，修改后运行 composer dump-autoload；函数在 vendor/autoload.php 加载时执行，测试需显式引入该文件。
composer.json 里 files 怎么写才生效
必须写在 "autoload" 的 "files" 数组里，且路径是相对于 composer.json 所在目录的——不是相对于项目根目录，也不是相对于 vendor/。常见错误是写成绝对路径或漏掉 vendor/autoload.php 的引入。
实操建议：
-
"files"数组里的每个路径必须是真实存在的 PHP 文件（不能是目录），且文件内应有可执行代码或函数声明 - 路径支持
./src/helpers.php、src/functions.php这类相对写法，但不支持../shared/global.php（跨出项目根目录会加载失败） - 修改后必须运行
composer dump-autoload，否则新增的文件不会被注册进自动加载器 - 如果文件里定义了函数，这些函数会在 Composer 自动加载时无条件执行（类似
require），注意副作用
为什么 files 加载的函数在测试时找不到
因为 files 只在 vendor/autoload.php 被 require 时触发，而很多测试框架（如 PHPUnit）默认不加载它，或者用的是自己的引导逻辑。
常见错误现象：
- 命令行跑
php test.php报Call to undefined function - IDE 显示函数存在，运行时报错
解决方法：
- 确保测试脚本开头有
require __DIR__.'/vendor/autoload.php'; - 检查 PHPUnit 的
phpunit.xml是否配置了bootstrap，并指向了正确的 autoloader - 避免在
files中依赖尚未加载的类——它比 PSR-4 加载更早，没有类可用
files 和 psr-4 混用时谁先执行
files 里的文件会在所有 PSR-4/PSR-0 映射注册前就被 include_once 执行，所以它天然适合放全局辅助函数、常量定义、基础配置等“前置依赖”。
但这也带来风险：
- 不能在
files文件中new SomeClass()，除非该类已通过其他方式提前加载（比如也在files里、或硬编码require） - 如果两个
files都定义同名函数，后加载的会覆盖前一个（PHP fatal error：Cannot redeclare） - 性能上几乎无影响——只是多几个
include_once，但加载顺序不可控，不适合做逻辑编排
什么时候该用 files，什么时候该改用服务提供者或容器
只在真正需要“全局函数即开即用”时用 files，比如 Laravel 的 helpers.php、WordPress 插件的工具函数集。一旦出现以下情况，就该停手：
- 函数开始依赖 DI 容器、配置实例、数据库连接等运行时对象
- 不同环境要加载不同文件（
files不支持条件加载） - 需要单元测试隔离——
files是全局污染型加载，没法 mock 或替换 - 项目已用框架（如 Laravel、Symfony），其服务容器或 HelperServiceProvider 更合适
容易被忽略的一点：files 不受 Composer 的 autoload-dev 控制——开发专用的 helper 文件如果放在 autoload.files 下，生产环境也会加载。真要区分，得拆到 autoload-dev.files 里，并确保部署时没运行 composer install --no-dev。
