FORMA

系统下单（重复单提示框）异常复盘

问题现象

下单流程中，重复单提示弹窗会出现「闪烁后消失」或「未正常展示」的情况。虽然页面无明显报错，但属于典型的功能异常：用户几乎无法感知到系统本应给出的风险提示。

由于现象没有明确的报错堆栈，前端首次接手时容易误判为「样式问题」或「组件本身渐隐动画」，实际复盘后发现根因与展示动画完全无关，这也是本文单独记录复盘过程的原因之一——类似「看起来像 UI 小问题」的现象，背后可能是逻辑层面的竞态缺陷。

场景与影响

该问题发生在类似电商下单页面：用户填写基础信息、计算费用后提交下单，系统应在检测到「短时间内重复下单」（参见 同业主重复单提醒规则）时给出提醒弹窗。此类风控提示与普通表单校验不同——它不是阻断式的强制拦截，而是需要在给用户「继续操作空间」的同时，确保提示本身足够稳定地展示出来，一旦提示本身不可靠，风控规则设计得再完善也失去了实际意义。

异常影响主要包括：

  • 误触下单风险上升：尤其是自动扣款场景下，用户没有看到提醒即可能重复扣款，属于本次问题中优先级最高的风险点；
  • 客服成本增加：客服需要额外处理撤单、退款、解释等售后工作；
  • 信任度下降：用户对系统稳定性与风控能力产生疑问，间接影响产品口碑；
  • 数据统计失真：若依赖前端弹窗展示次数来统计规则命中率，弹窗异常消失会导致统计数据比实际命中次数偏低，影响后续对规则效果的评估。

排查时间线

  1. 客服反馈「用户投诉重复下单被扣款两次，但没有看到任何提示」；
  2. 前端复现时发现，部分网络环境下提示框确实闪现了一下又消失，怀疑是弹层被主动关闭；
  3. 通过日志与代码排查，定位到关闭弹层的调用链路，确认是 dialog.closeAll() 在特定时序下被触发；
  4. 复现条件锁定为「并发或连续请求」场景，与加载态弹层的关闭时机重叠；
  5. 与后端确认接口本身返回内容正常（重复单判定结果确实已返回），排除掉「后端未触发判定」这一可能性，进一步锁定问题在前端弹层展示环节。

问题分析

如果图片显示较小，可点击放大查看。

下单提示异常

根因是弹层关闭逻辑过于粗粒度：

  • 在并发请求或连续请求场景下，执行了 dialog.closeAll()；
  • 当未传入目标参数时，closeAll() 会关闭所有弹层，而不区分「加载态弹层」与「业务提示弹层」；
  • 请求返回时机与重复单提示弹窗的展示时机存在竞态：加载层关闭动作发生在业务弹窗刚展示之后，导致业务弹窗被一并误关闭；
  • 表现为「弹窗一闪而过」或「完全没有出现」，取决于两者时序的先后关系。

修复前后对比

维度修复前修复后
关闭方式无参 dialog.closeAll()，无差别关闭所有弹层加载层维护独立 id，仅 closeAll(id) 关闭对应加载层
业务提示弹窗可能被并发请求的加载层关闭动作误关闭与加载层关闭逻辑解耦，不受影响
复现概率与请求时序强相关，弱网/连续点击下概率更高消除时序竞争，稳定展示
排查难度无明显报错，只能靠现象复现和日志定位加载层与业务弹层分别打标记，日后类似问题更易定位

修复方案与结果

修复思路是「只关闭加载层，不影响业务弹窗」：

  1. 为加载层维护独立且递增的 id；
  2. 请求完成后使用 closeAll(id) 或指定关闭 API，仅销毁对应加载层；
  3. 避免无参 closeAll() 清空全部弹层；
  4. 对「业务风险提示类弹窗」（如重复单提醒）单独打上标记，即便未来仍有类似批量关闭调用，也不会被无差别清除。

修复后效果：

  • 重复单提示弹窗可稳定展示；
  • 加载层关闭不再影响业务弹窗；
  • 下单流程风险提示恢复正常。

由于代码涉及公司内部业务，本文不展示源码，仅保留效果示意图：

最终效果

回归检查清单

  • 单次请求场景下，重复单提示弹窗正常展示且不闪烁；
  • 并发/连续请求场景下（如快速多次点击下单），提示弹窗不会被加载层关闭动作误关闭；
  • 页面内其他使用 dialog/loading 的模块，确认未因本次修复而出现「加载层无法正常关闭」的回归问题；
  • 覆盖所有会触发重复单检测的入口（见 同业主重复单提醒规则 中的场景表），逐一验证提示弹窗展示正常；
  • 弱网/延迟环境下手动多次提交，确认提示弹窗展示时序稳定。

经验总结

  • 使用「无差别批量关闭」类 API（如 closeAll()）时，务必确认是否会影响到其他业务无关的弹层；优先使用带 id/引用的定向关闭方式；
  • 涉及风控/安全提示类弹窗，建议在设计上与普通加载态弹层做隔离，避免被通用清理逻辑误伤；
  • 类似的「异常无报错、但功能表现不正常」问题，排查时应重点关注竞态时序，而非仅看单次请求的日志。

类似风险点排查建议

本次问题的本质是「批量操作 API 的作用范围被想当然地扩大」，团队后续排查类似隐患时，可参考以下检查方向：

检查方向具体做法
全局搜索批量 API 调用搜索项目内 closeAll()、clearAll()、removeAll() 等无参批量调用，逐一确认调用场景是否会影响非预期目标
弹层/浮层分级按「加载态」「普通提示」「风控/安全提示」三级管理弹层，不同级别使用不同关闭策略
并发场景补充测试对涉及多个异步请求的页面，专门补充「快速连续操作」「多个请求几乎同时返回」的测试用例
组件库封装规范若二次封装了弹层组件，建议默认不提供无参「关闭所有」方法，或在文档中明确注明该方法的影响范围
Code Review 关注点涉及弹层关闭的改动，Review 时应额外确认是否可能影响其他并发场景下的弹层展示

常见疑问

  1. 为什么浏览器多次测试没有复现，只有部分用户反馈？
    竞态问题往往依赖请求返回的时序，本地测试环境网络延迟低、请求几乎同步返回，容易掩盖问题；线上用户网络环境更复杂，多个请求的返回时间差更容易触发竞态窗口，因此更常见于生产环境反馈。
  2. 除了本次涉及的重复单提示，是否还有其他弹窗存在类似风险？
    建议按上文「类似风险点排查建议」表格对全站弹层调用做一次专项排查，而不是仅修复本次报告的具体场景。
  3. 加载层的 id 应该如何生成？
    建议使用自增计数器或时间戳 + 随机数组合，保证同一页面内并发请求产生的加载层 id 不重复，避免 closeAll(id) 误关闭到另一个并发请求对应的加载层。
  4. 本次修复是否需要补充自动化测试？
    建议补充：对下单接口 mock 出「并发触发加载态 + 重复单提示」的场景，断言提示弹窗最终仍处于展示状态；纯手工回归容易在下次迭代中被无意间引入的新调用重新破坏。

相关链接

相关文章

Series

team documents

11 / 22

图片上传前的自定义水印实践系统自动更新说明