webview 渲染 css 与系统浏览器不一致的根本原因是容器未提供完整标准环境，如禁用媒体查询、不透传 prefers-color-scheme、裁剪 ua 样式表、calc() 解析更严格、动画渲染管线被阉割等，需原生层显式配置适配。
WebView 渲染 CSS 和系统浏览器不一致，根本不是“样式写错了”，而是 WebView 容器本身没把标准环境给全——它可能禁用媒体查询、忽略 prefers-color-scheme、不触发 matchMedia 监听、甚至硬编码了 UA 样式表的子集。
WebView 不识别 prefers-color-scheme 的真实原因
这不是 CSS 写法问题，是容器没把系统深色模式信号透传进来。iOS 的 WKWebView 默认不启用自动主题适配，Android 的 WebView 在低版本或未开启 forceDarkMode 时也直接跳过该媒体查询。
- 必须在原生层显式设置：
webView.configuration.defaultWebpagePreferences.preferredContentMode = .recommended（iOS） - Android 需调用
WebSettings.setForceDark(WebSettings.FORCE_DARK_ON)，且仅对 Android 10+ 有效 -
@media (prefers-color-scheme: dark)规则在 WebView 里查不到匹配状态，window.matchMedia('(prefers-color-scheme: dark)')返回matches: false是常态，不是 bug
normalize.css 在 WebView 里失效的常见场景
WebView 的 UA 样式表往往被裁剪或冻结，normalize.css 加载后仍无法覆盖某些元素的默认行为，尤其是 button、input[type="date"]、select 这类系统控件。
-
button的box-sizing在 iOS WebView 中不继承，必须单独写button { box-sizing: border-box; } -
input[type="date"]在 Android WebView（尤其 4.4–7.0）中不支持appearance: none，normalize.css的重置规则被完全忽略 - 部分 WebView（如微信内置）会强制注入自己的 UA 样式，且优先级高于外部 CSS，
normalize.css放再前也没用
WebView 中 calc() 和单位解析更脆弱
系统浏览器至少还有容错机制，WebView 的 CSS 解析器常更严格或更陈旧，calc() 里单位缺失、混合单位、负值等极易直接失效。
-
calc(100% - 20)在多数 WebView 中直接被丢弃，不报错也不渲染，Chrome 浏览器可能悄悄补px，但 WebView 不会 -
font-size: calc(1em + 2px)在 Android 5.1 WebView 中解析为0，Safari WebView 则可能 fallback 到基础字号 - 避免
rem基准依赖html的font-size动态计算——WebView 可能不触发重排，导致响应式字体卡死
动画和 transform 在 WebView 中的隐性降级
WebView 的渲染管线常被阉割，GPU 加速开关不开放、合成层策略不同、关键帧解析更保守，导致动画卡顿、跳变或静止。
- Safari WebView（iOS 15.4 以下）要求
@-webkit-keyframes和-webkit-animation同时存在，缺一不可 -
transform: translateZ(0)在部分 Android WebView 中反而触发软件渲染，改用transform: translate3d(0, 0, 0)更稳 -
will-change: transform在 WebView 中容易引发内存泄漏，且不自动回收，建议动画结束立即设回will-change: auto
WebView 不是“轻量版 Chrome”，它是被封装、被限制、被定制过的渲染沙盒。所有你以为“浏览器都支持”的东西，在 WebView 里都要重新验证——不是看 Can I Use，是看你的 App 打包进的 WebView 版本、系统 API 级别、以及原生层是否开了对应开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
