日志等级（Log Levels）是给每条日志标注的严重程度标签，用于控制「什么信息被记录、什么信息被展示、什么信息触发告警」。主流标准分为 DEBUG、INFO、WARN、ERROR、FATAL 五级，严重程度依次递增。 等级体系的核心价值是：日常把噪音压到最低，出问题时又能按等级快速过滤和报警。
五个标准等级速查表
| 等级 |
含义 |
典型内容 |
生产环境 |
触发告警 |
| DEBUG |
调试细节 |
变量值、SQL 语句、函数入参 |
关闭 |
否 |
| INFO |
正常的业务节点 |
用户登录、订单创建、任务启动 |
开启 |
否 |
| WARN |
异常但可自动恢复 |
重试成功、降级触发、慢请求 |
开启 |
聚合后人工关注 |
| ERROR |
功能失败，影响当前操作 |
接口 5xx、支付失败、空指针 |
开启 |
是 |
| FATAL |
系统级不可用 |
数据库连不上、服务无法启动 |
开启 |
是（P0 响应） |
每个等级的判断标准
实践中等级误用比缺日志更常见。以下是可执行的判断标准：
DEBUG：给开发者自己看的
- 判断标准：这条信息在系统正常运行时毫无价值，只在排查具体 Bug 时有用；
- 典型内容：函数入参出参、中间计算结果、缓存命中情况；
- 关键原则：生产环境默认关闭。不是删掉，是过滤掉——出问题时能临时打开。
INFO：给「看系统在做什么」的人
- 判断标准：半年后回看这条日志，能还原出用户的操作轨迹；
- 典型内容：关键业务动作（注册、下单、发布），任务开始/结束与耗时；
- 反面例子：把每个 HTTP 200 都打成 INFO——这是访问日志该干的事，不要污染业务日志。
WARN：异常发生了，但系统扛住了
- 典型内容：重试后成功、触发限流/降级、请求耗时超过阈值；
- 风险信号：WARN 数量突增往往是 ERROR 的前兆，应接入趋势监控。
ERROR：用户的某个操作失败了
- 典型内容：外部服务调用失败、数据校验异常、未捕获异常（Uncaught Error）；
- 关键要求：每条 ERROR 必须带上下文（URL、用户/租户 ID、请求参数、堆栈），否则只是一条无法行动的噪音。
FATAL：系统已经不可用了
- 典型内容：数据库连接失败、依赖的配置缺失、启动失败；
- 实践提示：Web 应用里 FATAL 很少——大多数「系统挂了」表现为成批的 ERROR，用「ERROR 突增告警」覆盖即可，不要滥用 FATAL 稀释严重性。
浏览器 Console 里的日志等级
前端日志等级与后端同名但能力不同。Console 原生支持：
| 方法 |
Console 中的等级 |
用途 |
console.debug() |
Debug（默认隐藏，需勾选 Verbose） |
开发期调试 |
console.log() |
Info |
普通输出 |
console.info() |
Info |
同上，语义化写法 |
console.warn() |
Warning，黄色 |
可恢复异常提示 |
console.error() |
Error，红色，带堆栈 |
失败与未捕获异常 |
两个实用建议：
前端用 console.debug 而不是 console.log 写调试信息——生产构建会自动被默认过滤器隐藏，不需要手动清理；
未捕获异常（window.onerror / unhandledrejection）默认就是 ERROR 级，是线上排查的第一线索。
前端日志的特殊难题：用户不帮你采集
后端日志集中在服务端，出了问题随时可查。前端日志却散落在每个用户的浏览器里——用户报「页面坏了」，而 Console 报错和失败请求随着那次页面会话消失了。等用户按教程打开 DevTools（步骤见如何打开浏览器控制台），报错早已被刷新冲掉。
所以前端日志策略要回答的问题不是「等级怎么定」，而是「出错瞬间的日志怎么留存下来」。常见方案：
| 方案 |
原理 |
代价 |
| 自建上报 |
全量把 console 输出发回服务端 |
存储/隐私成本高，采样难定 |
| 前端监控平台 |
全量采集 + 会话回放 |
按量计费，中小团队成本高 |
| 按需采集（随 Bug 报告带走） |
用户提交反馈时，自动把当时 Console/Network 的报错一并附上 |
成本最低，覆盖「用户主动报告」这一最大来源 |
第三种方案与缺陷报告天然契合：用户报 Bug 的那一刻，正是需要日志的那一刻。
BugCapturer 采用的就是这种按需采集：用户（哪怕完全不懂技术）通过浏览器扩展或页面内嵌 SDK 提交带标注的截图/录屏时，报告自动附带当前的 Console 报错（含 ERROR 堆栈）与 Network 失败请求，以及 URL 和浏览器环境（详见诊断功能）。开发者收到的报告自带 ERROR 级日志上下文，不需要再让用户「打开 F12 复制一下」。报告可生成免登录分享链接，或自动推送进 Slack / Microsoft Teams 频道统一跟踪。
常见误区
| 误区 |
正确做法 |
用 console.log 打一切，上线不清理 |
分级：调试用 debug，业务节点用 info，构建时压缩 debug |
| 把失败打成 INFO「以免吓到运维」 |
失败就是 ERROR，告警靠等级而不是靠人翻日志 |
| ERROR 不带上下文，只有一条消息 |
强制附带 URL、参数、堆栈，否则等于没记 |
| 所有日志都开 DEBUG 方便排查 |
等级是过滤器：平时关 DEBUG，问题发生时再按需打开 |
| WARN 大量积压无人处理 |
WARN 接趋势告警，突增即 ERROR 前兆 |
FAQ
Q：log levels 一共有哪几个？
A：主流标准是 DEBUG、INFO、WARN、ERROR、FATAL 五级；部分框架（如 Syslog、Trace 系）会有 TRACE/NOTICE/CRITICAL 等变体，但语义与上表一一对应。
Q：logging levels 应该怎么选和配置？
A：开发环境全开（DEBUG 起），生产环境 INFO 或 WARN 起；ERROR 级接告警，WARN 级接趋势监控。库与业务代码分开配置，避免依赖库的 DEBUG 刷屏。
Q：前端有必要像后端一样做日志分级吗？
A：有必要但可以简化：区分「调试 / 正常 / 警告 / 错误」四级即可，重点保证 ERROR 带堆栈，并解决「出错瞬间日志留存」的问题。
Q：用户报 Bug 时怎么让他把 Console 报错发过来？
A：让非技术用户复制报错基本不可行。用 BugCapturer 这类工具在提交反馈时自动抓取 Console/Network 报错，见上文「按需采集」一节。