为什么日志需要统一格式
你有没有遇到过这种情况：系统出了问题，急着查日志，结果打开一看，有的时间用中文“上午”，有的用24小时制，还有的干脆只写分钟数？开发同事A写的是JSON，同事B却用纯文本，搜索关键字都对不上。这种混乱的日志格式，不仅浪费排查时间，还容易漏掉关键信息。
日志不是写给自己看的日记，而是给团队、运维甚至自动化工具读的。统一格式能让所有人快速定位问题，也能方便后期用脚本批量分析。
核心字段不能少
一个标准的日志条目至少包含四个基本要素：时间戳、日志级别、模块名称和具体信息。比如你在做一个订单系统，某次支付失败，日志应该是这样：
[2024-05-13 14:28:36] ERROR payment_service - 支付请求超时，订单ID: 10086，用户UID: 9527这里时间用了ISO 8601标准格式，级别明确标出ERROR，模块名写清是payment_service，后面跟上具体事件。这样一目了然，谁都能看懂。
时间格式要一致
别小看时间写法。有人喜欢“2024年5月13日”，有人写“May 13 14:28”，机器解析起来全乱套。建议全部使用UTC或固定时区的时间，格式为 YYYY-MM-DD HH:mm:ss。如果涉及毫秒，可以加上 .SSS：
[2024-05-13 14:28:36.123]这样排序、跨服务对比都方便，也不会因为夏令时搞错时间。
日志级别合理划分
INFO、WARN、ERROR这三个是最常用的。DEBUG在生产环境一般关闭。举个例子：
[2024-05-13 14:30:01] INFO order_processor - 订单创建成功，ID=10087
[2024-05-13 14:30:05] WARN inventory_check - 库存不足，自动转为预售模式
[2024-05-13 14:30:08] ERROR payment_gateway - 调用银行接口返回503通过级别能快速筛选出异常情况，不用一行行翻。
结构化输出更高效
现在很多系统支持JSON格式日志，更适合被ELK这类工具收集。例如：
{"time":"2024-05-13T14:28:36Z", "level":"error", "module":"auth", "msg":"login failed", "uid":9527, "ip":"192.168.1.100"}字段清晰，程序处理起来省力，还能直接做图表统计登录失败来源IP分布。
团队协作靠约定
光一个人写得好没用，得整个项目组一起遵守。可以在项目文档里写清楚日志规范，新成员一来就知道该怎么写。也可以在代码提交检查中加入日志格式校验，不符合的不让合并。
别觉得这是小事。等哪天半夜报警响了，你能三分钟内定位到问题，就知道统一规范有多值了。