别把日志当废纸——HiLog 日志体系与调试技巧（Echo_Wish 私房话版）

大家好，我是 Echo_Wish。写代码久了，总看到这样两类人：一类把日志当作吐槽台，“反正出 bug 了才看”；另一类把日志当成救命草，早早埋好埋实。今天咱聊的，是鸿蒙/HiLog 这套日志体系怎么用才能既高效又体面——少啰嗦，多实战，按我常用的套路走：引子 → 原理通俗讲 → 实战代码 → 场景应用 → Echo_Wish 式思考。

引子（有共鸣）

你是否遇到过这些场景：

• 线上某条能力延迟飙升，日志里一堆 INFO，却找不到根因；
• 开发环境一切正常，上线后崩溃，日志里看不到关键变量；
• 为了找一次偶发错误，把日志量级开到 100%，结果磁盘跟着陪葬。

这些恼人的事，90% 都和“日志没提前设计”有关。HiLog 本质上不是魔法，但用得巧，能让你把故障从“捉迷藏”变成“透明诊断”。

原理讲解（通俗版）

鸿蒙的 HiLog（在 OpenHarmony/OHOS 体系中常见）是系统级的日志框架，特点可以概括为：

1. 层级化日志（Level）：常见的有 FATAL、ERROR、WARN、INFO、DEBUG、VERBOSE（不同版本名称可能轻微差别）。用来区分严重性，便于筛选。
2. 标签（Label）/模块化：通常通过 HiLogLabel 把日志和模块、子系统关联，便于按服务/模块过滤。
3. 性能友好：系统层面有 logd/hiLogd 做接收与落盘，应用只负责发出日志，避免同步阻塞。
4. 可配置性：通过系统属性或者运行时接口可以调整某些模块的日志级别（动态开关），支持采样/采集策略。
5. 兼容调试工具：和 adb logcat、系统日志查看工具集成，线上日志收集通常有 agent/collector 拉取 hiLogd 的输出到集群存储。

关键点：日志是一个信号体系，不是海量文本。好的日志具备结构、上下文（trace id）、采样和敏感信息屏蔽策略。

实战代码（要能直接拿去用）

下面给出常见的三种语言示例（C++、Java、JS/ArkTS 风格伪代码），便于在鸿蒙不同开发模式下直接套用。

C++（Native）基本用法

#include <hilog/log.h>

static constexpr HiLogLabel LABEL = {LOG_CORE, 0xD001100, "EchoWishModule"};

void DoWork(int id) {
    HiLog::Info(LABEL, "Start DoWork, id=%{public}d", id);
    if (id < 0) {
        HiLog::Warn(LABEL, "id is negative: %{public}d", id);
    }
    // 模拟错误
    if (id == 999) {
        HiLog::Error(LABEL, "Critical error: id==999, aborting");
    }
    HiLog::Debug(LABEL, "Finish DoWork, id=%{public}d", id);
}

注意：使用 %{public}s / %{public}d 等占位符能避免敏感信息泄露到私有标志（不同平台占位符语法略有差异，按对应 SDK 文档调整）。

Java（Ability/Framework）示例

import ohos.hiviewdfx.HiLog;
import ohos.hiviewdfx.HiLogLabel;

private static final HiLogLabel LABEL = new HiLogLabel(HiLog.LOG_APP, 0xD001100, "EchoWishJS");

public void handle(String userId) {
    HiLog.info(LABEL, "handle start, user=%{public}s", userId);
    try {
        // ...
    } catch (Exception e) {
        HiLog.error(LABEL, "process failed: %{public}s", e.toString());
    }
}

ArkTS/JS（伪示例）

// 假设存在封装模块 hiLog
import { HiLog, HiLogLabel } from 'hilog';
const LABEL = new HiLogLabel(3, 0xD001100, "EchoWishTS");

function apiHandler(event) {
  HiLog.info(LABEL, `apiHandler start, reqId=${event.reqId}`);
  // ...
  HiLog.debug(LABEL, `response payload size=${JSON.stringify(payload).length}`);
}

场景应用（如何在真实工程里落地）

下面是几类我常用的“日志实战模板”：

1. 打埋点 vs 打诊断日志

• 埋点：轻量、结构化，面向统计（如 API 成功率、耗时）。
• 诊断日志：详细、伴随上下文（trace id、请求路径、关键变量），仅在采样或错误发生时启用。

实践：在 RPC/HTTP 请求入口处生成 trace_id，通过上下文传递给下游；普通请求只记录少量埋点（状态码、延迟），遇到异常按采样策略收集 full dump。

2. 动态日志开关

通过系统属性或管理 API 实现模块级别的 debug 开关。线上出现疑难问题时，短时把相关模块的日志级别从 INFO 拉到 DEBUG，问题定位后回滚，避免日志爆炸。

3. 敏感信息处理

对用户隐私（手机号、身份证、token）做屏蔽或脱敏。使用 %{private}s 或应用端显式脱敏函数。

4. 日志采样与上报

对于高 QPS 的路径，采用固定比率采样或异常触发采样（出现异常则全量上报），结合异步上报机制，保证性能。

Echo_Wish 式思考（温度 + 观点）

写日志是一门“艺术而非机械”。我的一些体会，分享给你们：

1. 日志就是你的未来自己：有人说写日志是给别人看的，错——写日志最大的受益者是未来的你。你下次再来 debug，那些当年你“懒得写”的上下文，会让你怀疑人生。
2. 日志要可操作：不是把一堆文本丢在磁盘上，而是要能快速被搜索、聚合和报警。结构化日志 + Trace ID 是基础。
3. 别把日志当万能药：日志不是万能，面对性能瓶颈，堆栈采样、profiling、指标（metrics）也很关键。把日志和指标、追踪结合起来，问题解决效率成倍提升。
4. 对运维友好：日志策略应包含“告警背后的决策规则”。监控只告诉你“哪里痛”，日志应该告诉你“为什么痛”以及“下一步怎么做”。

最后一句话：把日志当成产品去设计，而不是临时工写出来的调试台账。你会惊喜地发现，系统稳定性和团队心态都会变好——这就是可观测性真正的力量。