一次审核反馈只有一句"支付结果页偶现空白"。开发机上复现不了，普通日志又混着账号、订单号和网络参数，既不能直接提交，也很难证明问题已经修复。
一、审核失败后，最缺的不是更多日志
这次 Demo 叫 ReviewTrace Lab 。目标不是做一套通用埋点平台，而是把某次上架审核的复现过程收拢成可提交、可校验、可过期的证据包。审核案例 ID 为 review_20261001_12，构建号 720120，问题发生在支付结果页从后台恢复时。
原来的做法是让测试人员复现后导出整段 HiLog。文件里有几万行，无关模块很多，还可能出现账号、订单号、访问令牌和完整 URL。删得太少有合规风险，删得太多又失去上下文；更麻烦的是，大家无法确认截图、日志与测试步骤是不是来自同一次复现。
最终一轮收集了 428 个业务事件，脱敏 37 个字段，直接丢弃 6 个疑似密钥；按三个关键阶段生成 3 个日志切片，清单与文件摘要校验 3/3 PASS，状态 EVIDENCE_READY。证据包没有保存真实账号、原始令牌和完整订单号，默认 72 小时过期。
这次改造的判断很简单：审核证据不是"把日志打包"，而是一个有边界的数据产品。事件进入时要结构化，导出前要脱敏，切片后要有清单，最终还要验证每个文件确实属于同一案例和同一构建。
二、事件先结构化，禁止自由拼接字符串
最早的日志长这样：pay result failed user=... order=... url=... token=...。它对开发者很方便，却让后续脱敏几乎只能依赖正则。字段一换顺序，规则就可能漏掉。
当前代码解决"源头不可控"。业务层只能提交白名单事件和结构化参数，敏感字段在进入 HiAppEvent 之前就被替换或拒绝。事件保留 caseId、buildNo、stage 和匿名会话 ID，方便后续切片。
ts
import { hiAppEvent } from '@kit.PerformanceAnalysisKit'
const ALLOWED = new Set(['page_enter', 'request_end', 'state_restore', 'render_ready'])
export async function recordReviewEvent(name: string,
stage: string, params: Record<string, string | number>): Promise<void> {
if (!ALLOWED.has(name)) throw new Error(`EVENT_NOT_ALLOWED:${name}`)
const safe = redactParams(params)
await hiAppEvent.write({
domain: 'review_trace',
name,
eventType: hiAppEvent.EventType.BEHAVIOR,
params: {
case_id: 'review_20261001_12',
build_no: 720120,
stage,
session_hash: 's_91a72c',
...safe
}
})
}调用发生在四个确定节点：进入结果页、接口结束、状态恢复、首帧可见。它不记录用户点击的自由文本，也不记录响应体。redactParams 返回的是新对象，不原地修改业务参数，避免后续代码误用脱敏后的值。
正式项目要注意，HiAppEvent 负责记录运行事件，不等于可以随意采集信息。事件名称、字段用途和保存周期仍需经过合规评审。Demo 的匿名会话值由一次复现随机生成，不能用设备标识或账号做稳定映射。页面销毁后不需要保留监听器，因为这里使用主动写入；如果扩展为订阅系统事件，则必须成对移除 watcher。
三、脱敏器先看键，再看值
只按字段名过滤会漏掉 extra 中意外拼进来的令牌；只按值正则又容易把普通长字符串误判为密钥。我们采用两层规则：token/password/secret 等键直接丢弃，账号、订单、手机号做保留结构的哈希；其余字符串再走 URL、Bearer 和长密钥检测。
下面的代码解决"37 个字段需要替换、6 个密钥不能进入证据包"的问题。每次处理还会返回审计结果，但审计里只记录规则名和字段路径，不记录原值。
ts
interface RedactAudit {
path: string
action: 'MASK' | 'DROP'
rule: string
}
export function redactParams(input: Record<string, string | number>):
Record<string, string | number> {
const out: Record<string, string | number> = {}
for (const [key, value] of Object.entries(input)) {
const lower = key.toLowerCase()
if (/token|password|secret|authorization/.test(lower)) {
audit({ path: key, action: 'DROP', rule: 'secret-key' })
continue
}
if (typeof value === 'string' && /user|phone|order/.test(lower)) {
out[key] = `hash:${sha256(value).slice(0, 10)}`
audit({ path: key, action: 'MASK', rule: 'identity-hash' })
continue
}
out[key] = typeof value === 'string' ? scrubValue(value, key) : value
}
return out
}数据变化不是简单"字符变少"。订单 A202610011234 会变成固定长度的 hash:...，同一证据包内仍能判断多个事件是否属于同一订单；令牌字段则完全消失，连哈希也不保留。完整 URL 只留下 scheme、host 与路径模板，查询参数按白名单选择。
哈希必须使用本次证据包的随机盐，否则不同导出包之间可能形成稳定关联。盐只在内存中参与计算，不写入清单。重复调用脱敏器应得到同样的安全形态，不能出现 hash:hash:...，所以函数先识别已脱敏前缀并跳过。单元测试里还要加入大小写混合、嵌套 JSON 字符串和超长字段。
四、用阶段标记切片，而不是按时间猜
审核人员给出的复现步骤是"支付完成---切后台---返回结果页"。如果简单导出故障前后 30 秒，设备卡顿或测试人员停顿都会让边界漂移。我们改为由事件阶段定义切片：PAY_CONFIRMED、BACKGROUND_RETURN、FIRST_FRAME，每段保留前后少量上下文。
这段代码解决"切片是否属于同一次复现"。每个事件都带案例、构建和匿名会话；生成清单时再次检查三者，混入其他会话就拒绝导出。
ts
export interface EvidenceSlice {
file: string
stage: string
eventCount: number
sha256: string
}
export async function buildEvidence(events: ReviewEvent[]): Promise<EvidenceSlice[]> {
const scoped = events.filter(item =>
item.caseId === 'review_20261001_12' &&
item.buildNo === 720120 && item.sessionHash === 's_91a72c')
const groups = groupByStage(scoped,
['PAY_CONFIRMED', 'BACKGROUND_RETURN', 'FIRST_FRAME'])
const slices: EvidenceSlice[] = []
for (const group of groups) {
const file = `${group.stage.toLowerCase()}.jsonl`
const bytes = encodeJsonLines(group.events)
await atomicWrite(file, bytes)
slices.push({
file, stage: group.stage, eventCount: group.events.length,
sha256: sha256(bytes)
})
}
return slices
}428 个事件最终分到 3 个切片，文件名与阶段固定，不使用用户输入。atomicWrite 先写临时文件并校验长度，再重命名，避免导出中断留下半个证据包。切片完成后原始内存缓冲立即清空，页面只拿到清单，不持有全部事件。
如果某个阶段缺失，状态应停在 INCOMPLETE，不能为了凑齐三个文件生成空切片。重复点击导出使用 caseId + buildNo + sessionHash 作为幂等键，已完成的证据只做校验，不再次写一份。页面退出时可以取消尚未开始的阶段，但正在执行的原子写入要完成或清理临时文件。
五、证据校验比压缩成功更重要
生成 ZIP 并不代表证据可信。我们在清单里记录案例 ID、构建号、匿名会话、切片名称、事件数、摘要、生成时间和过期时间；压缩前重新读取三个文件计算摘要，只有 3/3 PASS 才允许进入 EVIDENCE_READY。
这一轮的关键数据是：事件 428，脱敏字段 37，丢弃密钥 6，切片 3，摘要通过 3/3，包大小 284 KB。复现链显示 PAY_CONFIRMED → BACKGROUND_RETURN → FIRST_FRAME，其中旧版本在恢复后缺少 render_ready，修复版本已经补齐，空白页能被明确定位到状态恢复与首帧之间。
手机运行页把这些结果直接展示出来，同时显示过期时间 2026-10-04 12:42。红色批注只指向"密钥丢弃 6"和"摘要 3/3 PASS"，帮助审核材料的制作人员确认安全门和完整性门都通过。
六、提交审核前的最后边界
证据包默认不自动上传。测试人员在页面确认案例、构建号、时间范围与字段统计后，才执行导出；如果平台要求通过指定入口提交，就按当前审核流程操作，不把日志发送到未授权服务。72 小时到期后，本地包和撤销不了的临时文件都要清理。
1. 页面生命周期不能截断证据生命周期
最初的导出逻辑写在页面组件里，用户切到后台再回来，组件重建导致内存里的事件数组丢失，恰好把最重要的 BACKGROUND_RETURN 阶段切断。现在页面只展示收集状态，真正的会话由业务容器持有；窗口隐藏不会停止记录，案例关闭、超时或用户明确取消才结束会话。
页面重新出现时，通过 caseId + sessionHash 读取当前计数，不重新注册一套重复监听。若前一个页面实例仍未完成注销，新实例会发现同一订阅键已存在并复用，避免一个事件被收两次。测试中连续前后台切换 12 次，事件序号保持单调，重复序号为 0。
会话结束后按顺序执行：停止接收新事件、等待当前写入完成、生成切片、清空原始缓冲、校验清单。任何一步失败都不会直接显示 EVIDENCE_READY。若只完成两个阶段，页面明确显示 INCOMPLETE 2/3，并列出缺失的 FIRST_FRAME，让测试人员知道需要重新复现，而不是提交一个看似完整的 ZIP。
2. 开发日志和审核证据使用不同出口
HiLog 仍然用于开发期实时观察，HiAppEvent 则承载有限的结构化事件。两者不能简单互相替代：HiLog 适合看执行细节，但输出范围大、字段自由；审核证据强调字段白名单、固定阶段和可验证清单。Demo 的底部调试面板会显示两者的关联序号，却不会把完整 HiLog 原样塞进证据包。
遇到框架层异常时，我们只提取与本次匿名会话时间窗相关的错误码、线程类别和模块名，不带完整堆栈中的路径与参数。若问题确实需要堆栈，单独走受控附件并再次脱敏，不能因为"审核需要"就放宽整个事件模型。不同证据类型在清单里有不同 contentType，校验器也按类型检查必需字段。
这层区分还让故障定位更快。428 个事件里，真正进入三个切片的只有与复现阶段相关的 76 个；其余统计事件用于本地判断，不随包导出。证据越小，审核人员越容易看到状态恢复后缺少首帧事件这一条主线，同时也减少不必要的数据暴露。
3. 修复前后必须是两个不可覆盖的样本
我们为旧构建与修复构建分别生成证据。旧构建号 720119 的链路停在 BACKGROUND_RETURN，新构建号 720120 继续到 FIRST_FRAME。两个包使用不同匿名会话、不同生成时间和不同摘要，不允许用同一个目录覆盖。AppGallery Connect 中的说明只引用案例 ID 和构建号，具体文件按提交入口附加。
校验页面会并排显示两份清单的阶段差异，但不会合并它们的事件。这样可以证明修复解决了什么，而不是拿新日志去解释旧现象。若新构建仍失败，第三次复现生成新的样本；历史包在过期前保持只读，任何手工修改都会让摘要校验失败。
审查用日志也不应成为常驻高频埋点。Demo 只在测试构建和明确的复现开关开启时记录详细事件，正式版本保留最小必要指标。采样开关、构建号与开关来源要写入清单，避免拿调试包的行为解释线上发布包。
最后，截图与日志要由同一个匿名会话关联，但截图里不能展示真实身份信息。若修复后重新复现，应生成新的会话和清单，不能覆盖旧证据；旧包用于说明问题，新包用于证明结果，二者的构建号必须可区分。
这条链路真正解决的不是"怎么多打几行日志"，而是如何把复现过程变成可提交的证据：HiAppEvent 提供结构化事件，脱敏器限定数据边界，切片器保留问题上下文，摘要清单证明文件没有混用。到了 EVIDENCE_READY，我们交出去的才是一份能被复核的材料，而不是一包需要对方重新猜的日志。
最后一次演练里，我们故意篡改了一个切片的单个字符，校验立即从 3/3 PASS 变成 2/3 FAIL，导出按钮同步禁用。这个小测试证明完整性门不是页面上的装饰，而是真正阻断错误材料进入审核流程。