HarmonyOS 7 / API 26 HiLog 日志怎么防泄漏手机号、token 和发布包调试日志怎么挡住日志是开发时最顺手的排查工具但也是最容易被忽略的隐私风险。HarmonyOS 7.0.0 / API 26 项目里如果把手机号、token、完整接口参数直接打进 HiLog开发阶段看起来很方便到了发布包和上架审核前就会变成风险点。这篇只讲一个具体问题日志怎么写才能既能定位问题又不把敏感信息带出去。运行环境和检查范围项目取值系统版本HarmonyOS 7.0.0满足 HarmonyOS 5.0.0 及以上要求API 版本API 26工程模型Stage 模型语言与框架ArkTS ArkUI关注能力HiLog 日志、隐私合规、发布包检查、上架审核验证目标开发态可排查发布态不泄漏手机号、token 和完整请求参数这个主题适合上架前自查也适合团队代码提交前做静态检查。它不是为了把所有日志都删掉而是把日志分级、脱敏和发布态关闭这三件事做成固定规则。问题一般怎么发生坏例子通常长这样hilog.info(0x0000,Login,phonephone, tokentoken)这段代码的问题不是 HiLog 本身而是日志内容没经过处理。手机号、token、完整请求体这些字段一旦出现在日志里后面再靠人工检查就很难完全挡住。我会把风险拆成三类敏感字段没有脱敏所有环境都打同一套日志发布包里还保留 debug 级别日志。先用脚本把坏例子挡住下面这个脚本模拟三种日志策略裸日志、开发态脱敏日志、发布态日志。坏例子必须失败好例子必须通过。constcases[{name:bad-raw-log,usesLevelSwitch:false,masksPhone:false,masksToken:false,blocksReleaseDebug:false},{name:good-dev-log,usesLevelSwitch:true,masksPhone:true,masksToken:true,blocksReleaseDebug:false},{name:good-release-log,usesLevelSwitch:true,masksPhone:true,masksToken:true,blocksReleaseDebug:true},];functioninspect(item){consterrors[];if(!item.usesLevelSwitch)errors.push(missing log level switch);if(!item.masksPhone)errors.push(phone number is not masked);if(!item.masksToken)errors.push(token is not masked);if(item.name.includes(release)!item.blocksReleaseDebug)errors.push(debug log is still enabled in release build);return{...item,passed:errors.length0,errors};}constresultcases.map(inspect);console.log(JSON.stringify({total:result.length,passed:result.filter((item)item.passed).length,failed:result.filter((item)!item.passed).length,result,},null,2));本地结果是 3 个用例里 2 个通过、1 个失败。失败的是裸日志这正好说明检查能挡住最危险的写法。{total:3,passed:2,failed:1}第一层先做字段脱敏不要在每个调用点临时想要不要脱敏。更稳的方式是先封一个统一方法所有日志都从这里过。functionmaskPhone(value:string):string{returnvalue.replace(/(\d{3})\d{4}(\d{4})/,$1****$2)}functionmaskToken(value:string):string{if(!value||value.length10)return***returnvalue.slice(0,4)***value.slice(-4)}functionsanitizeLog(input:Recordstring,string):Recordstring,string{return{...input,phone:input.phone?maskPhone(input.phone):,token:input.token?maskToken(input.token):,}}这样调用侧不需要记住每个字段怎么处理只要先把日志参数交给 sanitizeLog。第二层日志要分环境开发包需要更多信息发布包需要更严格。我的习惯是把日志开关放在统一入口不让业务代码自己判断。typeLogLeveldebug|info|warn|errorconstisReleasetruefunctioncanPrint(level:LogLevel):boolean{if(isReleaseleveldebug)returnfalsereturntrue}functionsafeLog(level:LogLevel,tag:string,data:Recordstring,string){if(!canPrint(level))returnconstsafeDatasanitizeLog(data)hilog.info(0x0000,tag,JSON.stringify(safeData))}这里重点不是 isRelease 这个变量怎么来而是日志策略要集中管理。发布包不应该依赖每个开发者手动删 debug 日志。第三层上架前怎么查上架审核前我会至少查四件事搜索 hilog、console、JSON.stringify看有没有裸输出搜索 phone、token、password、authorization看有没有直接拼日志确认发布态 debug 日志被开关挡住对照隐私声明看日志里有没有声明之外的采集字段。这一步很实际。很多问题不是代码不会写而是发布前没人把日志当成隐私出口来查。两个用例怎么验第一个用例是登录失败。输入手机号和 token让日志输出失败原因。合格结果应该能看到错误码和接口名称但看不到完整手机号和完整 token。第二个用例是发布包检查。把环境切到 release再跑 debug 日志。合格结果应该是 debug 日志完全不输出warn 和 error 仍然可以输出必要的错误码。方案对比方案好处问题手动不打敏感字段改动少靠人记容易漏调用点各自脱敏比裸日志好规则分散后期难维护统一日志入口脱敏加环境开关最稳适合团队复用前期要补一个小封装我会选第三种。日志是基础设施越早统一后面越少返工。最后怎么避免再出问题我的做法是把日志检查放进提交前和发布前两道门提交前挡明显的敏感字段发布前再查 release 包日志策略。这样既不影响开发定位问题也能减少上架前临时大面积改代码的风险。HiLog 本身是工具真正决定安全的是我们往里面写什么。把脱敏、分级、发布态开关做成固定入口日志就能继续帮我们定位问题而不是变成新的审核风险。两个复现场景先把问题跑出来场景一登录失败时直接打印请求参数登录失败最容易偷懒开发时想知道手机号、验证码、token 到底有没有传过去于是把整段对象直接打出来interfaceLoginRequest{phone:stringverifyCode:stringtoken:string}functionbadLoginLog(req:LoginRequest){hilog.info(0x0000,Login,requestJSON.stringify(req))}这个写法排查问题很快但风险也很直接日志里会出现完整手机号、验证码和 token。只要日志被导出、截屏、上传到排障系统敏感信息就跟着出去了。我更倾向于把日志入口收住而不是要求每个调用处都记得脱敏constLOG_DOMAIN0x0001typeLogLeveldebug|info|warn|errorfunctionmaskPhone(phone:string):string{if(!phone||phone.length7)return***returnphone.slice(0,3)****phone.slice(-4)}functionmaskToken(token:string):string{if(!token)returnemptyreturntoken.slice(0,4)***token.slice(-4)}functionsafeLoginLog(level:LogLevel,req:LoginRequest,isRelease:boolean){if(isReleaseleveldebug)returnconstsafePayload{phone:maskPhone(req.phone),verifyCode:***,token:maskToken(req.token)}hilog.info(LOG_DOMAIN,Login,JSON.stringify(safePayload))}这里的关键不是多写几行工具函数而是把规则固定下来手机号只能保留首尾验证码永远不打印token 只能留很短的定位片段发布态直接关掉 debug 日志。场景二接口异常时把完整响应体打出来第二类问题更隐蔽。很多接口失败会把请求头、服务端返回、错误码一起打印代码看起来像这样functionbadApiErrorLog(url:string,headers:Recordstring,string,body:string){hilog.error(0x0000,Api,urlurl, headersJSON.stringify(headers), bodybody)}这个问题不只出现在登录页。支付、个人资料、设备绑定、消息推送这些链路只要 headers 里带 Authorization日志就可能把凭证带出去。更稳的做法是把“允许打印的字段”和“必须拦截的字段”分开constBLOCK_KEYS[authorization,token,cookie,set-cookie,phone,verifycode]functionsanitizeRecord(input:Recordstring,string):Recordstring,string{constoutput:Recordstring,string{}Object.keys(input).forEach((key){constlowerKeykey.toLowerCase()output[key]BLOCK_KEYS.includes(lowerKey)?***:input[key]})returnoutput}functionsafeApiErrorLog(url:string,headers:Recordstring,string,statusCode:number){hilog.error(LOG_DOMAIN,Api,JSON.stringify({url,statusCode,headers:sanitizeRecord(headers)}))}这段代码故意不打印完整 body。很多时候定位接口问题只需要 url、状态码、traceId、少量白名单字段完整 body 反而是最容易出事的部分。我会怎么选调用处自觉还是统一封装方案优点问题适合场景每次打印前手动脱敏改动小上手快很容易漏代码审查压力大临时排查不适合长期维护封装 safeLog 方法规则统一方便 CI 检查前期要梳理字段规则推荐适合团队项目发布包完全关闭日志风险最低线上问题定位会变弱金融、账号、安全要求很高的模块我会选第二种保留必要日志但所有入口都走 safeLog。这样开发态还能定位问题发布态也不会把敏感字段带出去。放进 CI 里的最低检查只靠人眼看日志代码不稳定。至少要在提交前挡住几个高风险写法constfsrequire(fs)constsourcefs.readFileSync(entry/src/main/ets/pages/LoginPage.ets,utf8)constblockedPatterns[/hilog.(debug|info|warn|error)([^]*(phone|token|authorization|cookie)/i,/JSON.stringify([^]*(request|headers|body)/i,/verifyCode/i]consthitblockedPatterns.find((pattern)pattern.test(source))if(hit){console.error(日志检查失败存在可能泄漏敏感字段的日志写法)process.exit(1)}console.log(日志检查通过)这个检查不需要一开始就做得很复杂。先挡住手机号、token、authorization、cookie、验证码再逐步把项目里的敏感字段补进去。上架前自查清单发布包里是否还有 debug 级别日志登录、支付、用户资料、设备绑定页面是否打印手机号、token、验证码网络错误日志是否打印完整 headers 和 body线上排障是否只保留 traceId、状态码、接口名和脱敏后的关键字段代码提交前是否有脚本拦截高风险日志团队是否约定所有日志统一走 safeLog不允许业务代码直接拼接敏感字段。这个问题越早处理越省事。等到上架前再全局搜索日志通常会发现一堆临时排查代码混在业务里很难判断哪条能删、哪条还要保留。把脱敏、分级、发布态关闭做成固定入口后面每个页面都能复用。