根本原因是安卓 WebView 未正确解析视口基准，导致 media 查询失效；需确保 viewport 标签唯一、位于 head 顶部、内容准确，并验证真机 clientWidth 是否符合逻辑宽度。
根本原因不是媒体查询写错了，而是安卓 WebView 没正确解析视口基准——viewport 标签失效、重复或位置错误，导致所有 @media 规则失去运行前提。
检查 viewport 标签是否真正生效
真机上 document.documentElement.clientWidth 返回 980 或远大于设备逻辑宽度（如 390/414），基本可断定 viewport 没起作用。这不是“写了就行”的标签，它必须同时满足：
-
<meta name="viewport" content="width=device-width, initial-scale=1.0">必须写在<head>最顶部，且严格位于所有<style>和<link rel="stylesheet">之前 - 不能写成
width=320或width=1200—— 固定值会锁死视口，让max-width断点永远不触发 - 避免
user-scalable=no：部分旧版 X5/UC 内核会因此降级为桌面渲染模式，先去掉它测试 - Next.js、UniApp 等框架可能自动生成一条
viewport，若你又手动加了一条，后加载的会覆盖前一个；务必查看最终 HTML 源码，确认只有一条且内容准确
验证 @media 语法是否被低版本 WebView 支持
Android 4.4–6.0 的系统 WebView（Chromium 30–46）对媒体查询支持极弱，常见失效点：
- 不支持
dppx单位，@media (-webkit-min-device-pixel-ratio: 2)可能静默失败，优先用@supports (background: image-set())检测高清屏 - 不支持
@media (width > 768px)这类比较运算符写法，必须用标准min-width/max-width -
@media (hover: hover)在旧 WebView 中返回hover: none或直接忽略，改用@supports (pointer: fine) - 嵌套写法（如
.box { @media (max-width: 768px) { ... } }）纯 CSS 不支持，Sass/Less 编译后才有效；未编译就直接扔进.css文件，安卓 WebView 会整条忽略
排查 CSS 变量与媒体查询耦合导致的失效
如果你在媒体查询里用了 var(--color)，而目标安卓 WebView 是 Android 4.4 以下（比如某些定制 ROM 或旧微信内置浏览器），那变量本身就被静默跳过——连 @supports (--x: red) 都不可用，整个规则块会被丢弃。
立即学习“前端免费学习笔记（深入）”；
- 运行时检测比 UA 更可靠：
document.documentElement.style.setProperty('--test', 'ok') === undefined返回true，说明变量不可写，需立即启用 fallback - fallback 必须前置：例如
color: #333; color: var(--text);，不能把var()写在前面，否则低版本直接跳过整行 - PostCSS 插件（如
postcss-custom-properties）可能因变量跨选择器定义、含calc()或 JS 动态注入而漏替换，构建后仍残留var(--x)
别信 DevTools 模拟，真机调试才是唯一验证方式
Chrome DevTools 的响应式模拟器默认补全 viewport 行为，哪怕你 HTML 里压根没写，它也会“假装”有。但真实安卓 WebView（微信、QQ、系统浏览器）严格按 HTML 实际内容执行——漏了就是漏了，不会宽容。
- 用 Chrome 远程调试连接真机，执行
window.innerWidth和document.documentElement.clientWidth，两者应接近设备逻辑宽度（如 Pixel 6 是 412px） - 打开页面源码（
view-source:或远程调试的 Network → HTML），逐行确认viewport是否唯一、位置正确、无空格/换行 - 禁用所有 JS，仅保留 HTML + CSS，复现问题：若此时媒体查询生效，说明是 JS 动态改了
html的font-size或插入了冲突样式
最常被忽略的一点：媒体查询不是独立运行的，它完全依赖视口宽度这个“标尺”。标尺歪了，再准的断点也无效——所以排查永远从 viewport 开始，而不是从 @media 本身。
