解读

国内一线/二线互联网公司的 PHP 面试里，Composer 加载机制是“必考点”。
面试官抛出此题，通常想验证三件事：

1. 你是否真的读过 composer.json 官方文档，而不是只会 composer install；
2. 能否把“自动加载”与“性能”“维护成本”联系起来，体现线上高并发场景下的工程思维；
3. 是否清楚 PSR-4 的局限性，知道在遗留代码、全局函数、第三方闭包库等场景如何兜底。

回答时切忌只背定义，要结合“什么时候用、什么时候别用、踩过什么坑”来讲故事，才能拿到高分。

知识点

1. Composer 自动加载四板斧：psr-4、psr-0、classmap、files，优先级依次降低。
2. classmap 生成机制：composer dump-autoload 时扫描指定目录/文件，把“类名→文件路径”写入 vendor/composer/autoload_classmap.php，PHP 启动时一次性载入内存，O(1) 查找。
3. files 生成机制：把列表中的文件直接 require，适合函数、常量、全局配置，不做类映射。
4. 性能对比：
   – classmap 无 IO、无前缀匹配，适合 0-100 ms 级别敏感接口；
   – files 每增加一个文件就多一次 require，APCu/Opcache 命中率高时差异不大，但低版本 PHP5 或 CLI 短生命周期任务里容易成为瓶颈。
5. 国内工程化实践：
   – Laravel 早期版本用 classmap 加速 Eloquent 模型；
   – 微服务 SDK、银行对接 SDK 常带 helpers.php，用 files 加载全局函数；
   – 阿里规约要求“业务代码禁止用 files 加载>5 个文件”，防止 composer.json 失控。

答案

classmap 适用场景

1. 目录下类文件多、命名不规范，无法配出 PSR-4 前缀；例如 legacy Zend 1 项目、历史商城源码。
2. 线上大流量接口，需要把类加载耗时压到最低；通过 composer dump-autoload --optimize（--apcu）生成 classmap， Opcache 预热后 TTFB 可再降 5-15 ms。
3. 打包 Phar 或 Docker 镜像时，提前把类路径写死，避免运行时扫描磁盘。

files 适用场景

1. 定义纯函数、常量、闭包，例如 Laravel 的 helpers.php、WordPress 的 functions.php。
2. 第三方库强制要求先载入配置或 polyfill，如 symfony/polyfill-mbstring。
3. CLI 一次性脚本，文件数<3、体积<100 KB，图方便直接 files 加载，省去写 bootstrap 的麻烦。

何时两者都不用
新项目、统一 PSR-4 命名规范、开启 Opcache，直接走 psr-4 即可；额外维护 classmap/files 反而增加“composer.lock 冲突”风险。

拓展思考

1. 混合策略：核心接口用 classmap，后台管理后台用 PSR-4，既保性能又保开发效率；在 composer.json 里通过 autoload 与 autoload-dev 区分，线上 dump-autoload --no-dev --optimize。
2. 版本升级陷阱：PHP8 引入 preload，classmap 会被提前载入内存，若同时用 files 加载同名函数会抛“Cannot redeclare”致命错；国内某头部电商曾因 helpers.php 重复定义 env() 导致 618 预热失败，教训是“files 加载前先 if (!function_exists)”。
3. 国内云函数（SCF、FC）冷启动优化：把 classmap 与 files 合并到一个 autoload.php，配合 Opcache 预编译，冷启动可压到 30 ms 内，比传统框架降低一个数量级。