@media 查询写在 CSS 底部更安全，因浏览器自上而下解析，底部的响应式规则可确保基础样式优先加载，避免小屏设备先渲染错乱的大屏布局再重绘，减少弱网下的视觉抖动。
为什么 @media 查询写在 CSS 底部反而更安全
因为浏览器解析 CSS 是从上到下顺序执行的，把响应式规则放在底部，能确保基础样式先加载完成，避免小屏幕设备先渲染出错乱的大屏布局再重绘。尤其在移动端弱网环境下，这种顺序能减少视觉抖动。
常见错误是把所有 @media 堆在顶部或分散在各处，导致维护困难、覆盖逻辑混乱。实际项目中建议按「移动优先」组织：基础样式（默认为手机）→ @media (min-width: 768px) → @media (min-width: 1024px)，逐级增强。
- 不要用
@media (max-width: 767px)做手机样式——它依赖断点精度，且容易被更高权重的选择器意外覆盖 - 断点值统一用变量管理（如 Sass 中定义
$breakpoint-tablet: 768px），避免散落的魔法数字 - 慎用
!important强制覆盖媒体查询内样式，它会破坏层叠逻辑，后续调试极难定位
min-width 和 max-width 混用时的实际冲突场景
当同时存在 @media (max-width: 767px) 和 @media (min-width: 768px)，看似无缝衔接，但某些设备（如 iPad Pro 横屏 1024×1366）因缩放、DPR 或 viewport 设置，可能让视口宽度落在“间隙”中（比如 767.5px），导致两个规则都不命中。
更稳妥的做法是只用 min-width 单向递进，并确保基础样式已适配最小屏：
/* 默认：手机 */
.container { width: 100%; padding: 1rem; }
/ 平板及以上 /
@media (min-width: 768px) {
.container { width: 750px; margin: 0 auto; }
}
/ 桌面 /
@media (min-width: 1024px) {
.container { width: 970px; }
}
- 避免用
max-width定义“大屏回退”，它和min-width混用极易产生竞态 - 如果必须支持旧版 IE（@media
- 测试时用 Chrome DevTools 的 device toolbar 切换尺寸，但别只信模拟——真机横竖屏切换、系统字体放大都会触发不同行为
viewport meta 标签没配对，@media 就是摆设
很多开发者写了完整媒体查询，却漏掉 HTML 中这行关键声明：。没有它，移动端浏
@media (max-width: 768px) 永远不会生效。
常见错误配置：
-
content="width=768"—— 固定宽度，失去响应能力 - 漏掉
initial-scale=1—— iOS Safari 可能自动缩放，导致媒体查询基于缩放后宽度计算 - 多个 viewport meta 标签共存 —— 浏览器只读第一个，其余被忽略
正确写法只需一行，放在 内最顶部位置：
用 prefers-reduced-motion 做无障碍适配不是可选项
越来越多用户在系统设置里开启「减少动画」，而 CSS 媒体查询已原生支持检测：@media (prefers-reduced-motion: reduce)。忽略它，意味着你的轮播图、展开动画、loading 微交互可能直接违反 WCAG 2.1 标准。
实操建议不是简单关掉动画，而是降级为平滑过渡或静态状态：
/* 默认有动画 */
.card:hover { transform: translateY(-4px); transition: transform 0.3s ease; }
/ 用户偏好减少动画时 /
@media (prefers-reduced-motion: reduce) {
.card:hover { transform: none; transition: none; }
}
- 该特性在 Chrome 74+、Firefox 63+、Safari 13.1+ 支持良好，无需 polyfill
- 不要只在 hover 上处理，focus、loading、路由切换等涉及运动的场景都要检查
- 测试方法：macOS 系统设置 → 辅助功能 → 显示 → 减少运动；Windows 设置 → 轻松使用 → 显示 → 禁用动画
实际项目中最容易被忽略的，是 viewport meta 标签和 prefers-reduced-motion 这类非视觉但强依赖的配置。它们不报错，也不影响开发预览，直到真机测试或无障碍审核时才暴露。
