HarmonyOS 应用实战 69hilog 别记录用户正文用事件码保留排障线索开发时在 hilog 打出 question 和 answerText 很方便但答案之书的用户问题、题库和答案都可能是私人内容。日志一旦被截图、导出或附在反馈里正文就离开了设备。本文解决四个问题用事件码替代用户正文只记录安全 id、长度、数量和阶段把日志格式集中管理验证发布态不会输出题库全文日志不是业务备份日志的目标是定位阶段不是复原用户内容。能用长度、计数、hash、事件码说明的问题就不要打印原文。泄露链hilog.info(question%s, question) - 用户反馈截图 - 私人问题进入工单 - 排障通道变成泄露通道这篇和第 58 篇的边界不同第 58 篇管用户可发送报告第 69 篇管日志写入源头。日志本身不记录正文导出时才不会被迫补救。事件码先覆盖核心动作事件码要稳定、可检索、可聚合。不要把自然语言错误散落在每个页面。enumBookEventCode{StartupReadySTARTUP_READY,DrawCandidateEmptyDRAW_CANDIDATE_EMPTY,FavoriteWriteFailedFAVORITE_WRITE_FAILED,RouteParamInvalidROUTE_PARAM_INVALID}事件码要覆盖核心动作而不是让每个页面写一段自然语言。稳定事件码才能被搜索、聚合和发布前审计。日志参数只允许白名单字段安全字段包括阶段、事件码、deckId hash、候选数量、文本长度。正文不进入日志输出格式。interfaceSafeLogPayload{code:BookEventCode;deckHash?:string;qLen?:number;candidateCount?:number;errorCode?:string;}白名单字段让日志保持可用阶段、数量、长度、截断 id 可以定位故障但不会还原用户问题。BookLogger 统一输出格式集中封装后页面和服务不再直接拼 hilog 字符串。classBookLogger{staticinfo(payload:SafeLogPayload):void{hilog.info(0x0001,AnswerBook,code%{public}s deck%{public}s qLen%{public}d count%{public}d,payload.code,payload.deckHash??-,payload.qLen??0,payload.candidateCount??0);}}BookLogger集中格式后业务代码不再直接拼hilog.info。后续要调整公开字段也只改一个 owner。抽取链路记录长度不记录问题问题长度可以帮助判断空输入、超长输入和是否来自推荐但不需要知道问题内容。classDrawDiagnostics{logDrawStart(deckId:string,question:string,candidateCount:number):void{BookLogger.info({code:candidateCount0?BookEventCode.StartupReady:BookEventCode.DrawCandidateEmpty,deckHash:Hash.sha256(deckId).slice(0,12),qLen:question.trim().length,candidateCount});}}抽取链路记录问题长度不记录问题文本。长度足以区分空输入、超长输入和推荐入口正文没有进入日志的必要。发布前搜索敏感日志模式不要只靠代码评审记忆。发布前用 rg 搜索常见危险字段和直接 hilog 调用。rg-nhilog\.(info|warn|error)|question|answerText|deckName|JSON.stringifyD:\ProgramData\huawei\lesson\The_Book_of_Answers发布前搜索敏感日志模式是为了发现新增代码绕开 logger。JSON.stringify、questionText、answerText都应该被重点看。hilog 排查表日志越详细不一定越好能定位阶段且不泄露正文才是正确目标。现象风险修复日志含 answerText泄露答案改 answerId/hash页面直接 hilog输出格式不可控统一 BookLogger只有错误文本无事件码难检索增加 BookEventCode如果日志里已经出现正文先不要讨论导出报告怎么脱敏。源头日志改干净后诊断导出才是真正安全的第二层。先从源头禁止正文进入 hilog第 58 篇解决“用户导出的报告怎么脱敏”第 69 篇要往前一步日志写入时就不接收正文。否则导出报告再安全开发截图、临时附件和系统日志里仍可能出现敏感内容。字段是否进入日志替代questionText否qLen、事件码answerText否answerId的安全片段deckName否deckHash候选数量是candidateCount这张白名单比“发布前记得删日志”可靠因为它让业务代码没有传正文的入口。发布前搜索要看直接调用和间接泄露只搜hilog.info不够。JSON.stringify(deck)、错误对象拼接、临时console风格输出都可能把正文带进日志。发布前至少搜三类模式。rg-nhilog\.(debug|info|warn|error)entry hsp har rg-nquestionText|answerText|deckName|JSON.stringifyentry hsp har rg-nBookLogger\.info|BookLogger\.warn|BookLogger\.errorentry hsp har第一条找直接日志调用第二条找敏感字段第三条确认是否走统一 logger。命中不是一定错误但每个命中都要判断是否会输出用户正文。交付记录要区分日志和诊断报告日志治理和诊断导出是两层证据。日志层证明源头不写正文报告层证明用户复制出去的内容也只包含白名单字段。两层缺一层都不要写“排障材料已安全”。证据证明BookLogger白名单日志调用格式受控敏感字段搜索记录新增代码没有绕过 logger脱敏报告样例用户导出内容可发送发布清单条目日志、诊断和隐私口径已对齐这篇文章的结论应限定为“日志写入策略和本地静态审计方法”没有设备hilog输出记录时不写真机日志已验证。日志事件码要能回到业务动作事件码不是越多越好。每个事件码都应该能回到一个业务动作和一个排查入口。比如DRAW_CANDIDATE_EMPTY回到抽取候选集ROUTE_PARAM_INVALID回到路由守卫FAVORITE_WRITE_FAILED回到收藏仓储写入。事件码业务动作第一排查点DRAW_CANDIDATE_EMPTY抽取答案当前题库答案数量ROUTE_PARAM_INVALID进入页面DrawingRouteGuardFAVORITE_WRITE_FAILED收藏写入FavoriteRepository.saveAllSTARTUP_READY启动完成Preferences 与 AppStorage 水合如果事件码不能指向排查点它就只是另一种自然语言日志。第 69 篇要把“少打正文”和“仍能排障”同时讲清楚否则读者会担心日志治理降低定位效率。人工评审时抽一条日志反推定位能力日志不记录正文以后团队可能担心不好排障。最好的评审方式是随机抽一条安全日志看它能否反推出下一步查哪里。log: codeDRAW_CANDIDATE_EMPTY deckab12-cd34 qLen6 count0 下一步查 deckHash 对应题库是否为空、候选过滤是否过严、当前 deckId 是否失效。 log: codeROUTE_PARAM_INVALID deck- qLen0 count0 下一步查路由入口、参数构造和 DrawingRouteGuard。如果一条日志既没有正文又能指向排查入口说明事件码设计是有效的。若日志去掉正文后完全无法定位就不是隐私治理的问题而是事件码和上下文字段设计太弱。最后一项看调试开关是否进入发布态日志治理还要检查临时调试开关。开发阶段可能会为了排查问题临时打开 verbose 日志发布前必须确认这些开关不会让正文重新进入输出。建议把开关名、默认值和 release 行为写进发布清单debug 包可以放宽事件数量release 包仍然只允许白名单字段。这样日志策略不会因为一次临时排障被悄悄改坏。开关debug 行为release 行为verboseLog可增加事件数量仍禁正文diagnosticsPreview可展示报告预览只展示脱敏字段小结hilog 要留下排障线索但不能留下用户正文。事件码、阶段、长度、数量和 hash 已经足够定位多数问题直接打印 question、answerText 和 deckName 应从发布态代码里移除。
HarmonyOS应用实战-启示散页-69-hilog 别记录用户正文：用事件码保留排障线索
发布时间：2026/8/2 3:07:14
HarmonyOS 应用实战 69hilog 别记录用户正文用事件码保留排障线索开发时在 hilog 打出 question 和 answerText 很方便但答案之书的用户问题、题库和答案都可能是私人内容。日志一旦被截图、导出或附在反馈里正文就离开了设备。本文解决四个问题用事件码替代用户正文只记录安全 id、长度、数量和阶段把日志格式集中管理验证发布态不会输出题库全文日志不是业务备份日志的目标是定位阶段不是复原用户内容。能用长度、计数、hash、事件码说明的问题就不要打印原文。泄露链hilog.info(question%s, question) - 用户反馈截图 - 私人问题进入工单 - 排障通道变成泄露通道这篇和第 58 篇的边界不同第 58 篇管用户可发送报告第 69 篇管日志写入源头。日志本身不记录正文导出时才不会被迫补救。事件码先覆盖核心动作事件码要稳定、可检索、可聚合。不要把自然语言错误散落在每个页面。enumBookEventCode{StartupReadySTARTUP_READY,DrawCandidateEmptyDRAW_CANDIDATE_EMPTY,FavoriteWriteFailedFAVORITE_WRITE_FAILED,RouteParamInvalidROUTE_PARAM_INVALID}事件码要覆盖核心动作而不是让每个页面写一段自然语言。稳定事件码才能被搜索、聚合和发布前审计。日志参数只允许白名单字段安全字段包括阶段、事件码、deckId hash、候选数量、文本长度。正文不进入日志输出格式。interfaceSafeLogPayload{code:BookEventCode;deckHash?:string;qLen?:number;candidateCount?:number;errorCode?:string;}白名单字段让日志保持可用阶段、数量、长度、截断 id 可以定位故障但不会还原用户问题。BookLogger 统一输出格式集中封装后页面和服务不再直接拼 hilog 字符串。classBookLogger{staticinfo(payload:SafeLogPayload):void{hilog.info(0x0001,AnswerBook,code%{public}s deck%{public}s qLen%{public}d count%{public}d,payload.code,payload.deckHash??-,payload.qLen??0,payload.candidateCount??0);}}BookLogger集中格式后业务代码不再直接拼hilog.info。后续要调整公开字段也只改一个 owner。抽取链路记录长度不记录问题问题长度可以帮助判断空输入、超长输入和是否来自推荐但不需要知道问题内容。classDrawDiagnostics{logDrawStart(deckId:string,question:string,candidateCount:number):void{BookLogger.info({code:candidateCount0?BookEventCode.StartupReady:BookEventCode.DrawCandidateEmpty,deckHash:Hash.sha256(deckId).slice(0,12),qLen:question.trim().length,candidateCount});}}抽取链路记录问题长度不记录问题文本。长度足以区分空输入、超长输入和推荐入口正文没有进入日志的必要。发布前搜索敏感日志模式不要只靠代码评审记忆。发布前用 rg 搜索常见危险字段和直接 hilog 调用。rg-nhilog\.(info|warn|error)|question|answerText|deckName|JSON.stringifyD:\ProgramData\huawei\lesson\The_Book_of_Answers发布前搜索敏感日志模式是为了发现新增代码绕开 logger。JSON.stringify、questionText、answerText都应该被重点看。hilog 排查表日志越详细不一定越好能定位阶段且不泄露正文才是正确目标。现象风险修复日志含 answerText泄露答案改 answerId/hash页面直接 hilog输出格式不可控统一 BookLogger只有错误文本无事件码难检索增加 BookEventCode如果日志里已经出现正文先不要讨论导出报告怎么脱敏。源头日志改干净后诊断导出才是真正安全的第二层。先从源头禁止正文进入 hilog第 58 篇解决“用户导出的报告怎么脱敏”第 69 篇要往前一步日志写入时就不接收正文。否则导出报告再安全开发截图、临时附件和系统日志里仍可能出现敏感内容。字段是否进入日志替代questionText否qLen、事件码answerText否answerId的安全片段deckName否deckHash候选数量是candidateCount这张白名单比“发布前记得删日志”可靠因为它让业务代码没有传正文的入口。发布前搜索要看直接调用和间接泄露只搜hilog.info不够。JSON.stringify(deck)、错误对象拼接、临时console风格输出都可能把正文带进日志。发布前至少搜三类模式。rg-nhilog\.(debug|info|warn|error)entry hsp har rg-nquestionText|answerText|deckName|JSON.stringifyentry hsp har rg-nBookLogger\.info|BookLogger\.warn|BookLogger\.errorentry hsp har第一条找直接日志调用第二条找敏感字段第三条确认是否走统一 logger。命中不是一定错误但每个命中都要判断是否会输出用户正文。交付记录要区分日志和诊断报告日志治理和诊断导出是两层证据。日志层证明源头不写正文报告层证明用户复制出去的内容也只包含白名单字段。两层缺一层都不要写“排障材料已安全”。证据证明BookLogger白名单日志调用格式受控敏感字段搜索记录新增代码没有绕过 logger脱敏报告样例用户导出内容可发送发布清单条目日志、诊断和隐私口径已对齐这篇文章的结论应限定为“日志写入策略和本地静态审计方法”没有设备hilog输出记录时不写真机日志已验证。日志事件码要能回到业务动作事件码不是越多越好。每个事件码都应该能回到一个业务动作和一个排查入口。比如DRAW_CANDIDATE_EMPTY回到抽取候选集ROUTE_PARAM_INVALID回到路由守卫FAVORITE_WRITE_FAILED回到收藏仓储写入。事件码业务动作第一排查点DRAW_CANDIDATE_EMPTY抽取答案当前题库答案数量ROUTE_PARAM_INVALID进入页面DrawingRouteGuardFAVORITE_WRITE_FAILED收藏写入FavoriteRepository.saveAllSTARTUP_READY启动完成Preferences 与 AppStorage 水合如果事件码不能指向排查点它就只是另一种自然语言日志。第 69 篇要把“少打正文”和“仍能排障”同时讲清楚否则读者会担心日志治理降低定位效率。人工评审时抽一条日志反推定位能力日志不记录正文以后团队可能担心不好排障。最好的评审方式是随机抽一条安全日志看它能否反推出下一步查哪里。log: codeDRAW_CANDIDATE_EMPTY deckab12-cd34 qLen6 count0 下一步查 deckHash 对应题库是否为空、候选过滤是否过严、当前 deckId 是否失效。 log: codeROUTE_PARAM_INVALID deck- qLen0 count0 下一步查路由入口、参数构造和 DrawingRouteGuard。如果一条日志既没有正文又能指向排查入口说明事件码设计是有效的。若日志去掉正文后完全无法定位就不是隐私治理的问题而是事件码和上下文字段设计太弱。最后一项看调试开关是否进入发布态日志治理还要检查临时调试开关。开发阶段可能会为了排查问题临时打开 verbose 日志发布前必须确认这些开关不会让正文重新进入输出。建议把开关名、默认值和 release 行为写进发布清单debug 包可以放宽事件数量release 包仍然只允许白名单字段。这样日志策略不会因为一次临时排障被悄悄改坏。开关debug 行为release 行为verboseLog可增加事件数量仍禁正文diagnosticsPreview可展示报告预览只展示脱敏字段小结hilog 要留下排障线索但不能留下用户正文。事件码、阶段、长度、数量和 hash 已经足够定位多数问题直接打印 question、answerText 和 deckName 应从发布态代码里移除。
)
来给你答案！)
)
