把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 浏览器缩放缩小 CSS viewport，固定宽度侧栏与绝对定位按钮容易重叠。WCAG reflow 要求 400% 等效窄宽通常无需双向滚动。
无障碍不是发布前补一组 aria 属性，而是让键盘、屏幕阅读器、缩放、减弱动态和高对比度用户完成同一任务闭环，并在错误后找得到下一步。
落地方案的关键部件
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 主布局 minmax(0,1fr)，卡片允许内容换行，工具栏使用 flex-wrap；长设备名和英文不以缩小字体解决，焦点元素可滚入视图。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 上线参数必须有保守默认值、服务端上限和灰度开关，不能把浏览器传来的数字直接当作资源预算。
“200% 浏览器缩放：功能不该被挤出视口或要求横向滚动”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
别让错误假设进入生产
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 全局 overflow-x:hidden 会掩盖被裁按钮而非修布局；固定底栏在移动键盘和缩放下可能覆盖最后一项操作。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
发布闸门应该检查什么
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 在 100/200/400% 与 320 CSS px 下完成所有主要任务，自动检测横向溢出、不可见焦点和被固定层遮挡元素。
- 连续执行一百次开始、失败、重试和取消，检查句柄、监听器、队列及临时数据回到基线。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
最终交付标准应当是：正常路径足够快，异常路径能够收敛，用户意图不会被自动恢复覆盖，运维人员也能从有限而安全的证据定位问题。