安全记录请求日志需只取必要字段（method、fullurl、ip、user id）、过滤敏感参数、清洗控制字符、避免序列化大对象；响应日志应通过terminating回调获取，禁用非json格式器，生产环境按需开关并采样。
中间件里怎么安全记录请求日志
直接在中间件里用 Log::info() 记录请求，看似简单，但容易漏掉关键字段、污染日志格式，甚至拖慢响应。核心是：只记必要字段，避免序列化大对象，别在中间件里做耗时操作。
推荐用 Laravel 自带的 Request 对象提取结构化数据，而非 $request->__toString() 或 print_r($request) —— 后者会把整个容器、闭包、上传文件句柄都塞进日志，轻则日志爆炸，重则 OOM。
- 只取
$request->method()、$request->fullUrl()、$request->ip()、$request->user()?->id（注意空值） - 敏感参数如
password、token必须从$request->all()中显式过滤，不能靠“信任前端” - 不要在
handle()开头就打日志——万一后续中间件抛异常，这条日志就成了“幽灵请求”，实际没走到业务层
为什么不能在中间件里记录响应体或状态码
因为中间件执行时响应还没生成。你在 handle() 里拿到的 $response 是下游返回的，但此时它可能还是 Illuminate\Http\Response 实例，也可能是 StreamedResponse，甚至未渲染的视图对象。直接调用 $response->getContent() 有风险：
- 对 JSON 响应有效，但对重定向、文件下载、流式响应会失败或阻塞
- 多次调用
getContent()可能触发重复渲染（尤其带副作用的视图） - 状态码在中间件里可用
$response->getStatusCode()，但它的值未必反映最终结果——比如后面中间件改了状态码，你记下的就是错的
真要记响应状态，建议用 terminating 回调或事件监听 kernel.handled，而不是硬塞在中间件 handle() 里。
如何避免日志内容被篡改或注入
用户控制的请求头（如 User-Agent、Referer）和查询参数，可能含换行符、控制字符或超长字符串，直接拼进日志会导致日志切割错乱、ELK 解析失败，甚至被用来伪造日志条目。
- 统一用
str()->replace(["\n", "\r", "\t"], ' ')->trim()清洗字符串字段 - 对 IP 地址用
$request->ip()而非$request->header('X-Forwarded-For')—— 后者可被客户端伪造 - URL 用
$request->fullUrl()安全，但若需记录原始 path，请先urlencode()再写入，防止路径中含恶意字符 - 日志通道配置里禁用
json格式以外的 formatter，避免文本日志被注入伪条目
性能影响在哪？什么时候该关掉
每请求一次磁盘 I/O 或网络写入（如 Slack、Syslog），都会增加平均响应时间 2–10ms。高并发下这个开销会被放大，且日志文件增长过快还可能触发 inode 耗尽。
- 开发环境默认开启，生产环境建议按需开关：用配置项
config('logging.request_enabled')控制 - 高频接口（如心跳、轮询）建议跳过日志，可在中间件里加白名单判断：
in_array($request->route()->getName(), ['api.heartbeat', 'web.ping']) - 异步写日志不现实——中间件必须同步执行，所以只能靠降低采样率，例如只记录 5% 的请求：
rand(1, 100)
最常被忽略的一点：日志里记了 $request->cookie() 却忘了它是加密后的 raw 字符串，直接记录等于暴露加密上下文，应该只记是否存在、不记值。
