psr-4是真正的按需加载，但仅在类首次被引用时触发，依赖composer.json中autoload配置；错误地将helpers.php等文件纳入"files"或把trait/interface放入psr-4目录会导致非按需加载或报错，应严格限定autoload范围。
PSR-4 是真正的按需加载，但前提是你没乱注册
Composer 的“按需加载”不是魔法，它只在类被首次引用（new、static::、class_exists() 等）时触发自动加载器。这个过程依赖 vendor/autoload.php 中注册的 ClassLoader 实例，而它的行为完全由 composer.json 中的 autoload 配置决定。
常见错误是把不该进 autoload 的东西硬塞进去：
-
"files": ["src/helpers.php"]—— 这会强制在autoload.php加载时就require_once执行，不是按需，而是“一劳永逸”，副作用代码提前跑，还污染加载逻辑 - 把纯
trait或interface文件放在psr-4映射目录里，却没定义对应类名 —— 自动加载器找不到文件就报错，不是跳过 - 多个
psr-4前缀存在重叠（如"App\": "src/"和"App\Http\": "legacy/http/"），匹配顺序靠前的先命中，后面配置可能永远不生效
真正“按需”的做法：只注册明确以类为单位组织的命名空间；工具函数、stub 文件、测试辅助类，统统移出 autoload 区域，需要时手动 require_once。
composer install --no-dev --optimize-autoloader 能砍掉 30%+ 内存峰值
生产环境启动慢、内存爆表，往往不是因为代码本身，而是 Composer 在生成 autoloader 阶段干了太多事。默认的 composer install 会加载全部 dev 依赖元数据、扫描所有 PSR-4 目录、构建未优化的映射逻辑——这些都在 PHP 进程里完成，直接吃内存。
必须加的三个参数：
-
--no-dev：跳过require-dev下所有包（比如phpunit、phpstan）的解析和安装，省下几百 MB 内存 -
--optimize-autoloader（或-o）：生成vendor/composer/autoload_classmap.php，把类名直连路径，绕过字符串拼接 + 文件是否存在检查，减少 I/O 和 CPU 开销 -
--no-progress：关闭进度条和实时状态快照，避免内部维护大量临时数组
注意：--optimize-autoloader 生成的 classmap 是静态的，新增类后必须重新运行 composer dump-autoload -o，否则类找不到。
低内存服务器上，clean install 比增量更新更稳
在 512MB 或更低内存的服务器上，composer update 几乎必然 OOM；而 composer install 如果 vendor/ 已存在且 lock 文件有变更，也会触发全量依赖图重建，峰值内存常超 800MB。
可靠做法是彻底清掉旧状态再装：
- 执行
rm -rf vendor/ && composer install --no-dev --optimize-autoloader --no-progress - 配合环境变量限制：
COMPOSER_MEMORY_LIMIT=128M+php -d memory_limit=128M composer install ... - 禁用所有插件（如
hirak/prestissimo），它们在资源紧张时反而引发并发竞争或缓存膨胀
关键点：clean install 只读 composer.lock，路径线性、对象生命周期短；而增量更新要 diff 旧 vendor 元数据，内存占用不可控。别怕删 vendor，它本来就是可再生的。
classmap-authoritative 模式能提速，但会掩盖动态类
"classmap-authoritative": true（或 composer install -a）会让自动加载器彻底放弃 PSR-4 fallback：如果类不在预生成的 classmap 里，直接抛 Class not found，不再尝试拼路径找文件。
这带来两个实际影响：
- 加载速度更快——省掉所有字符串处理和
file_exists()调用，尤其适合容器化部署、opcache 全启用场景 - 但凡项目里有运行时生成的类（比如 Laravel 的事件监听器绑定、Doctrine 的代理类、某些 ORM 的动态实体）、或依赖包用了
class_alias()/eval()，就会报错 - 开发阶段绝对不要开，它和热重载、动态类注册天然冲突
真正适合它的场景很窄：打包好的 CLI 工具、无框架脚本、或确认所有类都已静态声明且不会运行时扩展的封闭系统。
