Laravel 6服务容器需精准使用：控制构造函数注入≤3个依赖，避免注入Request/Auth/Session等高开销门面，非必需服务按需resolve()，慎用单例（仅限无状态类），精简服务提供者并启用延迟绑定与配置/路由/视图缓存。
Laravel 6 的服务容器本身非常强大，但滥用会直接拖慢请求响应、增加内存占用、甚至引发状态污染。关键不是“少用”，而是“用得准、管得住、清得净”。
避免构造函数过度注入
每个构造函数注入的服务，都会触发容器解析（含反射），嵌套深时开销明显。尤其在高频控制器或中间件中，应严格控制数量。
- 单个类构造函数建议不超过 3 个依赖；超过时考虑拆分职责或改用方法注入
- 避免注入 Request、Auth、Session 等高开销门面实例——它们内部有运行时状态和延迟加载逻辑
- 对非必需服务（如通知、日志、第三方 SDK 客户端）优先使用
app()或resolve()按需获取，而非构造注入
慎用单例绑定，明确生命周期
单例（singleton()）看似省资源，实则容易成为状态泄漏源，尤其在 Swoole/常驻进程环境下更危险。
- 仅对真正无状态、线程/协程安全的类（如格式化器、加密器）使用单例
- 数据库连接、Redis 客户端、HTTP 客户端等绝不能全局单例——必须每次请求新建或使用连接池
- 自定义单例务必实现重置逻辑（如配合 LaravelSwoole 的 Resetter），否则沙箱模式也救不了
精简服务提供者与延迟绑定
Laravel 6 启动时默认加载全部服务提供者，哪怕只用其中一两个方法，也会执行其 register() 和 boot()。
- 检查
config/app.php中的providers数组，移除未实际使用的扩展包服务提供者 - 为非核心服务启用延迟绑定（
defer = true），仅在首次解析时注册绑定，减少启动开销 - 大型项目可运行
php artisan package:discover --optimize生成优化清单，加快服务发现
配置与绑定缓存必须启用
未开启缓存时，每次请求都要重新合并 config 文件、扫描路由、解析门面别名，是 Laravel 6 最易忽视的性能黑洞。
- 部署后立即执行：
php artisan config:cache && php artisan route:cache && php artisan view:cache -
注意：缓存后
.env和运行时config(['key' => 'val'])将失效，所有动态配置需改用缓存驱动或数据库存储 - 若使用自定义门面，确保其
getFacadeAccessor()返回的字符串已注册到容器，否则缓存后会报错
不复杂但容易忽略：容器不是万能胶，而是精密杠杆。用对支点，四两拨千斤；乱塞依赖，反而压垮整个请求周期。
