css变量在android 4.4以下webview中完全不被解析，整条--x声明和var(--x)被静默跳过，无报错，样式回退至initial或继承值；须用setproperty检测并前置fallback，@supports在此版本前不可用。
CSS变量在Android 4.4以下WebView中根本不会被解析，不是“失效”，而是整条--x声明和var(--x)调用被浏览器静默跳过——连DevTools里都看不到报错，样式直接回退到initial或继承值。
运行时检测比UA判断更可靠
安卓系统版本 ≠ WebView内核版本，很多定制ROM或厂商预装浏览器（如UC、QQ、旧版微信）会替换WebView，导致navigator.userAgent里的Android 4.4实际跑着Chromium 25内核。硬匹配字符串极易误判。
- 用
document.documentElement.style.setProperty('--test', 'ok') !== undefined检测：返回false说明变量不可写，应立刻启用降级逻辑 - 检测后给
加no-cssvars类，用CSS选择器批量切换fallback样式，避免JS反复操作DOM - 不要在
DOMContentLoaded之后才检测——某些低端机WebView初始化慢，需在内尽早执行
@supports(--x:red)在Android 6.0前完全不可用
Android 4.4–6.0的WebKit内核既不支持CSS变量，也不识别@supports规则本身。整个@supports块会被当作无效CSS忽略，里面定义的var(--x)和fallback都会丢失。
- 必须写无条件fallback前置：例如
color: #333;必须出现在@supports块之前，且不能依赖!important覆盖 -
@supports (color: var(--x))是非法语法，浏览器会直接丢弃整条规则；正确写法只能是@supports (--x: red) - 变量名含单位时，fallback值单位必须一致：
margin: var(--gap); margin: 12px;✅，margin: 12;❌
PostCSS降级失败的三个隐蔽原因
即使配置了postcss-custom-properties，构建后CSS里仍有var(--x)残留，大概率不是插件没运行，而是它“看不见”可替换的上下文。
- 变量必须静态可求值：不能含
calc()，不能引用未展开的另一变量（如--c: var(--a)），不能是JS动态注入的值 - 作用域必须显式覆盖：若
--bg定义在.theme-dark { --bg: #111; }里，而你在.btn里写background: var(--bg)，插件不会跨选择器推导，结果就是未替换 - 插件顺序错误：如果
postcss-custom-properties在autoprefixer之后运行，某些带前缀的规则（如-webkit-box-flex）可能已变形，导致变量匹配失败
link加载CSS变量文件时的路径陷阱
在uni-app或原生Android WebView中，<link href="css/vars.css">这种相对路径在H5模式下正常，但在App端会变成file:///android_asset/css/vars.css，若路径未适配，文件404，变量自然为空。
- 检查方式：真机打开页面，进DevTools → Elements → 点
，看Styles面板是否出现--primary-color声明；若没看到，先查Network面板确认vars.css是否加载成功 - uni-app中建议用绝对路径+条件编译：
<link href="/static/css/vars.css" v-if="process.env.UNI_PLATFORM === 'h5'">，App端改用JS动态注入或内联样式 - 若变量文件通过
<link>加载，必须显式指定base URL，否则@import中的相对路径在低版本WebView中可能解析失败
最容易被忽略的是：变量降级不是“有备选就行”，而是要确保fallback声明在CSS层真正生效——老系统跳过@supports时，它必须是第一条有效规则；PostCSS生成的fallback必须在源码中物理位置靠前；JS检测必须在样式表解析完成前执行。三者缺一，降级就形同虚设。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
