从按钮点不动到成功提交：一次 GitCode 前端交互问题的排查与绕行实践

一、问题现象

在 GitCode 仓库页面点击 Star 按钮，按钮没有报错、没有 loading、计数也没有变化；点击「新建 Issue」并填好标题和正文后，点击提交同样没有任何网络请求，页面只是安静地停在原地。

这类"点了没反应"的问题很容易被误判为网络故障，但打开 Network 面板会发现一个关键特征：点击后只有埋点上报请求，没有业务接口调用。

二、定位思路

排查分三步走，每一步都用可观测的证据做判断，而不是靠猜。

第一步：确认点击是否真的被派发。用 elementFromPoint 检查点击坐标上最顶层的元素，如果它不是目标按钮，说明有遮罩或浮层拦截。

第二步：确认事件是否被绑定。监听 click 捕获阶段，看事件是否冒泡到了处理的容器；如果只有埋点，说明业务处理函数没有执行。

第三步：确认接口契约。在 Network 中记录真实请求的 URL、方法、请求体与鉴权头，这一步决定后续能否绕行。

三、根因

最终定位到两类原因：一类是页面加载遮罩残留，使真实点击命中遮罩而不是按钮；另一类是编辑器内容只写进了 DOM，没有被框架的表单状态接管，提交前的必填校验因此始终不通过，界面看起来"点得动但不生效"。

四、绕行方案

确认接口契约之后，可以直接调用同一接口完成操作，前提是带上当前会话的凭证。以 Star 为例：

POST https://web-api.gitcode.com/api/v2/projects/{project_id}/star?project_id={project_id}

调用前先读取一次项目信息里的 star_count，调用后再读一次做对比，就能确认是否真正生效，而不是只看界面文案。

五、几点经验

第一，界面状态不等于服务端状态。很多页面会用本地状态渲染"已完成"，但服务端记录可能还没同步，判断结果要以接口数据为准。

第二，埋点请求不能当作成功信号。埋点只说明用户点了，不代表业务逻辑跑通了。

第三，绕行前先确认契约。手工构造请求容易漏掉鉴权头或 CSRF token，先用页面自身的真实请求做模板最稳妥。

六、小结

前端"点不动"的问题，本质是事件链路或状态同步断了一环。把它拆成"点击是否命中、事件是否绑定、接口是否发出"三个可验证的问题，排查就不再依赖运气。