Laravel无法捕获超大请求体，因PHP在SAPI层已丢弃数据；需在public/index.php开头截取php://input前1KB，或用Nginx日志记录$request_length，或捕获PostTooLargeException记录CONTENT_LENGTH等元信息。
如何在 Laravel 中捕获超大请求体并记录到日志
直接说结论：Laravel 默认不记录完整请求体，尤其是超过 post_max_size 或 max_input_vars 限制的请求，根本进不了应用层；想记录“大请求”，必须在 PHP 接收阶段就介入，不能依赖 Request 对象或中间件。
为什么 $request->all() 或 $request->getContent() 无法拿到超大请求体
PHP 在解析请求时，如果 POST 数据超过 post_max_size（如 8M），会直接丢弃整个 $_POST 和 php://input 流，$_POST 变为空数组，$request->getContent() 返回空字符串——这不是 Laravel 的问题，是 PHP SAPI 层的硬限制。
- 常见错误现象：
$_POST为空、$request->has('xxx')始终为false、日志里只看到空[] - 使用场景：上传 JSON 配置、批量导入数据、前端误发巨型 base64 图片字段
- 关键参数差异：
post_max_size控制原始 POST 数据上限，upload_max_filesize只管multipart/form-data中的文件字段，二者独立 - 性能影响：开启
always_populate_raw_post_data（PHP 5.6+ 已废弃）或反复读取php://input会导致内存占用飙升，尤其对大请求
真正能记录大请求体的两个可行位置
只能从 PHP 底层或 Web 服务器侧入手，Laravel 应用内补救空间极小。
- 在
public/index.php最开头加逻辑：用fstat(STDIN)或$_SERVER['CONTENT_LENGTH']获取原始请求大小，再用file_get_contents('php://input', false, null, 0, 1024)截取前 1KB 记录（避免 OOM） - 改用 Nginx 日志：在
log_format中加入$body_bytes_sent和$request_length，配合map判断是否超阈值后打标，再用 logrotate + grep 提取可疑请求 - 禁用
enable_post_data_reading = Off（PHP-FPM）可保留原始流，但需自行解析 multipart，风险高，不推荐生产环境
如果只是想记录“被拒绝的大请求”，用 Laravel 中间件也能凑合
它抓不到内容，但能识别失败模式并记下上下文，比完全没日志强。
- 监听
Illuminate\Http\Exceptions\PostTooLargeException异常，在app/Exceptions/Handler.php的render()中捕获 - 记录
$_SERVER['CONTENT_LENGTH']、$_SERVER['REQUEST_URI']、$_SERVER['HTTP_USER_AGENT']、$_SERVER['REMOTE_ADDR'] - 注意：该异常只在
post_max_size超限时触发，max_input_vars超限只会静默截断，需额外检查count($_POST) < ini_get('max_input_vars') - 示例日志条目：
PostTooLargeException: CONTENT_LENGTH=12849232, URI=/api/v1/import, IP=203.0.113.42
真正难的不是记录，而是区分“故意传大包”和“客户端 bug 导致的意外膨胀”——这得靠请求头里的 X-Request-ID 或业务字段特征来关联分析，光看大小没意义。
