最小复现用例:把「偶现 bug」变成必现

按「缩小输入—缩小路径—固定环境」三步收敛,产出可提交的复现脚本。

什么时候用:遇到偶发 bug,说不清触发条件,只能反复试;提给同事也没人复现得了。

提示词(整段复制)

你是调试专家。请帮我把下面这个偶现问题收敛成最小复现。

现象:{{现象}}
出现频率与环境:{{出现频率}}
已知线索:{{线索}}
相关代码或配置:{{相关代码}}

输出要求:
1. **假设清单**:列出 3~5 个可能原因,每个标注「如何用一次实验排除」。
2. **收敛步骤**:按顺序给出三轮实验:
   ① 缩小输入(哪些数据可以删掉仍能复现)
   ② 缩小路径(哪些前置操作可以跳过)
   ③ 固定环境(版本、并发数、时序、缓存状态)
3. **复现脚本**:给一段可直接运行的代码/命令(含必要的 sleep、并发、重试),目标是**稳定复现**。
4. **判定标准**:什么现象出现即确认「已复现」,避免把别的错误当成它。
5. **下一步**:复现之后应该采集哪些信息(日志、堆栈、状态快照)。

约束:
- 不猜测「可能是缓存问题」这种没有排除动作的结论。
- 复现脚本必须是确定性的,不依赖「多试几次」。

复制时把 {{变量}} 换成你自己的内容;变量名不要改,改了模型容易把它当普通文字。

要替换的变量

变量示例值
{{现象}}每天凌晨 2 点左右,定时任务偶发执行两次,导致数据重复
{{出现频率}}约每周 2~3 次,生产环境,测试环境从未出现
{{线索}}两台服务器都部署了定时任务,日志时间戳相差不到 1 秒
{{相关代码}}node-cron 每小时跑一次,没有分布式锁

实操建议

常见问题

生产环境不能随便试怎么办?

先在预发环境复刻机器数量与时钟源,用同一份配置和并发数。生产上只做只读的信息采集。

复现不了就不能修吗?

能修,但要先证明假设。本例加分布式锁属于「无论根因是什么都该做」的正确性修复,可以先做。

配套工具