直接在docker-compose.yml中为每个服务配置logging属性，可强制输出结构一致、可轮转、带标识的标准日志；推荐统一使用json-file驱动，设max-size:"10m"、max-file:"3"、tag:"{{.Name}}"，并禁用ANSI色码、避免应用写文件日志，确保所有日志经stdout捕获。
直接在 docker-compose.yml 中为每个服务配置 logging 属性，就能强制所有服务输出结构一致、可轮转、带标识的标准日志，无需修改应用代码。
统一使用 json-file 驱动并规范格式
这是最轻量也最实用的起点。所有服务共用同一套日志行为，避免因驱动不同导致格式混乱：
- 固定用
json-file驱动：确保每条日志都是结构化 JSON，含时间戳、流类型（stdout/stderr）、容器名等元数据 - 统一设置
max-size和max-file：比如"10m"和"3"，防止某个服务狂打日志占满磁盘 - 用
tag: "{{.Name}}"或tag: "{{.ImageName}}/{{.Name}}"标识来源，让docker-compose logs输出时一眼分清哪条来自哪个服务
为不同环境选配合适驱动
开发、测试、生产可差异化配置，但保持接口一致：
- 本地调试用
json-file：开箱即用，docker-compose logs -f直接看到带颜色、按时间合并的日志流 - 测试/预发环境用
syslog：把所有服务日志发到统一 syslog 服务器，便于集中归档和基础告警 - 生产环境用
fluentd或gelf：对接 Fluentd 或 Graylog，支持字段提取、路由、脱敏和长期存储
避免常见格式陷阱
即使配置了统一驱动，应用层仍可能破坏日志一致性：
- 禁用应用内日志框架的“彩色控制符”或“ANSI 转义序列”：这些字符在 JSON 日志里会变成非法内容，导致解析失败
- 不要让应用自行写文件日志：Docker 只捕获 stdout/stderr；若应用另开文件，这部分日志就脱离 Compose 管控
- 确保所有服务都输出到 stdout（不是 stderr）做主业务日志：stderr 应仅用于真正异常，否则
docker-compose logs里混杂大量干扰信息
配合命令行实现精准查看
配置好 logging 后，用标准命令就能高效使用：
-
docker-compose logs -f --tail=50 -t web api db：实时看三个服务最新 50 行，带时间戳，按时间顺序交叉显示，适合查请求链路 -
docker-compose logs --since="10m" -t web | grep "ERROR"：快速捞出 Web 服务最近 10 分钟的错误行 -
docker-compose logs -f --no-color api：关闭颜色，方便重定向到文件或管道给其他工具处理
