跨端兼容：先做特性检测，再准备回退

浏览器升级后出现的布局问题，常常不是“某个内核不支持”这么简单：属性支持了，组合用法也可能不同。处理兼容性时，先从受影响的页面和浏览器版本开始复现，再决定是否需要回退。不要用 UA 猜能力。

回退应该保住内容和操作

@supports 适合把高级效果和基础样式分开。基础版先保证内容可读、操作可达；容器查询、动态视口单位或滤镜只是增强项。回退不必复制一整套页面。

.card { display: grid; grid-template-columns: 1fr; }

@supports (container-type: inline-size) {
  .card { container-type: inline-size; }
  @container (min-width: 36rem) { .card { grid-template-columns: 9rem 1fr; } }
}

把兼容性检查放进发布前

挑选真实覆盖的浏览器组合跑核心路由，重点看登录前后状态、软键盘、横竖屏、文本缩放和滚动。构建工具可以处理已知语法转换，但不能替你判断产品行为。遇到问题时记录浏览器版本、最小页面状态和截图，不记录账号、地址等测试数据。

回退样式也要在真实内容下过一遍。短标题通常看不出问题，换成长文案、放大系统字体或出现错误提示后，换行和触控区域才会暴露出来。把这些状态放进发布前的用例，比等到某台设备上出现投诉再补特判更稳妥。

先定义基础体验的底线

兼容方案不是把新特性全部禁用，而是明确哪些能力不能退。用户至少要能读到主要内容、完成关键输入、提交操作并看见结果。比如复杂的毛玻璃背景可以换成纯色，双栏卡片可以变成单列，但登录按钮不能被安全区域或软键盘盖住。先写出这条底线，选择回退时才不会被视觉细节牵着走。

CSS 新特性之外，脚本 API 也需要同样的判断。不要因为某个浏览器支持部分接口，就默认它支持事件选项、观察器行为或输入法组合。对关键交互，优先使用成熟的基础 API；确实需要增强功能时，将检测、启用和失败后的行为放在相邻代码中，避免以后只删掉其中一半。加载 polyfill 也要评估体积和维护成本，少量用户的非关键效果通常不值得为此增加整站负担。

复现记录要能指导修复

报告兼容问题时，写清浏览器版本、操作系统、页面路径和最小步骤，再附上实际与预期的对比。只说“安卓不兼容”范围太大，无法判断是 WebView、字体、视口还是特性实现差异。若问题受网络、缓存或系统设置影响，也要注明条件。截图能说明布局，录屏更适合说明输入、滚动和键盘变化。

修复后不要只在出问题的设备上验证。至少回跑一组基础浏览器，确认回退样式没有覆盖现代环境的正常路径。兼容性代码很容易因为选择器优先级或加载顺序，悄悄影响本来不需要回退的用户。

发布后若收到新环境的问题，先补一条可执行的复现用例，再考虑把它写进长期兼容矩阵。矩阵不必覆盖所有型号，而要反映真实访问占比和业务风险。定期淘汰已无用户的旧版本，也能让团队把测试时间留给仍在变化的 WebView 和系统浏览器。兼容性的目标是稳定完成任务，不是无限期保留每一种视觉细节。

对于无法修复的已知限制，页面可以给出清楚、不过度打扰的提示，并提供仍可完成任务的替代操作，避免用户面对无响应的界面。