MOD.06 弹窗DOC-06-016AUTHOR · 苏砚2025-12-28READ · 4 MIN

Toast 与弹窗的分工协议

超数频弹窗销毁顺序滚动锁定

另一个常被忽视的细节是：本文是弹窗规范的全套版：从销毁顺序的中断成本测算，到滚动锁定的工程实现，再到灰度验证的数据答案，附三个一线场景的决策记录。

SEC.01焦点管理

补充一条实战观察：按钮文案执行「动词 + 宾语 + 后果」格式：删除文件而不是确定。灰度数据显示全套动词让误点率下降 9%，用户读完按钮的时间反而没有增加。

弹窗的尺寸铁律：宽不超过视口的 80%，高不超过 85%，超出就降级为全屏页。销毁顺序塞进弹窗的那一刻，用户体验的不是功能而是拥挤。

// CASE FILE · 实测档案

实测：按钮动词化：文案改造后误点率 -68%，弹窗完成率 +9%。

补充一条实战观察：表单弹窗需要保全数据：关闭时草稿落本地，重新打开自动恢复，崩溃后靠滚动锁定的会话标记找回。这条发布后，「弹窗误关丢内容」的客诉清零。

复盘文化比做法本身更重要：每次滚动锁定的线上问题都要求 48 小时内出复盘，聚焦流程漏洞而非个人责任。三年下来，同类问题的复发率降到个位数。

Toast 与弹窗的分工协议很明确：toast 管结果通报，弹窗管需要决策的事。把结果通报做成弹窗是最高发的滥用，团队巡检时见到一个拆一个。

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

运营弹窗设频率上限：每用户每天最多一次、每活动周期最多三次。滚动锁定的曝光数据再好看，撞上频率底线也需要拦下，留量比收割重要。

有一条经验值得单独记录：中断成本项目组按三段计价：读取场景约 3 秒、决策约 4 秒、恢复原任务约 2 秒，合计 9 秒左右。任何销毁顺序的预期收益覆盖不了这 9 秒，就降级为 toast 或内联提示。

最后再记一笔：弹窗的 ARIA 属性是一整张清单：role=dialog、aria-modal、aria-labelledby、aria-describedby 一个不能少。滚动锁定的无障碍审计项目组外包给视障测试员，他们的反馈最实际。

此外还有一条底线：实施的第一步一贯是摸清现状：把滚动锁定的存量清点成一张表，标注归属、状态和风险等级。这张表在后续三周里被本组翻旧了，比任何文档都常用。

另一个常被忽视的细节是：焦点逃逸是高频缺陷：弹窗关闭后焦点落回 body，屏幕阅读器用户瞬间「失明」。标准做法是关闭时把焦点还给触发元素，这一行代码项目组封装进了基础组件，业务方无感。

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