前端按钮点了没反应？用一套「行为取证」流程定位真正的接口

一、问题的形状

「按钮点了没反应」是前端排障里最常见、也最容易被误判为「用户点错了」的一类现象。它至少有四种完全不同的成因：

1. JS 报错中断：处理函数第一行就抛异常，后续逻辑全不执行。
2. 弹窗被拦：window.open 返回 null，接着对 null 取属性直接抛 TypeError。
3. 请求发了但被静默吞掉：前端拿到 4xx/5xx 后没有 catch 提示。
4. 请求压根没发：前置条件不满足（缺参数、缺 token、缺名额），代码提前 return。

这四种情况在界面上长得一模一样，所以不能靠「再点一次」来区分，必须取证。

二、四步取证法

第 1 步：录包，确认「有没有请求发出去」

先 hook 住 fetch 和 XMLHttpRequest，再点按钮。这一步的产出是「点了之后到底有没有网络动作」，它直接把问题劈成两半：

window.__cap = [];
const of = window.fetch;
window.fetch = function (u, o) {
  const url = typeof u === "string" ? u : u && u.url;
  const p = of.apply(this, arguments);
  p.then(r => r.clone().text().then(t => window.__cap.push({ url, status: r.status, body: t.slice(0, 800) })));
  return p;
};

如果 __cap 是空的，说明请求根本没发，属于第 4 类；如果有请求但 4xx/5xx，属于第 3 类。两种走的路完全不同。

第 2 步：抓异常，确认「是不是抛错了」

在控制台看有没有 TypeError。有一类特别典型：

const t = window.open(url, "_blank");
t.opener = null;   // 弹窗被拦时 t 是 null，这里直接炸

这种代码在正常浏览器里没有症状，一旦运行环境禁止弹窗，整个跳转链路就断了。判断依据不要用 offsetParent !== null 去看弹层有没有出现——position: fixed 的元素 offsetParent 恒为 null，会把「已经弹了」误判成「没弹」。正确写法是：

getComputedStyle(n).position === "fixed" && getComputedStyle(n).display !== "none"

第 3 步：读源码，把「终态 URL / 请求体」拼出来

现代前端都是打包产物，但函数名和路由字符串往往没被混淆。在 CDN 上的 JS 里搜关键动作（比如 enterTestPage、submit-post），经常能直接读到：

enterTestPage(t, e) {
  const { resource_type } = this.testDetail;
  gV(`${s}/${resource_type === "console" ? "consoleExperiment_" : "experimentalStudy_"}` +
     `${e}_${t}_0_${Date.now()}`, 1e4);
}

这段代码等于把「正确的 URL 长什么样」直接告诉你了。用它反推出来的地址，比在页面上猜要可靠一个数量级。

第 4 步：用最小代价验证一次

拼出参数后，先在控制台里单独发一次请求（或用 location.href 直接跳），确认接口认不认。不要一上来就改业务代码。

三、三个真实案例

案例 A：弹窗被拦导致整条链路断掉

某积分站的任务卡「去完成」点击无任何反应。录包显示没有请求发出，控制台有 TypeError: Cannot set properties of null (setting "opener")。源码里就是上面那段 window.open(...).opener = null。解法：hook window.open 把 URL 录下来，再用地址栏直接访问。这类场景下「直接打开目标 URL」永远是可用兜底。

案例 B：URL 参数不全导致的假失败

某云实验页跳转时少拼了一段 topology，页面稳定显示「环境启动失败，请联系管理员或稍后重试」。这看起来像服务端故障，实际上参数补齐后立刻正常。教训：「稍后重试」类提示不一定是服务端的问题，先核对 URL 结构是否和源码一致。

案例 C：状态只能靠真实操作产生

最耗时的坑：某些「完成状态」（实验进度、审核结果）只能由真实行为驱动，没有可调用的写接口。判断方法——把所有疑似接口挨个以最小请求体打一遍，如果全部返回 200 但状态字段一律不变，或者关键接口恒定 500，就应当立刻停止枚举，承认「这条路不存在」，转去真操作或等结算。

这条经验值得单独强调：接口探测超过两三次没有正向反馈，就应该切换策略，否则最容易发生的事就是在一个不存在的入口上耗掉整个下午。

四、把流程固化成清单

• 点之前先 hook 网络，点之后看请求有无；
• 有异常先读栈，特别注意 null 取属性；
• 判断弹层用 position/display，不用 offsetParent；
• 读打包源码抠路由与参数模板，别靠猜；
• 接口探测两次无正向反馈即转向，不做无效枚举；
• 所有「去完成」类按钮，准备好「直接访问 URL」的兜底方案。

这套流程的价值不在于某个具体项目的技巧，而在于把「点了没反应」这种模糊抱怨，变成四步可执行、可复现的取证动作。