你是不是也在想——“鸿蒙这么火我能不能学会”答案是当然可以这个专栏专为零基础小白设计不需要编程基础也不需要懂原理、背术语。我们会用最通俗易懂的语言、最贴近生活的案例手把手带你从安装开发工具开始一步步学会开发自己的鸿蒙应用。不管你是学生、上班族、打算转行还是单纯对技术感兴趣只要你愿意花一点时间就能在这里搞懂鸿蒙开发并做出属于自己的App关注本专栏《零基础学鸿蒙开发》一起变强每一节内容我都会持续更新配图代码解释全都有欢迎点个关注不走丢我是小白酷爱学习我们一起上路 全文目录前言一、HiLog 是什么先简单说一下边界二、五个级别的官方定义三、基本调用方式四、最小实践五个级别各写一条五、几个容易理解偏差的地方六、容易踩坑的地方七、排查日志级别混乱的思路开发经验总结前言写日志这件事很多开发者要么全堆info要么遇到异常一律error久而久之日志就成了噪音。翻 Logcat 的时候满屏 ERROR但大多数只是一个接口返回了空值满屏 INFO但其中混着几条真正需要关注的状态变化。HiLog 提供了五个日志级别每一个都有官方明确的使用场景定义。这篇文章就围绕这五个级别结合一个最小示例说清楚它们之间的边界在哪里。一、HiLog 是什么先简单说一下边界HiLog 是 HarmonyOS 提供给应用层使用的日志打印系统对应ohos.hilog模块。在 ArkTS 工程中直接import hilog from ohos.hilog即可使用无需额外权限配置。这里要先区分两个常见误区console.log在 HarmonyOS 应用开发中也可以用但它是 ArkTS 运行时提供的基础输出不具备日志级别过滤、域标签管理等能力生产场景不推荐依赖它来管理日志。HiLog 对应的是 HarmonyOS 官方日志系统可以通过 DevEco Studio 的 Log 面板按 Level、Tag 过滤。HiLog 在 ArkTS 侧的 API 基本信息方法对应级别API 起始支持版本hilog.debug()DEBUGAPI 7hilog.info()INFOAPI 7hilog.warn()WARNAPI 7hilog.error()ERRORAPI 7hilog.fatal()FATALAPI 7hilog.isLoggable()级别过滤判断API 7这五个方法从 API 7 开始支持HarmonyOS 5.xAPI Level 12及当前主流版本均可使用无设备限制适用于 Phone、Tablet、2in1 等全形态。二、五个级别的官方定义HiLog 官方文档对五个级别的定义如下这里直接引用官方表述不做二次演绎DEBUG详细的流程记录通过该级别的日志可以更详细地分析业务流程和定位分析问题。该级别日志在正式发布版本中一般不会输出只有在调试版本或特意打开调试日志功能时才会生效。INFO用于记录业务关键流程节点以及异常情况下的关键信息这类信息应该对排查问题有帮助。WARN用于记录较为严重的不预期情况但是此时运行环境依然正常。ERROR应用发生了错误该错误需要被关注和修复该错误的发生会影响用户使用或功能运行。FATAL重大致命异常即将发生严重的程序错误。这五段官方定义里有几个词值得单独注意DEBUG 的定位是详细流程它明确说明正式发布版本一般不会输出。这意味着 debug 级别的日志在 release 包里默认可能被过滤不适合用来记录任何需要在生产环境追踪的信息。WARN 的关键词是运行环境依然正常。也就是说warn 不代表出错只代表出现了不预期的情况业务还在跑。ERROR 的关键是需要被关注和修复而且影响用户使用或功能运行。如果某个异常根本不影响用户感知就不应该是 error。FATAL 是即将发生严重的程序错误这个级别通常意味着应用可能即将崩溃或进入不可恢复状态。三、基本调用方式HiLog 的调用格式是固定的hilog.级别(domain,tag,format,...args)参数类型说明domainnumber日志所属业务域十六进制范围 0x0~0xFFFFtagstring用于标识调用者最长 31 字节formatstring格式化字符串支持 %{public}s、%{private}s 等隐私标识argsany[]对应格式化参数关于domain这是一个用来标识日志所属子系统或模块的数字应用开发中通常自定义一个固定值例如0x0001用来区分不同业务模块的日志。关于隐私标识格式化参数中%{public}s表示公开输出%{private}s表示隐私数据在日志中会被替换为private。如果什么都不标注默认是%{private}s也就是默认不暴露参数内容。四、最小实践五个级别各写一条下面用一个最小示例围绕一个模拟的用户订单查询流程演示五个级别各自适合记录什么。这段代码的目标是用同一个业务流程展示五个日志级别的合理使用位置而不是逐一罗列 API 用法。importhilogfromohos.hilog;constDOMAIN0x0001;constTAGOrderService;functionqueryOrder(userId:string,orderId:string):void{// DEBUG记录详细的入参和内部流程用于调试阶段追踪执行路径hilog.debug(DOMAIN,TAG,queryOrder called, userId%{public}s, orderId%{public}s,userId,orderId);if(!userId||!orderId){// ERROR参数缺失会直接导致功能无法运行需要修复hilog.error(DOMAIN,TAG,queryOrder failed: userId or orderId is empty);return;}constcachedResultgetFromCache(orderId);if(!cachedResult){// WARN缓存未命中不是错误但属于不预期的情况业务依然能继续hilog.warn(DOMAIN,TAG,Cache miss for orderId%{public}s, fallback to network,orderId);}// INFO记录关键业务节点表示正式发起了网络请求hilog.info(DOMAIN,TAG,Requesting order data from server, orderId%{public}s,orderId);constresponsefetchOrderFromServer(orderId);if(responsenull){// FATAL服务端连接完全失败可能意味着整个业务链路已经断裂hilog.fatal(DOMAIN,TAG,Server response is null, network or server may be unavailable);}}functiongetFromCache(orderId:string):object|null{// 模拟缓存查询这里直接返回 null 模拟未命中returnnull;}functionfetchOrderFromServer(orderId:string):object|null{// 模拟网络请求这里返回 null 模拟失败returnnull;}真正需要关注的几个地方debug用在了函数入口记录入参。这类信息调试时非常有用但在 release 包里不需要输出正好对应 DEBUG 级别的定义。warn用在了缓存未命中。缓存未命中是预期内可能发生的情况业务还在走用error就过重了。info用在了真正发起网络请求的时刻。这是业务关键节点排查问题时是否发起了请求是第一个要确认的问题。error用在了参数为空导致直接return的情况。这类问题需要开发者介入修复。fatal用在了服务端完全不可用、整个业务链路断裂的情况。这里是否用fatal可以根据实际场景评估核心判断标准是是否意味着应用即将进入不可恢复状态。五、几个容易理解偏差的地方1. 所有 try-catch 里的 catch 都用 error这是最常见的误用。catch住的异常不一定都是 error 级别。例如某个图片解码失败但应用会自动显示占位图用户感知不到任何问题——这种情况用warn更合适。只有当异常会影响用户正常使用某个功能才应该上升到error。2. debug 是我在调试所以用 debug不是。debug是一个日志级别代表这条日志在 release 包里不需要输出而不是我现在正在调试。如果某条日志在生产环境也需要可见就不应该用debug。3. 同一条日志能不能先 info 再 error不应该。每条日志只对应一个级别级别应该由这条信息在运行时代表的含义决定而不是由写代码的人当时的心情决定。4. format 中的参数默认是不可见的前面提到参数默认是%{private}s也就是在日志中会被替换成private输出。如果在调试时发现参数没有输出记得检查是否加了%{public}s。这一点在刚开始写 HiLog 时很容易被忽略。5. isLoggable 的作用HiLog 提供了hilog.isLoggable(domain, tag, level)方法可以在打印前判断当前日志级别是否可输出避免构造复杂的日志字符串产生不必要的性能开销。在日志内容构造本身有一定代价时建议先用这个方法判断一下。if(hilog.isLoggable(DOMAIN,TAG,hilog.LogLevel.DEBUG)){constdetailbuildExpensiveDebugInfo();// 只在 debug 可输出时才构造hilog.debug(DOMAIN,TAG,Detail: %{public}s,detail);}六、容易踩坑的地方domain 范围越界domain 的合法范围是0x0~0xFFFF如果传入超出范围的值按照官方接口约束行为是未定义的。建议统一在一个常量文件里定义好各个模块的 domain 值避免散落在各处。tag 长度超限tag 最长 31 字节。如果用了中文 tag注意 UTF-8 编码下中文字符占 3 个字节31 字节实际能容纳的中文字符并不多。format 字符串中使用 %d、%f 等格式符HiLog 支持标准的 C 风格格式符例如%d整数、%f浮点数、%s字符串。注意格式符和实际参数类型要匹配类型不一致可能导致输出异常。不要在 debug 里记录需要在生产排查的信息重申一次debug 日志在 release 版本中默认不输出。如果某条日志在出现生产问题时必须能看到就不能用debug级别。七、排查日志级别混乱的思路如果项目里日志用得比较乱可以按下面顺序梳理先看 error 和 fatal 是不是真的需要关注。把所有 error 过一遍问一个问题这个 error 发生时用户感知到了什么如果什么都没发生降到 warn 或 info。再看 info 是不是太多。info 应该是关键节点不是每一步都记录。如果每个函数入口都有 info考虑把纯流程追踪的改成 debug。检查 debug 里是不是有不该在生产消失的信息。如果有及时升级级别。检查 warn 是不是被当成了 info 用。warn 代表出现了不预期的情况如果只是记录正常流程中的一个分支用 info 即可。检查 fatal 的使用频率。fatal 应该极少出现如果频繁出现说明要么使用过重要么系统确实有严重问题需要处理。开发经验总结五个级别的核心区分标准是这条日志代表的运行时含义而不是代码位置或个人习惯。debug的定位是调试辅助release 版本默认不输出不适合记录生产环境需要的信息。warn不是轻量版 error它代表不预期但不影响运行两者有明确的语义区别。不要因为某个地方写了 try-catch 就自动打 error影响程度才是决定级别的标准。注意 format 参数的隐私标识默认不公开调试时没有输出要先检查这里。isLoggable可以避免在日志不可见时构造无意义的字符串在性能敏感路径上值得加上。如果你的项目已经积累了一段时间的日志代码可以尝试按模块统计一下各级别的比例——如果 error 和 info 的数量远远多于 warn通常是日志级别规划出了问题值得重新梳理一遍。❤️ 如果本文帮到了你…请点个赞让我知道你还在坚持阅读技术长文请收藏本文因为你以后一定还会用上如果你在学习过程中遇到bug请留言我帮你踩坑