Sentry不报错的根本原因是异常被try/catch静默捕获或report()未被调用；report()仅处理未被捕获异常，需确保所有catch块显式调用$this->report($e)，且Handler的report()方法未被空实现或过滤，Sentry SDK须在boot()中初始化。
为什么 App\Exceptions\Handler 里加了 Sentry 却不报错？
常见现象是：本地 php artisan tinker 中抛出异常，Sentry 控制台没记录；或生产环境偶发错误完全漏报。根本原因不是 Sentry 配置错了，而是 Laravel 的异常处理流程被提前截断或跳过。
关键点在于：report() 方法只对「未被捕获的异常」生效；如果控制器里用了 try/catch 却没调用 $this->report($e)，或者在中间件/事件监听器中静默吞掉了异常，Sentry 就收不到任何信号。
- 检查所有
try/catch块，确保捕获后仍显式上报：$this->report($e) - 确认
app/Exceptions/Handler.php中的report()方法没有被重写成空逻辑或条件过滤掉非 HTTP 异常 - Sentry SDK 初始化必须在
report()调用前完成——推荐在boot()方法中初始化，而非构造函数
LOG_LEVEL=debug 在生产环境为什么反而让错误更难定位？
表面上看，日志级别越细越容易排查，但实际会掩盖真正的问题信号。Laravel 默认把 debug 级别日志写入 storage/logs/laravel.log，而这个文件在高并发下会迅速膨胀，导致：
- grep 查找特定错误时被海量 SQL/事件日志淹没
- logrotate 未配置时磁盘占满，整个日志系统失效
- 敏感参数（如密码、token）可能随请求体被完整记录，违反安全规范
生产环境应坚持 LOG_LEVEL=error，并为关键业务单独开通道：比如支付失败走 Log::channel('payment')->error(...)，再用 tail -f storage/logs/payment.log 实时盯控。
自定义验证失败响应为什么总被 ValidateRequests 中间件覆盖？
Laravel 的表单验证失败默认返回 302 重定向（Web）或 422 JSON（API），但很多人在 FormRequest 类里重写了 failedValidation()，却发现前端始终收不到自定义结构——问题出在中间件执行顺序和响应拦截时机。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
核心限制：ValidateRequests 中间件在控制器执行前就完成了验证和响应，一旦触发失败，后续控制器方法根本不会运行，所以你在控制器里写的 response()->json(...) 永远不会执行。
- Web 场景：改用
withErrors()+ 视图层判断，避免重写failedValidation() - API 场景：在
FormRequest中重写failedValidation()，但必须抛出HttpResponseException并手动构造响应，例如：throw new HttpResponseException(response()->json([...], 422)); - 统一出口：更稳妥的做法是全局覆盖
Illuminate\Foundation\Http\Exceptions\FormRequestValidationException的渲染逻辑，在App\Exceptions\Handler的render()方法中识别并转换
为什么 php artisan config:clear 后错误依旧存在？
缓存清理不彻底是高频盲区。Laravel 的配置加载有三层缓存机制：config:cache 生成的 bootstrap/cache/config.php、OPcache 缓存的 PHP 文件、以及 .env 解析结果被 vlucas/phpdotenv 缓存在内存中。
典型陷阱：你改了 .env 里的 APP_DEBUG=true，执行了 config:clear，但没清 OPcache 或重启 FPM，PHP 还在用旧的 config.php 编译结果。
- 完整清理链：
php artisan config:clear && php artisan cache:clear && php artisan route:clear && sudo systemctl restart php-fpm（或opcache_reset()） - 验证是否生效：在
tinker中执行config('app.debug')，输出必须是布尔值true，而不是字符串"true"（后者说明 .env 没被正确解析） - 开发时禁用 OPcache：在
php.ini中设opcache.enable=0，避免反复重启服务
最易被忽略的是异常上下文丢失——比如数据库查询失败时，$e->getPrevious() 可能包含 PDO 具体错误码，但默认日志只打 $e->getMessage()。真要定位根因，得在 report() 里主动展开整个异常链，否则永远卡在“QueryException”这个笼统分类上。
