color在媒体查询中不生效的根本原因是被更高权重样式覆盖，而font-size未被覆盖故“看似有效”；常见原因包括内联样式、!important声明或更具体选择器优先级更高。
为什么 color 在媒体查询里不生效，但 font-size 可以
根本原因不是媒体查询失效，而是 color 被更高权重的样式覆盖了。CSS 层叠机制会让内联样式、!important 声明或更具体的选择器胜出，而 font-size 恰好没被覆盖，所以“看起来”只有它动了。
常见触发场景：
- HTML 元素带
style="color: #333"内联样式 - 全局重置 CSS（如 Normalize.css）里用了
!important锁定color - 媒体查询外写了
.headerContainer a { color: blue !important; }，而媒体查询里只写a { color: red; }
验证方法：打开 DevTools → 选中目标元素 → 看 Styles 面板里 color 旁有没有被划掉的线；如果被划掉，说明有更高优先级规则在起作用。
!important 不是修复手段，而是掩盖问题的临时探针
加 !important 让 color 生效，只能帮你确认“媒体查询本身在运行”，但会把真实问题藏得更深。一旦多个 !important 并存，后续维护成本陡增，且容易在 Safari 或旧版 Chrome 中因解析顺序差异导致行为不一致。
更可靠的解法是提升选择器特异性：
- 把
.slash { color: red; }改成.headerContainer .slash { color: red; } - 避免用通配符
*或低权重组合（如div p span），改用语义化类名组合 - 检查是否在媒体查询外部定义了同名类（比如
.slash在默认样式里已带!important）
选择器写错：.body 和 body 是两回事
这是最常被忽略的硬性错误。浏览器不会报错，但 .body 永远匹配不到 标签——它只找 class="body" 的元素。
典型错误模式：
-
@media (max-width: 768px) { .body { background: #eee; } }→ 实际应为body -
.header .nav ul li a写成.header.nav ul li a（漏了空格，变成匹配同时含两个 class 的元素） - 大小写混淆：
.Header匹配不到class="header"（HTML class 名不区分大小写，但 CSS 选择器区分）
建议：在媒体查询内部，先用 DevTools 的 “Force element state” 功能临时激活断点，再手动输入选择器测试是否命中目标节点。
真正要盯住的三个地方：视口、语法、解析中断
媒体查询失效往往不是孤立事件。除了选择器和权重，还有三个隐蔽但高频的根因：
-
<meta name="viewport">缺失或不完整 —— 尤其在 iOS Safari 上，缺少maximum-scale=1会导致缩放干扰断点计算 - 媒体查询语法漏了
and，比如写成@media screen (max-width: 768px)→ 必须是@media screen and (max-width: 768px) - CSS 文件顶部存在未闭合的
@keyframes或@supports块，会让解析器跳过后续所有规则，包括整个@media块
这些错误都不会抛异常，浏览器静默吞掉后续样式。调试时别只盯着媒体查询那一段，从文件开头逐行扫语法，比反复改断点值更有效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
