你遇到的媒体查询没生效问题，90%都源于缺少正确的viewport设置。如果没有添加viewport meta标签，移动端浏览器会以980px的桌面宽度渲染页面，导致你写的@media (max-width: 768px)无法触发。
除了这个经典坑，还有几个高频雷区需要留意：
- 优先级被覆盖——比如
.header .logo这种具体选择器，优先级比媒体查询里的.logo高，除非你在媒体查询里也写同样的选择器链条 - 断点使用了
device-width而不是width——前者是设备物理像素，后者才是CSS视口宽度，响应式布局必须用width - 断点顺序反了——比如先写
@media (max-width: 768px)，再写@media (min-width: 480px)，后者会覆盖前者的部分范围，导致样式逻辑混乱
为什么 @media 媒体查询不生效？
先说最典型的：缺少那行著名的 。没有这行，移动端浏览器会以桌面宽度（通常是980px）渲染页面，@media (max-width: 768px) 永远不触发。
其他高频问题还包括：
@media规则写在了被更具体选择器覆盖的位置——比如.header .logo { font-size: 24px; }的优先级，比@media (max-width: 768px) { .logo { font-size: 16px; } }高，结果就是媒体查询里的样式根本不会生效。- 断点用了
device-width而不是width。前者是设备物理像素宽度，后者才是 CSS 像素构成的视口宽度——响应式必须用width。 - 多个
@media条件重叠且顺序反了，比如先写@media (max-width: 768px)，再写@media (min-width: 480px)，后者会覆盖前者部分范围。
min-width 和 max-width 怎么选？
划重点：推荐统一用 min-width，采用“移动优先”的写法。基础样式默认适配小屏，再用 @media (min-width: 768px) 逐步增强中大屏表现。
这么做的好处很明显：
- 避免重复覆盖——不用在每个断点里都写
display: block这类基础值 - 减少 CSS 体积——小屏设备只下载必要样式
- 逻辑更线性——从窄到宽，逐层叠加，清晰可控
如果非要用 max-width，务必注意断点值要严格递减，例如：@media (max-width: 1199px) → @media (max-width: 767px) → @media (max-width: 479px)，否则中间区间会漏掉。
断点值该设多少？别硬背标准值
所谓 “768px 是平板断点” 只是经验参考，实际应该看真实用户数据。Chrome DevTools 的 Device Mode 或 Analytics 中的屏幕尺寸分布才是靠谱依据。
更稳妥的做法是：
- 先写内容，等布局撑开或挤压明显时，记下此时的宽度——比如导航栏文字开始换行，记下这个
width值 - 用这个值 +1px 作为断点，例如文字在 374px 换行，就设
@media (min-width: 375px) - 避免用太多断点——3–4 个足够覆盖绝大多数场景；每多一个，维护成本和测试负担都翻倍
媒体查询能监听哪些真实有用的特性？
除了 width，这几个在实际项目中真有用：
orientation: landscape：横屏时隐藏侧边栏、放大地图容器prefers-reduced-motion: reduce：对动画做降级，比如把transform: scale(1.1)改成opacity: 0.9prefers-color-scheme: dark：配合系统深色模式切换主题色——注意它不触发重绘，仅 CSS 变量可响应hover媒体特性：@media (hover: hover)可区分触屏与鼠标设备，用来控制下拉菜单触发方式
至于 device-pixel-ratio 和 resolution，建议慎用——它们在不同浏览器行为不一致，且现代高清屏适配更多靠 srcset 和矢量图形解决。
真正容易被忽略的是：媒体查询本身不“响应”，它只是一次性匹配。页面缩放、旋转、动态改字体大小都不会重新触发。需要实时响应的行为——比如根据滚动位置切换导航样式——得用 JavaScript 配合 window.matchMedia() 监听，而不是只靠纯 CSS。
