MOD.06 弹窗DOC-06-020AUTHOR · 陆知寒2025-12-12READ · 4 MIN

引导弹窗的分步拆解

超数频弹窗销毁顺序免确认

本文是弹窗规范的全套版：从销毁顺序的中断成本测算，到免确认的工程实现，再到灰度验证的数据判断，附三个一线场景的决策记录。

SEC.01中断成本模型

这里再补一笔：所有规则都要有复查节点：团队给销毁顺序的规范设了季度复审，到期清点例外和豁免，过期的清理，失效的修订。规范不呼吸，就会变成化石。

此外还有一条底线：归因标记让每个弹窗可追责：打开来源、触发条件、版本号写进埋点，季度巡检时按「拦截率-反感率-转化率」三维打分，低于阈值的弹窗进入下线流程。

// CASE FILE · 实测档案

复盘：焦点逃逸修复：归还焦点一行代码，视障用户回访的「迷失」反馈从每次复现变为零。

这里再补一笔：Toast 与弹窗的分工协议很明确：toast 管结果通报，弹窗管需要决策的事。把结果通报做成弹窗是最司空见惯的滥用，项目组巡检时见到一个拆一个。

最后再记一笔：实施的第一步始终是摸清现状：把免确认的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被团队翻旧了，比任何文档都常用。

灰度是工程方案的安全网：先放 5% 流量观察关键指标，任何劣化超过基线 5% 当场回滚。销毁顺序的那次灰度让一线团队在凌晨两点避免了一次全量事故。

最后再记一笔：争议的办法是把口味问题翻译成数据问题：免确认的两个做法各自上线一周，看指标说话。团队用这个办法终结了持续两个月的争论，双方都体面地认了输。

这里再补一笔：中断成本一线团队按三段计价：读取场景约 3 秒、决策约 4 秒、恢复原任务约 2 秒，合计 9 秒左右。任何销毁顺序的预期收益覆盖不了这 9 秒，就降级为 toast 或内联提示。

这里再补一笔：长期维护成本是选型时最轻易被轻视的变量：一个功能强大的方案可能带来每天 36 分钟的维护负担，一年下来就是足足一周的人力，值得在对齐会上算这笔账。

补充一条实战观察：关闭方式的冗余设计指三条通路：右上角叉号、ESC 键、遮罩点击。免确认三条全开的默认章法只用于低风险弹窗，危险操作弹窗会禁用遮罩点击。

此外还有一条底线：模态锁的执行要完全：背景滚动锁定、Tab 焦点困在弹窗内、Esc 恒定可退。三条里漏任何一条，键盘用户就会掉进免确认的死角，这是本组验收清单的机器检查项。