复现率统计与压测

偶发 bug 的世界没有百分之百，只有复现率。这篇讲复现率统计与压测的方法论——Air 系列从真实工程里淬出来的纪律。

▍为什么单轮数据无效
偶发问题的触发时点方差极大：同一段压力脚本，这次五秒出问题、下次四分钟才出——风暴时点的分布跨越数量级。这意味着：一次没复现不等于修复（可能是运气），一次复现也不等于必然（可能是巧合）。判定任何补丁效果都要三轮以上重复，这是硬纪律。

▍复现率基线
先测基线：原版本在标准压力下连续跑 N 轮（十轮量级起），记录复现轮数与出现时点——基线给补丁效果的比较锚点。修复后同条件再跑 N 轮：复现率显著下降（比如八轮三现降到十轮零现）才有说服力；持平或抖动（十轮两现变十轮一现——可能只是方差）就要加轮数或承认没修好。

▍压力场景的设计
复现压力不是瞎点：从用户反馈的触发路径提炼（某操作序列、某数据形态、某环境组合）；逐步加码（先原速，再加并发、加数据量、加速度）；组合维度（操作序列交叉系统事件——切后台、来电、低电量提示这类系统插入事件常是偶发的真正触发器）。压力工具：自动化注入（uitest 篇）加系统事件模拟。

▍数据的记录
每轮记录：轮次、是否复现、复现时点、现场证据（日志片段与探针计数）。汇总成表——复现点的分布形态也有信息量（都在切后台后两秒内=强相关线索；均匀散布=更随机，查竞态方向）。

▍骰子型问题的特别纪律
时点漂移本身就是证据：如果加了日志后复现时点系统性变化（变多或变少），说明改动影响了时序——这正是竞争类问题的旁证（时序敏感）。记录里要保留这类观察。

▍验收
修复结论附带数据：基线复现率、修复后复现率、轮数。没有这三样的偶发 bug 修复结论，评审直接退回——数字面前，感觉不算数。

更多真实移植案例，欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。