laravel 11 在依赖管理与自动加载层面收紧默认行为：默认不预装开发依赖，强制启用权威类映射（--classmap-authoritative），部署必须用 composer install --no-dev --optimize-autoloader --classmap-authoritative，并硬性要求 apcu 与 opcache 协同缓存。
Laravel 11 在依赖管理与自动加载层面延续了 Laravel 9/10 的优化方向，但进一步收紧了默认行为、强化了生产就绪约束，并对 Composer 集成做了更精细的控制。它不引入颠覆性机制，而是把已验证有效的最佳实践“固化”进骨架和部署流程中。
默认 composer.json 更精简，开发依赖显式隔离
Laravel 11 新项目默认 不再预装 facade/ignition、laravel/tinker（CLI 环境除外）和 phpunit/phpunit 到 require-dev；这些包改为按需安装（如运行 php artisan tinker 时提示并引导安装）。此举从源头减少 autoload 扫描范围，避免新项目一初始化就生成数 MB 的 classmap。
- 本地开发可仍用
composer require --dev laravel/tinker，但该包不会进入生产 autoload 流程 -
config/app.php中的providers数组默认不注册 IgnitionServiceProvider，除非明确启用 - CI/CD 构建脚本若仍沿用旧版
composer install而未加--no-dev，会因缺失隐性依赖而失败——这是 Laravel 11 的主动防御设计
自动加载默认启用权威模式（classmap-authoritative）
Laravel 11 的官方部署文档和 artisan optimize:install 命令已将 --classmap-authoritative 设为标配参数之一。这意味着：类必须存在于 autoload_classmap.php 中，否则直接报错，不再 fallback 到 PSR-4 路径拼接。
- 要求
composer.json中所有 PSR-4 前缀末尾带反斜杠，例如"App\": "app/"（不是"App": "app/"） - 新增类后，必须运行
composer dump-autoload或重新执行composer install -o，否则线上请求立刻失败 - 全局 helper 文件（
"files"类型）不受影响，仍可正常加载
生产部署命令已标准化为单条强约束指令
Laravel 11 官方推荐的生产部署命令不再是可选组合，而是强制三合一：
composer install --no-dev --optimize-autoloader --classmap-authoritative-
--no-dev：跳过 require-dev 包安装，且彻底忽略其 autoload 配置（包括 Tests 命名空间） -
--optimize-autoloader：生成扁平 classmap，绕过所有文件系统调用 -
--classmap-authoritative：关闭 fallback，确保加载路径 100% 可预测
该命令在 CI 流水线中执行后，vendor/composer/autoload_classmap.php 将只包含真实生产代码路径，体积可控、结构清晰、无冗余扫描。
APCu 与 OPcache 协同成为硬性依赖项
Laravel 11 文档明确指出：若启用 --classmap-authoritative，则 必须同时启用 APCu 和 OPcache，否则 classmap 文件每次被读取、反序列化仍是性能瓶颈。
- OPcache 需开启：
opcache.enable=1+opcache.validate_timestamps=0（禁用时间戳校验） - APCu 需启用：
extension=apcu.so+apcu.enable_cli=1（FPM 下生效） - 验证是否命中缓存：
php -r "var_dump(apcu_fetch('composer:autoload'));"应返回非空数组
没有这两层缓存，classmap 优化效果会打五折以上——Laravel 11 把这个“隐性前提”变成了显性要求。
