为什么标题比正文更重要
好的 Bug 标题 = 在哪个页面 + 做了什么操作 + 结果错成什么样 + 什么条件下复现。 一句话把四件事说清，开发不用问你就能复现——这就是好标题和差标题的全部差别。下面 40 组对照示例，按登录、注册、支付、移动端、接口、性能、UI 七类场景列全，你可以直接照着自己的 Bug 改写。
开发者在缺陷列表里先扫的永远是标题。标题写得不明确，要么他得多问一轮，要么这条 Bug 被跳过。要命的是，标题写坏了，后面填的环境信息、复现步骤做得再认真也救不回来——没人会点开一个叫"按钮坏了"的工单。
判断一个标题好不好，只看四条：是否具体（点明组件/页面）、是否可观察（写事实，不写"不好用"）、是否含条件（浏览器、设备、账号类型、时间）、是否能一眼判断范围（是全局崩还是边缘场景）。
Bug 标题公式（4 段式）
[组件/页面] + [操作] + [异常结果] + [触发条件]
填法示例：
- 组件：结算页 / 登录弹窗 / 订单列表 /
POST /api/orders - 操作：点击、提交、上传、切换 Tab、扫码
- 异常结果：无响应、返回 500、数值多加一位、状态未同步、文案重叠
- 触发条件：Chrome 120、iOS 17.2、宽度 <390px、仅企业账号、网络超时后重试
英文团队常用同一套骨架：Component – Action – Result – Condition。骨架不变，语言换来换去都成立。
1. 登录与账号（7 组）
| 差标题 | 好标题 |
|---|---|
| 登录按钮没反应 | Chrome 120 下点击「登录」无响应，控制台报 TypeError: login is not a function |
| 忘记密码邮件收不到 | 使用 Gmail 邮箱点「忘记密码」后 30 分钟未收到重置邮件（已确认垃圾箱） |
| 登录后跳转错误 | 普通用户登录后被跳转到 /admin 而非 /dashboard，v5.3 起必现 |
| 验证码一直错 | 图形验证码输入正确仍提示「验证码错误」，仅隐私模式（无痕窗口）复现 |
| 账号被锁了 | 连续 3 次密码错误即永久锁定账号，提示文案却写「请 24 小时后重试」 |
| 多设备登录串号 | 同账号在第二台设备登录后，第一台设备会话未失效，仍可继续操作 |
| SSO 登录失败 | SSO 登录回调返回 Invalid signature，IdP 证书轮换后开始出现 |
要点：登录类 Bug 的条件字段（浏览器/账号类型/隐私模式）几乎决定复现概率，别省。
2. 注册与表单（7 组）
| 差标题 | 好标题 |
|---|---|
| 注册不了 | 邮箱含「+」号（如 user+test@x.com）注册时提示「邮箱格式错误」 |
| 手机号校验有问题 | 已输入 11 位 +86 手机号仍提示「请输入 11 位手机号」 |
| 密码强度提示错 | 已含数字的 8 位密码仍提示「需包含数字」 |
| 下拉框选不中 | 「国家/地区」下拉在输入 3 字符过滤后无法用键盘方向键选择 |
| 表单提交两次 | 注册表单按 Enter 提交两次，后台生成两条重复用户记录 |
| 必填项没校验 | 未勾选「同意服务条款」仍可提交，后台创建成功 |
| 时区默认值错 | 注册页时区默认显示 UTC+0，中国区用户应为 UTC+8 |
要点：表单类 Bug 用具体输入值代替描述，比写十句"输入有问题"都有用。
3. 支付与结算（7 组）
| 差标题 | 好标题 |
|---|---|
| 支付失败 | 订单金额 ¥1,299 在结算页显示为 ¥12,999（多一位），支付页金额同步错误 |
| 优惠券用不了 | 已过期优惠码仍显示「可用」，点击「应用」后返回 500 并清空购物车 |
| 购物车数量不更新 | 删除最后一件商品后顶部角标仍显示「1」，刷新页面才恢复 |
| 重复扣款 | 网络超时后重试支付，同一订单被扣款两次（订单号 #10231） |
| 发票信息不保存 | 结算页填写的公司发票信息，返回上一步再前进后被清空 |
| 退款状态不同步 | 后台已退款，用户端订单仍显示「已支付」（订单号 #10388） |
| 支付方式缺失 | 结算页缺少「微信支付」选项，仅企业账号类型下出现 |
要点：涉及金额、订单号的 Bug，把单号写进标题，排查速度能快一倍。
4. 移动端与响应式（6 组）
| 差标题 | 好标题 |
|---|---|
| 手机上错位 | iPhone 14（iOS 17.2）上「加入购物车」按钮与价格文字重叠，宽度 <390px 必现 |
| 页面没法滚动 | 移动端打开弹窗后页面锁定滚动，关闭弹窗后仍无法上下滚动 |
| 输入框被键盘挡住 | Android Chrome 键盘弹出时遮挡「提交」按钮，无法点击 |
| 横屏显示异常 | iPad 横屏（1024×768）下导航栏折行，Logo 与菜单重叠 |
| 图片不加载 | Safari iOS 16 商品详情页主图不显示，控制台返回 403（CDN 签名过期） |
| 点击热区太小 | 移动端分页按钮触控热区仅 12×12px，低于 44px 无障碍最小标准 |
要点：移动端一定要写具体机型 + 系统版本 + 屏幕宽度，"手机上"不是一个条件。
5. 数据、接口与权限（6 组）
| 差标题 | 好标题 |
|---|---|
| 导出失败 | 导出 1 万条以上订单报表返回 504，分批导出正常 |
| 时间显示错误 | 报表时间戳比实际早 8 小时，仅当用户时区为 Asia/Shanghai 时出现 |
| 搜索没结果 | 搜索「iPhone」返回 0 条，数据库中确实存在 12 条匹配记录 |
| 分页重复数据 | 订单列表翻至第 2 页时重复出现第 1 页最后 3 条记录 |
| 上传报错 | 上传 5MB 以上 PNG 返回 413，前端却提示「上传成功」且文件为空 |
| 权限越权 | 只读角色可调用 DELETE /api/projects/12 并成功删除项目 |
要点：接口类 Bug 标题里带上 HTTP 状态码 / 接口路径 / 阈值数字，等于把定位工作做了一半。
6. 性能与加载（3 组）
| 差标题 | 好标题 |
|---|---|
| 页面很卡 | 首页在 4G 网络下首屏 LCP 8.2 秒，主因是 2.1MB 未压缩 JS |
| 内存泄漏 | 连续切换 Tab 20 次后内存由 120MB 涨至 900MB，标签页最终崩溃 |
| 接口慢 | 商品列表接口 P95 响应 4.8 秒（基线 300ms），仅大促期间出现 |
要点：性能类必须给数字 + 基线，否则开发无从判断是否算缺陷。
7. 文案与 UI 细节（4 组）
| 差标题 | 好标题 |
|---|---|
| 有错别字 | 结算页「确任订单」应为「确认订单」 |
| 图标风格不统一 | 设置页 4 个图标中 2 个线性风格、2 个填充风格，视觉不一致 |
| 深色模式看不清 | 深色模式下输入框文字 #333 叠加深色背景，几乎不可见 |
| 错误提示不明确 | 上传失败仅提示「操作失败」，未说明原因与重试方式 |
要点：文案/UI 类 Bug 标题直接写出「错在哪 → 应该是什么」，评审成本最低。
7 个让标题变差的坏习惯
不同角色该怎么写
| 角色 | 建议写法 |
|---|---|
| QA / 测试 | 用完整 4 段式公式，条件字段写全（浏览器、设备、账号、网络） |
| 客服 / 运营转研发 | 写「用户视角的现象 + 可复现路径 + 截图」，不确定原因就不写原因，标注「待技术确认」 |
| UAT 验收 | 以验收标准为锚：「与验收标准 AC-3 不符：订单状态未在 5 秒内更新」 |
| 产品经理 | 标题写明「用户可感知的影响」，便于排优先级，但不要代替技术现象描述 |
中英文标题对照（给海外/双语团队）
| 中文标题 | 英文标题 |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | Cart badge not updated after removing the last item on checkout |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome keyboard covers the Submit button, making it untappable |
| 只读角色可删除项目（越权） | Read-only role can delete projects (privilege escalation) |
中文习惯"现象在前"，英文习惯"组件在前 + 句式首字母大写（sentence case）"。团队内部统一一种即可，统一比选哪种更重要。
常见问题（FAQ）
Bug 标题应该多长？ 控制在 60 个字符或 40 个汉字以内，保证在列表页不被截断。超过就说明核心信息没提炼出来，或者该拆成两条 Bug。
标题里要不要写优先级或严重程度？ 不要。优先级属于独立字段，会随排期变化；写进标题后一旦调整，标题就成了错误信息，还会干扰检索。
不知道原因，标题能写猜测吗？ 可以标注「疑似 XX 导致」，但不要把猜测当结论写死。带猜测的标题要在正文里说明依据，否则会误导排查方向。
同一个 Bug 在多个浏览器/设备上出现，要拆成多条吗？ 标题写核心现象，把环境差异放进「环境」或「备注」字段。只有当修复路径完全不同（例如 iOS 与 Android 分别由不同代码路径处理）时才拆分。
英文标题用 Title Case 还是 Sentence Case？ 两种都能用，但要与团队缺陷系统里的存量工单保持一致。若没有历史包袱，推荐 Sentence Case，可读性更好。
标题还是要人来写，其余字段可以自动完成
说清楚一点：BugCapturer 不会替你写标题——标题需要你对现象的判断。但一份 Bug 报告里最枯燥、最容易写漏的部分，它可以自动补齐：
- 自动技术信息：URL、浏览器、操作系统、屏幕分辨率、视口尺寸自动写入，标题里的条件字段不用再手抄。
- 诊断数据：自动收集错误级控制台日志与失败的网络请求（HTTP ≥ 400），敏感参数（token、密码、API Key）自动脱敏。
- 标注截图：拖拽选区即可在页面上画箭头、方框、文字，把"错在哪"固定在图上。
- 录屏：直接录制当前标签页并裁剪片段，提交给开发的就是一段可验证的 12 秒视频。
- 一键分享或同步：生成分享链接给外部协作方（免注册即可查看），或把报告送进飞书多维表格 / 通用 Webhook。
这样一来，你只需要专心写好标题那一行，剩下的字段交给工具填。
可下载清单
复制这份清单贴在显示器边，写完标题自查：
- 是否点明了组件或页面？
- 是否用了可观察的事实，而不是「不好用」？
- 是否包含了条件（浏览器 / 设备 / 账号 / 网络 / 屏幕宽度）？
- 是否带了可验证的数字（状态码、单号、金额、耗时、阈值）？
- 是否只描述一个现象？
- 是否去掉了优先级和未经验证的猜测？
- 是否控制在 60 字符 / 40 汉字以内？
7 条全过，你的标题就比 90% 的缺陷工单更容易被优先处理。
延伸阅读：Bug 报告模板（完整字段与可直接复制的模板）· 如何高效报告 Bug · 测试用例模板与示例 · Bug 报告格式 · 复现步骤怎么写