跨端兼容先做特性检测再准备回退浏览器升级后出现的布局问题常常不是“某个内核不支持”这么简单属性支持了组合用法也可能不同。处理兼容性时先从受影响的页面和浏览器版本开始复现再决定是否需要回退。不要用 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 和系统浏览器。兼容性的目标是稳定完成任务不是无限期保留每一种视觉细节。对于无法修复的已知限制页面可以给出清楚、不过度打扰的提示并提供仍可完成任务的替代操作避免用户面对无响应的界面。