ThinkPHP如何配置Json日志_Json格式日志输出配置【结构化】

想让ThinkPHP的日志以JSON格式输出，方便被ELK、Loki这类日志系统统一采集和分析吗？这确实是个提升运维效率的好习惯。下面，我们就来一步步拆解，看看如何从零开始，完整地配置ThinkPHP的JSON日志功能。

一、启用JSON格式日志（File通道）

最基础的配置，是从File类型的日志通道入手。它本身就支持通过一个简单的参数开启结构化输出。一旦启用，每条日志都会变成标准的JSON对象，里面规规矩矩地装着时间、级别、消息这些关键字段，无论是人读还是机器解析，都方便多了。

具体操作很简单：

首先，找到你应用配置目录下的那个config/log.php文件。

然后，在channels['file']这个配置项里，把'json'参数的值设置为true。

别忘了，同时要确认'type'确实是'File'，并且'path'指向的目录有写入权限。

保存配置，重启一下应用让它生效。最后，你可以故意触发一条日志记录（比如记录个警告信息），再去看看日志文件里的内容，是不是已经变成了整齐的JSON字符串。

二、配置自定义JSON日志通道（Console通道）

如果你的应用跑在Docker或Kubernetes这类容器环境里，日志通常需要直接打到标准输出（stdout），好让外部的日志采集器（比如Promtail）抓走。这时候，光配置File通道就不够了，得专门为控制台输出创建一个JSON通道。

怎么弄呢？

还是在config/log.php的'channels'数组里，新增一个通道，名字可以叫'console_json'。

关键的一步来了：把'type'设置成一个自定义的驱动类，比如'app\service\JsonConsole'。

接下来，你得去实现这个类。在app/service/JsonConsole.php文件里，创建一个类，让它继承think\log\driver\File或者直接实现think\log\DriverInterface接口。核心是重写里面的write方法，在写入前，先把日志记录数组用json_encode转成JSON字符串。

最后，在这个write方法里，别往文件写了，改用file_put_contents('php://stdout', $json_line . "", FILE_APPEND)，把JSON行直接输出到控制台。

配置好后，你可以把'default'默认通道改成它，或者在需要的地方用Log::channel('console_json')->info(...)来指定使用这个通道。

三、配置全局JSON日志处理器

有时候，我们希望在每条日志被记录前，都能自动给它“加点儿料”，比如注入当前请求的ID、用户信息或者模块名称。这样，无论日志从哪个通道出去，结构都是统一且信息丰富的。这就要用到processor（处理器）机制了。

操作起来也不复杂：

在config/log.php的根级别配置中，添加一个'processor'项，它的值是一个闭包函数。

这个闭包会接收到$record这个参数，也就是原始的日志记录数组。你可以在里面，向$record['context']里追加新的字段，比如从think\Request对象里拿到请求ID，从Session或Token里解析出用户ID。

处理完后，把$record返回去，它接下来就会被编码成JSON写入日志。

记得检查一下，确保各个独立的通道配置里没有设置自己的'processor'，以免把全局的这个给覆盖了。配置完，写条日志验证一下，看看新增的字段是不是已经乖乖地躺在JSON里了。

四、配置JSON日志时间格式与字段映射

默认生成的JSON日志，时间字段用的是ISO 8601格式。但问题来了，你的日志收集系统（比如某些ELK套件）可能只认特定的字段名，比如@timestamp，或者要求时间戳是毫秒级的整数。这时候，就需要我们对输出格式做定制化映射了。

首先，在File通道的配置里，把'format'设为null或者空字符串，目的是关掉默认的字符串模板格式化，让JSON驱动全权接管。

然后，在我们之前自定义的那个JsonConsole驱动的write方法里（如果是File通道也需要类似处理，可以创建另一个自定义驱动），手动构造最终的JSON数组。这里你可以大展拳脚：把$record['time']转换成毫秒时间戳，并赋值给@timestamp字段；把'level'字段名改成'severity'，把'msg'改成'message'，以适配像OpenTelemetry这样的通用规范。

在输出前，用json_last_error()检查一下编码是否成功，万一失败了，最好有个回退机制，比如把原始数组记下来，同时记录一条错误日志，免得日志丢了都不知道。

最终，确保生成出来的每行日志，其字段名和值类型都符合下游日志平台的要求。

五、配置JSON日志敏感字段过滤

JSON日志虽然结构清晰，但也带来了一个安全隐患：如果一不小心把用户的密码、API令牌、手机号这些敏感信息原样记录了进去，那麻烦就大了。因此，在日志被序列化成JSON之前，进行敏感信息过滤或脱敏，是必不可少的安全步骤。

这个过滤逻辑，通常放在全局的'processor'闭包里执行是最合适的。

你可以在闭包中，递归地遍历$record['context']和$record['extra']这两个数组，寻找键名包含'password'、'token'、'auth'、'id_card'等敏感词的字段。

找到之后，将其值替换成一串星号******，或者统一的标记如'[FILTERED]'。

特别要注意$record['context']['data']这种字段，它常常包含了完整的API请求或返回数据，需要做深度扫描。如果发现里面含有敏感键，可以考虑将整层数据替换成一个简单的标记，比如['filtered' => true]。

为了双重保险，也可以在自定义的JsonConsole驱动的write方法开头，再对整个$record数组执行一次脱敏逻辑。

所有配置完成后，务必进行验证：检查日志文件，确保敏感信息已经消失不见，同时其他正常的日志字段和JSON结构都保持完整、正确。