日志系统理解：为什么 console 不再是“直接输出”

在写了几天 HarmonyOS 代码之后，我逐渐意识到一个细节：

日志这件事，和我之前在 Web 或 Node 环境里的体验，其实差别挺大。

一开始只是觉得“有点不顺手”，但后来回头看，发现问题不在工具，而在认知——我把它当成了一个“简单输出工具”，但它实际上是一个系统级能力。

console 并不是简单打印

最开始我写了一行最基础的代码：

console.error('error')

在 Web 或 Node 里，这基本等同于一件事：

把一段字符串输出到控制台，路径非常简单：

代码 → stdout → 控制台

但在 DevEco Studio 里，这一行代码的行为明显不一样。

我现在的理解是，这里的 console 并不是直接打印，而是一个“日志接口”，它的背后接入的是 HarmonyOS 的系统日志框架（类似 Android 的 Logcat / HiLog）。

也就是说，这一行代码更接近：

代码 → 系统日志服务 → IDE日志窗口

这里多出来的这一层“系统日志服务”，其实就是整个体验差异的来源。

日志从“应用行为”变成了“系统行为”

一旦意识到这一点，很多之前觉得奇怪的现象就能解释了。

比如：为什么日志有分级（info / error）？为什么会看到很多“不是我写的日志”、为什么需要过滤、筛选

这些在 Web 环境里其实不常见，但在系统级日志体系里是默认存在的。

换句话说：

日志不再只是“你的输出”，而是“系统里的一部分数据流”。

IDE 本身也不是日志的“产生者”，而更像是一个“观察者”，负责从系统日志里把内容展示出来。

如果从开发体验上说，我一开始的直觉是：不如浏览器控制台那么“爽”。但这个“不爽”，其实是有原因的。我现在的一个阶段性判断是，主要来自三个方面。

第一，是日志分级带来的复杂性

在 Web 里，console 输出基本就是一条一条的信息流，很少需要关心级别。

但在 HarmonyOS 里error、info、debug 是分层的，不同级别可能有不同展示策略。这本身是更专业的设计，但在刚开始用的时候，会增加一点认知成本。

第二，是日志缓冲机制

日志并不是每一条都“实时刷出来”的。更像是先进入系统 → 再统一调度输出。这会带来一个直观感受：有时候日志不是“立刻出现”，偶尔会有延迟或集中刷新。和浏览器那种“同步打印”的感觉不太一样。

第三，是多进程环境

这一点其实是最底层的原因。

HarmonyOS 应用运行在系统环境中，日志来源不止一个：你的应用进程、系统服务、其他组件当这些日志混在一起时，如果没有过滤，就会出现：信息很多，但不够干净。这也是为什么 DevEco Studio 提供了各种过滤能力（按包名、Tag、级别等）。

一个认知转变：从 console 到日志系统

回头看，我觉得这里最大的变化其实不是“工具不同”，而是：

从“console思维”切换到了“日志系统思维”

在 console 思维里：输出是直接的，数据是单一的，环境是可控的。

但在日志系统里：

• 输出是分层的
• 数据是多源的
• 环境是系统级的
  

这两套思维如果不切换，很容易产生误解，比如以为日志“丢了”，以为 console 不生效，以为 IDE 有问题。但其实只是路径变复杂了。

当前阶段的一个理解

如果用一句话总结我现在对 HarmonyOS 日志系统的理解：

console 只是入口，真正工作的，是背后的系统日志框架。

这也意味着，后面如果要做更复杂的调试（比如性能分析、问题排查），这套日志体系反而是优势，而不是负担。