autoload_classmap.php 会拖慢 PHP-FPM 并撑大 worker 内存，因其是需每次加载解析的全量数组文件；应禁用 classmap，改用 autoload_static.php 或 APCu 缓存，并精简 autoload 配置路径。
自动加载文件本身不直接“占用运行时内存”，真正拖慢 PHP-FPM、撑大 worker 内存的是 autoload_classmap.php 这种全量数组被反复加载和解析——尤其在没开 OPCache 或配置不当的时候。优化方向不是“压缩文件”，而是避免加载它，或让它变轻、变快。
为什么 autoload_classmap.php 会让内存飙升
这个文件是 PHP 数组文本，内容类似 ['App\User' => '/path/to/User.php', ...]。问题在于：
- Composer 2.x 默认不生成它，除非你显式加
--optimize-autoloader（或-o）且项目里有"classmap": [...]配置 - 一旦生成，PHP 每次请求都要
require整个文件 —— 即使只用 1 个类，也要反序列化数 MB 的数组 - OPCache 对这种动态结构缓存效率低；若
opcache.max_accelerated_files不够，它还可能被挤出缓存 - 常见误判：看到
vendor/composer/autoload_classmap.php存在，就以为“优化生效了”，其实它正悄悄吃内存
生产部署必须禁用 classmap，改用 autoload_static.php
Composer 2.2+ 默认启用 autoload_static.php，它是编译后的静态映射表（非数组，是 PHP 字节码友好的结构），体积小、加载快、OPCache 友好。要确保它生效：
- 删掉
composer.json里的"classmap": [...]条目（尤其是"tests/"、"docs/"、"legacy/"这类无用扫描） - 部署命令必须带
--no-dev：composer install --no-dev --optimize-autoloader - 验证是否用了 static：检查
vendor/composer/autoload_real.php，应看到require __DIR__ . '/autoload_static.php';，而不是autoload_classmap.php - 如果仍看到 classmap 被加载，说明某依赖包的
composer.json里写了classmap—— 用composer show -t vendor/package定位并考虑替换或 fork
APCu 缓存比 classmap 更安全、更省内存
APCu 不缓存整个映射表，而是缓存「类名 → 文件路径」的查询结果，按需填充、按需淘汰。对中大型项目更友好：
- 启用只需加参数：
composer install --apcu-autoloader --no-dev - 不需要改代码，但要求 PHP 已装 APCu 扩展且
apc.enabled=1 - 相比
--classmap-authoritative，它不会因漏类报错，也不强制关闭 PSR-4 fallback - 注意：不能和
--classmap-authoritative同时用；APCu key 建议加前缀防冲突，如"apcu-autoloader": "myapp_"在 config 里配
真正省内存的关键：砍掉 autoload 配置里的冗余路径
很多项目在 "psr-4" 里写宽泛前缀，或重复注册，导致 Composer 加载器内部维护大量无效匹配逻辑：
- ❌ 错误写法：
"": "src/"（空命名空间会扫全目录）、"App\": "app/"和"App\Http\": "app/Http/"并存（重叠前缀） - ✅ 正确写法：
"App\": "app/src/"（精准路径），删掉所有测试/文档/旧模块的 autoload 条目 - 用
composer dump-autoload -v看输出：如果出现Scanning /path/to/tests for classes，说明它正在白干活 - 运行
php -r "echo memory_get_peak_usage() / 1024 / 1024 . ' MB';"加载vendor/autoload.php前后对比，最能暴露谁在吃内存
别迷信 -o 参数，它在 PHP 7.4+ + OPCache 下大概率是负优化；真正的内存节省来自路径精简、classmap 彻底禁用、以及让 autoload_static.php 或 APCu 成为唯一真相源。
