bug-triage

Bug triage

明确范围

1. 阅读仓库说明，并检查当前分支、状态和相关差异。
2. 确定用户是否只要求诊断，还是也授权修复。
3. 在询问缺失信息前，先检查可用的错误信息、日志、测试和代码。
4. 如果会影响调查，记录预期行为、实际行为、环境、发生频率以及最后一次确认正常的状态。

复现并隔离问题

1. 使用最小且可靠的复现方式。保留原始故障输出。
2. 如果故障是间歇性的，每次只控制一个变量：时间、随机性、并发、数据或重试。
3. 端到端追踪故障路径。编辑前搜索该函数或组件的所有调用方。
4. 提出可证伪的假设，并运行范围最小、足以确认或否定该假设的检查。
5. 只有在确定回归边界能显著缩短搜索时间时，才使用历史记录或 git bisect。

明确区分以下结果：

• 已确认的产品回归；
• 原本就存在或基线故障；
• 环境、凭据、服务或依赖故障；
• 证据不足，无法复现。

获得授权后修复

1. 添加或调整最小的回归检查，使其在已确认的根因存在时失败。
2. 修复共用的根因，而不是只在某个可见调用方添加防护。
3. 避免无关重构、升级依赖、格式调整造成的大量改动，以及宽泛的异常处理。
4. 重新运行复现步骤、针对性的回归检查，以及项目中范围最小的相关检查。

使用仓库已选定的包管理器、包装器和命令。根据仓库说明、清单、锁文件和脚本推断这些工具；不要仅因本机已安装其他工具就换用它们。

报告

包括：

• **观察结果：**确切症状和受影响范围。
• **根因：**已确认的解释，或明确标注的主要假设。
• **变更：**修改的文件和行为，或 diagnosis only。
• **验证：**运行的命令及其结果，包括基线故障。
• **剩余风险：**未经测试的路径、不稳定行为或外部阻碍。

只有在用户需要可复用的受理表单时，才使用 references/bug-report-template.md。