viewport元标签缺失或错误是响应式失效的首要原因；必须写为<meta name="viewport" content="width=device-width, initial-scale=1.0">；优先使用min-width配合移动优先策略；断点应基于内容临界点而非设备尺寸；推荐单文件内联写法，避免@media内嵌套伪类。
viewport 元标签没加或写错，@media 规则就根本不会生效——这是所有响应式失效的第一原因。
为什么 viewport 是媒体查询的前提
浏览器默认以桌面视口（约980px）渲染移动端HTML，即使你写了 @media (max-width: 768px)，设备实际报告的视口宽度仍是980px，导致媒体查询永远不匹配。
必须在 <head> 中声明：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
常见错误包括：
-
width=1200或width=320—— 硬编码宽度会锁死缩放，断点失效 - 漏掉
initial-scale=1.0—— iOS Safari 可能自动缩放，导致视口宽度计算偏差 - 写成
<meta name="viewport" content="user-scalable=no">—— 不仅禁用缩放，还可能让部分安卓浏览器忽略整个标签
@media 断点该用 min-width 还是 max-width
优先用 min-width，配合移动优先写法。基础样式写在媒体查询外，只针对更大屏幕做增强，逻辑更清晰、维护成本更低。
立即学习“前端免费学习笔记（深入）”；
例如：
.card { padding: 12px; font-size: 14px; }
@media (min-width: 768px) {
.card { padding: 16px; font-size: 16px; }
}
@media (min-width: 1024px) {
.card { padding: 20px; font-size: 18px; }
}
避免混用 min-width 和 max-width 在同一项目中，否则容易出现样式覆盖冲突，比如：
-
@media (max-width: 767px)和@media (min-width: 768px)之间存在 1px 缝隙（某些设备 DPR=2 时可能触发渲染抖动） - 多个
max-width嵌套时，调试时难以判断当前生效的是哪一层
断点值不是设备尺寸，而是内容临界点
别直接套用 “iPhone 14 是 390px” 这类数据。真实断点应由内容决定：文字开始换行、图片被裁切、导航栏挤成两行的那一刻的视口宽度。
实操建议：
- 打开 Chrome DevTools，勾选 “Toggle device toolbar”，拖动宽度滑块，观察布局断裂点
- 记录下文字溢出或元素重叠前的精确像素值，比如
482px、769px，而不是四舍五入成480px或768px - 如果用 WorkBuddy，可直接运行“响应式分析”，它会扫描 DOM 流动性并推荐语义化断点值
媒体查询写在哪？内联、单文件还是分离CSS？
现代项目基本统一用单文件内联写法，原因很实际：
- HTTP/2 下多请求优势消失，拆成多个CSS文件反而增加解析开销
- 构建工具（如 Vite、Webpack）已支持 CSS scope 提取和 tree-shaking，无需手动分离
- 媒体查询需与对应组件样式紧耦合，分离后定位修改成本高
唯一例外是 legacy IE 支持需求：IE9–10 不支持 @media 内联写法，此时才需用 <link media="..."> 引入独立文件，但 2026 年基本可忽略。
真正容易被忽略的是：媒体查询块内部不要嵌套伪类或动画关键帧——CSS 层叠规则在此处容易失控，:hover 在 @media 里写两次比写一次更难 debug。
