laravel 6 的异常处理器无法在构造函数中注入服务，因其由框架早期手动 new 实例化，此时容器尚未就绪；但可在 report() 和 render() 中安全使用 app() 或 $this->container 获取已绑定服务。
在 Laravel 6 中，异常处理器（App\Exceptions\Handler）默认**无法直接使用服务容器的自动解析能力**（比如构造函数注入），因为 Handler 类由框架底层提前实例化，早于服务容器完全就绪，且不经过容器的依赖注入流程。但你仍可在 report() 或 render() 方法中安全调用容器，前提是确保请求上下文已加载。
为什么不能在 Handler 构造函数里注入服务？
Laravel 在应用启动早期就 new 出 Handler 实例，此时服务容器尚未完成注册（如 config、log、request 等服务还未绑定），构造函数类型提示会失败，抛出 Target [SomeInterface] is not instantiable 错误。所以不要尝试在 Handler 的 __construct 中写 LoggerInterface $logger 这类依赖。
在 report() 和 render() 中安全使用 app() 或 resolve()
这两个方法总是在请求生命周期中较后阶段执行，此时容器已初始化完毕，app() 全局辅助函数和 $this->container（Handler 内部属性）都可用：
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- 用
app('log')或app(\Psr\Log\LoggerInterface::class)获取日志实例 - 用
app()->make(MyService::class)解析自定义服务（前提是它已在register()中正确绑定） - 若需 request 对象，可直接用
$request参数（report(Exception $e, $request)不是原生签名，但 Laravel 6.2+ 支持在report()中通过request()辅助函数或app('request')获取）
推荐做法：延迟解析 + 显式绑定保障
为避免运行时解析失败，建议：
- 所有要用于异常处理的服务，必须在
AppServiceProvider@register()中完成绑定（尤其是singleton()或bind()） - 在
report()中优先使用app()->make()，而非resolve()（后者可能绕过绑定逻辑） - 对关键服务（如 Sentry、Slack webhook 客户端）做空值检查：
if (app()->bound('sentry')) { app('sentry')->captureException($e); }
不推荐的兜底方式
以下操作会破坏 Laravel 设计原则，应避免：
- 在
bootstrap/app.php或中间件中用set_exception_handler()替代 Handler —— 丢失 request、auth、config 上下文 - 在 Handler 中手动 new 一个服务类（如
new Mailer()）—— 绕过容器，无法享受依赖注入与测试友好性 - 把
$dontReport数组当成“开关”来控制上报逻辑 —— 应该用业务逻辑判断，而不是靠排除列表屏蔽异常
