HarmonyOS应用实战-启示散页-99-发布前日志别靠人工删：用 ReleaseLogAudit 检查白名单

HarmonyOS 应用实战 99发布前日志别靠人工删用 ReleaseLogAudit 检查白名单本地工具类应用也会处理用户内容提问、答案、收藏、导入文本、题库名称。调试阶段为了排查方便很容易顺手把对象、错误、参数整段打进hilog。等到发布前再靠人工搜索删除风险很高因为日志分散在 entry、HSP 页面、服务和 HAR 仓储里。“答案之书”当前工程的日志多数已经比较克制比如首页只记录deckId和问题长度抽取服务只记录题库 id、索引和数量。但发布前仍需要一张明确白名单哪些字段能打哪些字段不能打扫描命令怎么跑发现异常后改哪里。当前日志分布不是一个文件能看完先用命令看全项目日志rg-nhilog\\.(info|warn|error|debug)D:\ProgramData\huawei\lesson\The_Book_of_Answers\entry\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHAR\src\main\ets当前能看到的典型位置包括层级文件日志类型entryEntryAbility.ets生命周期、启动失败entryIndex.ets提交入口、问题长度entrySeedLoader.ets默认题库播种、恢复原因HSP 服务AnswerPickService.ets抽取题库、索引、总数HSP 服务DeckService.ets保存、重命名、删除题库 idHAR 仓储PreferencesStore.ets偏好读写失败这说明发布前不能只检查一个服务文件。真正要做的是把日志调用当成一类交付项统一审计。当前做得对的地方记录长度和计数首页提交问题时没有打印问题正文consttrimmed:stringthis.question.trim();constparams:DrawingParams{deckId:this.currentDeckId,question:trimmed||undefined};hilog.info(DOMAIN,TAG,submit deck%{public}s qLen%{public}d,params.deckId,trimmed.length);抽取服务也没有打印答案正文constidx:numberpickIndexExcluding(deck.answers.length,excludeIndex);constans:Answerdeck.answers[idx];hilog.info(DOMAIN,TAG,pick deck%{public}s idx%{public}d/%{public}d,deckId,idx,deck.answers.length);returnans;这两处是很好的边界可以记录deckId、长度、索引、数量不能记录question原文和answer.text。文章要把这种边界写成规则而不是依赖开发者每次都自觉。风险点错误对象和 JSON.stringify日志里仍有需要关注的模式比如hilog.error(DOMAIN,testTag,Failed to set colorMode. Cause: %{public}s,JSON.stringify(err));JSON.stringify(err)不一定包含用户内容但它是一个风险形态一旦错误对象里携带业务参数就会把字段整体打出去。发布前审计时应该把JSON.stringify、raw、text、question、answers、import这类关键词单独扫出来。白名单先定义清楚建议把日志字段分成三类类别可以记录不要记录标识deckId、favoriteId、错误分类完整题库对象计数qLen、answerCount、idx/total答案正文状态seedVersion、schemaVersion、路径阶段导入原文错误受控错误码、简短原因整个 payload 或 JSON 文本这张白名单不只是安全要求也能提升排障效率。日志里出现“题库保存失败count1”比出现一整段答案文本更容易判断问题且不会泄露用户内容。用 SafeLog 封住业务日志可以先从业务层开始封装不必一次替换所有系统生命周期日志typeSafeLogValuestring|number|boolean;classSafeLog{staticinfo(tag:string,event:string,fields:Recordstring,SafeLogValue):void{constmessage:stringObject.keys(fields).sort().map((key:string):string${key}${fields[key]}).join( );hilog.info(DOMAIN,tag,%{public}s %{public}s,event,message);}}业务代码调用时只传白名单字段SafeLog.info(TAG,answer.pick,{deckId,index:idx,total:deck.answers.length});不要提供any或对象直传接口。日志封装越方便传大对象越容易在调试时把正文塞进去。发布前脚本扫敏感词不需要等到审查时才人工翻代码可以先准备一组rg命令rg-nhilog\\.(info|warn|error|debug)D:\ProgramData\huawei\lesson\The_Book_of_Answers\entry\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHAR\src\main\etsrg-nhilog\\..*(text|question|raw|answers|JSON\\.stringify|payload|import)D:\ProgramData\huawei\lesson\The_Book_of_Answers\entry\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHSP\src\main\etsD:\ProgramData\huawei\lesson\The_Book_of_Answers\libraryHAR\src\main\ets第一条命令列出所有日志点第二条命令只抓高风险字段。命中不一定就是错误但必须人工确认。把当前日志归类当前工程可以先按下面方式判断日志判断说明submit deck qLen保留只记录题库 id 和问题长度pick deck idx/total保留没有答案正文save deck id count保留没有题库名和答案文本add favorite total保留只记录数量JSON.stringify(err)复核错误对象来源要确认onRestore bundleVersion复核可以记录版本但不要扩展成备份体这个归类可以放进发布前清单。每次新增日志先问它属于哪一类再决定能否合入。调试日志要有构建开关有些问题确实需要在本地看正文比如导入解析失败时看原始片段。但这类日志只能放在调试构建下constRELEASE_LOG:booleantrue;functiondebugOnlyUserText(tag:string,text:string):void{if(RELEASE_LOG){return;}hilog.debug(DOMAIN,tag,debug text%{public}s,text);}真实工程里RELEASE_LOG应该从构建模式或编译常量读取而不是手写常量。这里的重点是原则正式包日志路径不能接收用户正文。验证路径发布前至少跑三类验证验证命令或操作期望静态扫描rg hilog\\.日志点全列出敏感字段扫描rg textquestion交互抽样提问、导入、收藏、恢复后抓日志不出现问题正文、答案正文、导入全文如果这篇只是文章改写不要写成“发布包已完成审计”。真正的审计要在工程代码和设备日志上完成。常见问题日志排查要避免两个极端一个是把用户正文全打出来另一个是删到只剩“失败”。可维护的做法是在日志里保留阶段、owner、id、计数和错误分类同时把问题正文、答案正文、导入原文挡在发布包之外。现象原因修复正式日志出现用户问题直接打印question改成qLen日志出现完整答案打印Answer对象只记answerId或索引导入失败日志很长打印 raw import只记长度和错误分类错误日志无法判断删除过度只剩“失败”保留 owner、阶段、计数收口第 99 篇的核心是把日志当成交付边界而不是发布前手工删几行。当前工程已经有一些正确做法记录长度、计数、id不记录正文。后续要补的是 SafeLog 封装、敏感字段扫描和发布前抽样让日志既能排障又不带出用户内容。最小闭环可以先从两件事开始所有新增业务日志必须写清楚白名单字段发布前固定跑一次rg敏感字段扫描。等这两项稳定后再把常见事件收进SafeLog。这样日志不是被动清理而是在编码阶段就被限制在可发布的字段范围内。