应使用$request->server('QUERY_STRING')和$request->getRawContent()分别获取GET和POST/PUT等请求的原始参数字节长度，而非param()或input()等已解析方法，因后者丢失原始体积信息。
直接统计接口请求参数的原始字节数，不能靠 request()->param() 或 input() —— 它们返回的是 PHP 已解析、过滤、转义后的数组，原始体积信息早就丢失了。真正能反映“客户端发了多少数据”的，只有原始请求体（raw body）和查询字符串（QUERY_STRING）。
为什么 param() 和 input() 统计不准
request()->param() 是 GET + POST + 路由变量的合并结果，内部调用 $_GET、$_POST 等超全局变量，而 PHP 解析这些变量时已做 URL 解码、键值分割、类型转换，原始二进制长度不可逆。比如一个含 200KB JSON 的 POST 请求，param() 返回的数组可能只占几 KB 内存，但实际网络传输量是 200KB。
- GET 参数被解析进
$_GET，但原始QUERY_STRING可能含未解码空格、%20、+，长度不同 - POST 表单（
application/x-www-form-urlencoded）经php://input解析后丢失原始编码细节 - JSON 或 XML 请求体必须用
$request->getRawContent()才能拿到未处理字节流 -
input('xxx', '', 'htmlspecialchars')会先转义再返回，原始长度彻底掩盖
如何在中间件中获取真实参数总大小
唯一可靠方式：在请求进入路由和控制器前，用中间件捕获原始输入源，并计算字节长度。注意区分请求类型：
- GET 请求：取
$request->server('QUERY_STRING')，非空则strlen()即为参数总长（单位字节） - POST/PUT/DELETE 请求：调用
$request->getRawContent()，它读取php://input流一次且仅一次；若返回false或空字符串，说明是表单编码，此时应 fallback 到拼接http_build_query($request->post())（但精度下降） - JSON 请求：
getRawContent()返回的就是原始 JSON 字符串，strlen()准确 - 文件上传（multipart）：
getRawContent()在 multipart 场景下通常为空（PHP 已将文件写入临时目录），此时应改用$request->header('content-length')—— 它是整个请求体长度，包含所有字段和文件，最接近攻击者实际发送量
示例中间件逻辑：
立即学习“PHP免费学习笔记（深入）”；
public function handle($request, \Closure $next)
{
$method = strtoupper($request->method());
$size = 0;
if ($method === 'GET') {
$query = $request->server('QUERY_STRING', '');
$size = strlen($query);
} elseif (in_array($method, ['POST', 'PUT', 'DELETE'])) {
$raw = $request->getRawContent();
if ($raw !== false && $raw !== '') {
$size = strlen($raw);
} else {
// fallback：估算表单编码长度（不精确，仅作兜底）
$post = $request->post();
$size = strlen(http_build_query($post));
}
}
// multipart 场景下 content-length 更可靠（含文件）
if ($size === 0 && $request->header('content-type', '')->contains('multipart/form-data')) {
$size = (int) $request->header('content-length', 0);
}
// 记录到日志或缓存
\think\facade\Log::info('request_param_size', [
'url' => $request->url(),
'method' => $method,
'size_bytes' => $size,
'ip' => $request->ip()
]);
return $next($request);
}
content-length 头为什么有时不准
Content-Length 是 HTTP 请求头，表示整个请求体（body）的字节数，但它在两种情况下失效：
- 使用分块传输编码（
Transfer-Encoding: chunked）时，该头不存在，PHP 无法通过 header 获取 —— 此时getRawContent()仍可用，但需确保未被其他中间件提前读取 - 某些代理或 CDN 会移除或修改该头，尤其是对大请求做了流式转发时
- 浏览器 FormData 提交时，boundary 随机生成，
Content-Length包含 boundary 和换行符，比纯参数略大，但仍是当前最贴近真实攻击面的指标
所以生产环境建议：优先用 getRawContent() + strlen()，multipart 场景 fallback 到 Content-Length，绝不依赖 $_POST 或 param() 做体积判断。
统计结果怎么用于限流或告警
拿到字节数后，别只打日志。可结合 Redis 实现「大参数请求频次」监控：
- 按 IP + 接口路径构造 key：
api:param_size:192.168.1.100:/api/v1/submit - 每请求累加：
Cache::inc($key, $size, 60)（60秒窗口内累计字节数） - 设置阈值，如 10MB/60s，超过则记录告警或触发中间件拦截
- 注意：Redis 的
INCR只支持整数，$size必须是 int，别传 float
真正容易被忽略的是：同一个接口，GET 参数长度和 POST 原始体长度差异极大，统计口径必须统一按「原始字节」而非「PHP 数组元素个数」——否则你看到的“高频请求”可能全是 50KB 的恶意 JSON，而日志里只记成 “3 个参数”。
