前端 Bug 排查实战：从现象定位到测试闭环的标准化流程

4. 验证机制与测试用例

这一步是保证质量的关键。你需要给出缺陷复现路径、边界条件覆盖、测试策略（代码或手动），以及回归测试表格。

缺陷复现路径

• 在 iOS 微信中打开页面，点击输入框，键盘弹出。
• 输入任意字符，点击键盘的'完成'按钮。
• 观察底部按钮是否消失。

边界条件覆盖

• 键盘弹出前快速滚动页面，键盘收起后按钮位置是否正确。
• 连续多次唤起/收起键盘，按钮是否始终可见。
• 在非 iOS 设备（Android、PC）上，该修复不应引入副作用。

测试策略与伪代码

// 使用 Vitest + Vue Test Utils 模拟视口变化
import { mount } from '@vue/test-utils';
import FixedButton from './FixedButton.vue';

test('视口变化后按钮应保持可见', async () => {
  const wrapper = mount(FixedButton);
  const btn = wrapper.find('.fixed-button');
  // 模拟 resize 事件
  window.dispatchEvent(new Event('resize'));
  await wrapper.vm.$nextTick();
  expect(btn.isVisible()).toBe(true);
});

回归测试表格

实战案例：重复提交请求的深层解决

再来一个更常见的场景：用户在商品详情页快速点击'加入购物车'两次，虽然按钮加了 loading 状态，但偶尔还是会发送两次请求。我们该如何分析？

现象确认

• 快速双击'加入购物车'按钮，后端收到两次相同请求，数据库重复记录。

根因分析

• 按钮的 loading 状态是通过响应式变量（如 isLoading）控制的，但第一次点击将 isLoading 设为 true 后，UI 更新是异步的（Vue 的 nextTick）。在微任务队列执行前，用户第二次点击可能已经被浏览器的事件循环处理，导致 isLoading 仍为 false，从而第二次请求被放行。
• 根本原因是前端防抖/节流未结合请求锁，且 loading 状态的设置未能及时阻止后续点击。

解决方案

• 采用'请求锁'模式：请求开始时锁定，结束时释放，并且在请求结束前任何点击都不再触发新的请求。
• 推荐使用 useRequest 组合式函数封装，内部维护一个 pending 状态，返回一个 run 方法，确保并发安全。

// hooks/useRequest.ts
import { ref } from 'vue';

export function useRequest<T>(fn: () => Promise<T>) {
  const pending = ref(false);
  const error = ref<Error | null>(null);
  const data = ref<T | null>(null);

  async function run() {
    if (pending.value) return; // 请求锁
    pending.value = true;
    error.value = null;
    try {
      const result = await fn();
      data.value = result;
      return result;
    } catch (e) {
      error.value = e as Error;
      throw e;
    } finally {
      pending.value = false;
    }
  }

  return { run, pending, data, error };
}

组件中使用：

<script setup>
const { run: addToCart, pending } = useRequest(() => api.addToCart(productId.value));

function handleClick() {
  addToCart().catch(err => console.error(err));
}
</script>

验证机制

• 复现路径：在 API 响应延迟 500ms 的情况下，快速点击按钮两次。
• 边界条件：网络超时、请求失败后锁是否正确释放；在 pending 期间再次点击应无效。
• 测试代码：用 vi.spyOn 模拟 API，验证多次点击只调用一次。
• 回归表格：覆盖正常提交、快速双击、请求失败重试、组件卸载时取消请求等场景。

如何将这套 SOP 融入日常工作

1. 培养'提问思维'：拿到 Bug 时，先问自己三个问题：用户做了什么？预期是什么？实际发生了什么？然后尝试用浏览器开发者工具模拟或复现。
2. 建立自己的知识库：将每次排查的根因记录在案，形成'常见问题模式'。例如：iOS fixed 问题、WebKit 滚动穿透、Vue 响应式陷阱、Pinia 状态共享冲突等。
3. 代码评审时引入防御性思维：在审查他人代码时，尝试用这套 SOP 的标准去评估：这个改动是否覆盖了边界情况？是否附带了测试？是否有潜在的竞态？
4. 与 QA 共建测试闭环：将修复后的测试用例交给 QA，并要求在回归测试中执行。这能显著降低 Bug 重复率。

结语：从'修 Bug'到'消灭 Bug 家族'

前端开发的世界里，Bug 永远不会消失，但我们可以选择用科学的方法去应对。这套方法不仅是一份 SOP，更是一种思维方式——它要求我们透过现象看本质，从框架原理和浏览器机制出发，给出稳健的解决方案，并让质量保障成为闭环的一部分。

希望这篇文章能给你带来启发，让你在下次面对诡异 Bug 时，不再迷茫，而是自信地走完'现象 → 根因 → 修复 → 测试'的全流程。