Composer性能优化关键在于精简自动加载路径和依赖，而非隐藏零件；应移除冗余polyfill、正确配置autoload-dev、避免滥用-dump-autoload -o，并聚焦autoload映射与require关系链。
Composer 没有“设备运行原理”或“隐藏无关零件”的概念——它不是硬件，也不支持按需裁剪二进制模块。所谓“提升性能”，本质是减少自动加载路径、跳过无用文件、避免冗余解析，而不是卸载或屏蔽某些“零件”。
composer dump-autoload -o 不是提速万能药，反而可能拖慢开发
加 -o（optimize）会生成 classmap，把所有类路径硬编码进 vendor/composer/autoload_classmap.php，跳过 PSR-4 的字符串替换和文件查找。但它只在以下场景真正有效：
- 部署环境（CI/CD 或生产镜像），且类结构稳定、极少新增
- PHP 未启用 OPCache，或 OPCache 的 realpath 缓存未生效时
- 项目中大量使用非标准命名（如类名与文件名不一致），PSR-4 推导失败频繁
开发中加 -o 反而有害：每次新增类都要手动再跑 composer dump-autoload -o，否则类直接不可见；生成的 classmap 文件体积大、写入慢，composer install 整体耗时上升。
移除 polyfill 和废弃扩展才是真·删零件
很多项目通过 Composer 安装了 PHP 版本或扩展的兼容层（polyfill），比如 symfony/polyfill-mbstring、paragonie/random_compat。如果你的 PHP 已是 8.0+ 且启用了 mbstring、openssl 等扩展，这些包就纯属冗余：
- 它们会被
vendor/autoload.php加载，哪怕从不调用，也增加 autoloader 查表开销 - Composer 2.x 会为每个包注册独立的 autoloader，polyfill 类多 → spl_autoload_register 调用链变长
- 用
composer-unused扫描后，可安全执行composer remove symfony/polyfill-mbstring
注意：composer remove 不会自动清理已生成的 autoload 映射，删完务必补一句 composer dump-autoload。
autoload-dev 配置没生效？你可能漏了 --dev 或写错了作用域
autoload-dev 里声明的路径（如 "Tests/": "tests/"）默认不会写入主 autoload 文件，只在以下情况生效：
- 执行
composer install --dev（本地开发环境） - 执行
composer dump-autoload --dev（显式生成） - CI 流水线用了
composer install --no-dev，那autoload-dev内容完全不会加载 —— 这是故意设计，不是 bug
常见错误：把测试工具（如 phpunit/phpunit）写在 require-dev，却把 Tests/ 放进 autoload（非 -dev），导致测试类在生产环境也能被加载，白占内存和查表时间。
vendor/autoload.php 是入口，不是配置项
这个文件由 Composer 自动生成，内容固定：require __DIR__ . '/composer/autoload_real.php';。它本身不能“隐藏”或“过滤”任何东西。所有“精简”动作都发生在生成阶段：
- 改
composer.json的autoload字段，再跑composer dump-autoload - 删掉
autoload-dev中不需要的路径，再跑composer dump-autoload --dev - 用
composer config -g discard-changes true避免交互卡住 CI，但这和加载性能无关
直接编辑 vendor/autoload.php 或里面的 autoload_psr4.php？Composer 下次 install/update 会直接覆盖，白改。
真正影响性能的，从来不是“哪些零件被隐藏”，而是“哪些路径被扫描”“哪些类被注册进 autoloader”“哪些包根本没被 require”。别信“禁用某功能就能提速”的幻觉，盯住 autoload 映射和 require 关系链，才抓得到关键。
