必须添加viewport meta标签，否则响应式失效；推荐三档断点（767px、768–1023px、≥1024px）；用rem配合媒体查询调字体，避免JS动态修改；表格、导航、图片需语义化适配，禁用多套HTML结构。
viewport meta 标签没加，其他都白搭
所有响应式行为的前提是浏览器知道该怎么缩放页面。如果 <meta name="viewport"> 缺失或写错，iOS Safari 和 Android Chrome 会以桌面视口（通常 980px）渲染，再缩小显示，导致媒体查询断点完全失效、文字模糊、点击区域错位。
必须在 <head> 中加入且仅用这一种写法：
<meta name="viewport" content="width=device-width, initial-scale=1">
不要加 maximum-scale=1 或 user-scalable=no —— 这些会禁用用户缩放，违反 WCAG 可访问性要求，也常被 iOS 系统拦截导致样式异常。
常见错误：
立即学习“前端免费学习笔记（深入）”；
-
width=320或width=1024：写死宽度，失去响应能力 - 漏掉
initial-scale=1：安卓 WebView 下默认缩放不一致 - 多个 viewport 标签共存：后加载的会覆盖前一个，行为不可预测
@media 查询写在哪儿、怎么断点才靠谱
媒体查询不是“越多越好”，也不是“抄别人断点就行”。关键看内容承载能力，而不是设备型号。
推荐三档主流断点（单位全用 px，避免 em 引入字体缩放干扰）：
-
@media (max-width: 767px)：手机竖屏主力区间（含折叠屏小屏态） -
@media (min-width: 768px) and (max-width: 1023px)：平板 / 小尺寸笔记本横屏 -
@media (min-width: 1024px)：常规桌面，可放心用多栏、固定宽组件
别用 device-width 做条件——它检测的是物理屏幕，不是视口，且在桌面浏览器缩放时完全不触发更新。
另外，CSS 文件里媒体查询要和基础样式写在一起，不要拆成多个 @import 或独立 CSS 文件——HTTP/2 虽支持多路复用，但解析顺序混乱仍会导致 FOUC（闪白）或样式竞态。
用 rem + 媒体查询调字体，但别用 JS 动态改 font-size
字体响应式最稳妥的方式是根元素 font-size 配合 rem，再由媒体查询阶梯调整：
html { font-size: 16px; }<br>@media (max-width: 767px) { html { font-size: 14px; } }<br>@media (min-width: 1024px) { html { font-size: 18px; } }
这样所有 rem 单位会自动重算，无需 JS 干预。
千万别用 JS 监听 resize 去改 document.documentElement.style.fontSize —— 频繁触发重排，滚动卡顿明显，且在 iOS Safari 的 pinch-zoom 下根本不同步。
注意：不要把 html { font-size } 写在媒体查询外层设成 62.5% 再套多层 media；现代浏览器对百分比计算有累积误差，尤其在 zoom=110% 时字体跳变明显。
表格、导航、图片这些“硬骨头”怎么切
纯 CSS 媒体查询能解决大部分布局切换，但某些结构天生不适合“一码通吃”，得提前设计好语义化 fallback 方案。
比如表格：
- 小屏下别强行横向滚动，用
display: block把每行转成卡片，th用position: absolute贴左作为标签 - 避免用
display: table-cell+white-space: nowrap强撑，容易溢出容器且无法语音朗读
导航栏：
- 小屏隐藏完整菜单，用
<button aria-expanded>控制<nav>显隐，而非直接display: none - 别依赖 JS 切换 class 来模拟“汉堡菜单”——无 JS 时整个导航消失，SEO 和可访问性双崩
图片：
- 单张图必加
max-width: 100%; height: auto;，否则在窄屏上直接撑破容器 - 需要多分辨率适配时，用
srcset+sizes，别用 JS 检测window.devicePixelRatio后动态换src—— 首屏加载慢、缓存失效、CDN 不识别
真正难的从来不是写多少媒体查询，而是 HTML 结构是否允许不同视口下用同一套 DOM 表达不同语义。一旦开始为“大屏”和“小屏”写两套 HTML，后续维护成本和可访问性问题就会指数级上升。
