PHP日志格式 = json格式？

PHP 日志格式 ≠ JSON 格式—— 二者是可选关系，而非等同关系。

传统 PHP 日志：纯文本（如error_log、Monolog 默认格式）
JSON 日志：结构化日志的一种可选格式，需显式配置

是否使用 JSON 取决于日志消费场景（如 ELK、Splunk 需要结构化数据）。

一、核心区别：文本 vs 结构化

特性	传统文本日志	JSON 日志
格式	人类可读的字符串	机器可解析的 JSON 对象
示例	`[2026-01-27 10:00:00] production.ERROR: User login failed`	`{"time":"2026-01-27T10:00:00Z","level":"ERROR","message":"User login failed","context":{"user_id":123}}`
解析难度	需正则提取字段	直接解析为对象
适用场景	本地调试、简单部署	集中式日志系统（ELK、Loki）

💡核心认知：
JSON 日志 = 为机器优化的结构化格式，文本日志 = 为人类优化的可读格式

二、PHP 日志实现对比

▶ 1.Laravel 默认文本日志

// config/logging.php'channels'=>['stack'=>['driver'=>'stack','channels'=>['single'],],'single'=>['driver'=>'single','path'=>storage_path('logs/laravel.log'),'level'=>'debug',],],

输出示例：

[2026-01-27 10:00:00] local.ERROR: Failed to connect to database {"userId":123}

▶ 2.Laravel JSON 日志配置

// config/logging.php'single_json'=>['driver'=>'single','path'=>storage_path('logs/laravel.json'),'level'=>'debug','formatter'=>\Monolog\Formatter\JsonFormatter::class,],

输出示例：

{"message":"Failed to connect to database","context":{"userId":123},"level":400,"level_name":"ERROR","channel":"local","datetime":"2026-01-27T10:00:00.000000Z","extra":[]}

▶ 3.原生 PHP 错误日志

error_log()：始终为文本格式
php-fpm.log：文本格式（无法直接改为 JSON）

三、工程实践：何时用 JSON？

▶ 1.必须用 JSON 的场景

集中式日志系统：
- ELK（Elasticsearch + Logstash + Kibana）
- Grafana Loki + Promtail
自动化分析：
- 需要按user_id、request_id聚合日志

▶ 2.推荐用文本的场景

本地开发/调试：
- 人类直接阅读（tail -f laravel.log）
简单服务器部署：
- 无日志收集系统

▶ 3.混合策略（最佳实践）

// config/logging.php'channels'=>[// 本地保留文本日志（方便调试）'daily'=>['driver'=>'daily','path'=>storage_path('logs/laravel.log'),'level'=>'debug','days'=>14,],// 同时输出 JSON 到标准输出（供 Docker/Logstash 捕获）'stderr'=>['driver'=>'monolog','handler'=>StreamHandler::class,'with'=>['stream'=>'php://stderr',],'formatter'=>JsonFormatter::class,],],

四、避坑指南

陷阱	破局方案
盲目全量 JSON	本地开发保留文本日志，生产环境输出 JSON 到 stderr
忽略上下文字段	在 JSON 日志中添加`request_id`、`user_id`等关键字段
未处理多行异常	使用`JsonFormatter`的`batchMode`避免异常堆栈破坏 JSON 结构