语义化HTML是响应式与可访问性的根基：必须用<main>等语义标签而非div，配合min-width防flex塌陷、em断点适配字体缩放、<picture>设宽高防抖动，并确保源码顺序匹配内容优先级。
直接说结论：结构混乱的HTML，再 fancy 的 CSS 动画或 JS 交互也救不回来；响应式不是“加个 @media 就完事”，它必须从 <header>、<main>、<nav> 这些语义标签开始扎根。
为什么用 <main> 而不是 <div id="main">？
浏览器和读屏软件靠语义标签识别内容优先级。<main> 明确告诉辅助技术“这是页面唯一主内容区”，而 <div id="main"> 只是普通容器，无语义。SEO 也会更倾向抓取 <main> 内的标题层级与文本密度。
- 每个页面只能有一个
<main>，重复使用会触发 W3C 验证警告 -
<main>不能嵌套在<article>、<aside>、<footer>、<header>或<nav>内部 - 若用 JS 动态插入内容，记得同步更新
<main>的aria-live属性（如aria-live="polite"），否则屏幕阅读器可能不播报更新
flex 布局中 flex-wrap 和 min-width 的配合陷阱
常见错误：设了 display: flex + flex-wrap: wrap，但子项没设最小宽度，导致小屏下元素被强行压缩变形甚至文字换行错乱。
- 给 flex 子项加
min-width: 280px（或min-width: 15rem）能防止过度收缩，尤其适用于卡片、按钮组 - 避免对 flex 容器设
width: 100%同时又设max-width: 1200px—— 这会导致小屏下容器仍占满视口，但内容却被max-width截断 - 移动端慎用
flex-direction: column-reverse，部分安卓 WebView 会忽略该值，造成视觉顺序与 DOM 顺序不一致，影响键盘焦点流
@media 断点别只盯着像素，先看内容撑不撑得住
很多团队按 768px / 992px / 1200px 硬套，结果平板横屏（1024×768）下导航栏文字挤成一团，而某些 1366px 笔记本反而因 DPI 高显示模糊——问题不在分辨率，而在内容密度。
立即学习“前端免费学习笔记（深入）”；
- 优先用
em写断点：@media (min-width: 48em)（即 48 × 默认字号 = 768px），比像素值更适配用户自定义字体缩放 - 关键断点应基于内容：比如当导航菜单第 5 项开始换行，就在此宽度设断点改用汉堡菜单；当侧边栏文字行宽超过 85 字符，就触发两列变单列
- 避免嵌套媒体查询，CSS 里写两层
@media容易漏掉中间状态，统一用移动优先，基础样式写默认（小屏），再用min-width逐级增强
<picture> + srcset 不是万能，得配 width 和 height 属性防布局抖动
图片加载前若没预留空间，加载瞬间会把下方内容往下顶，破坏滚动节奏，尤其在列表页或卡片流中明显。
- 必须为
<img>或<picture>设置width和heightHTML 属性（不是 CSS），浏览器才能提前计算占位尺寸 -
srcset中的描述要匹配实际设备像素比：比如image.jpg 1x, image@2x.jpg 2x，而非全写2x，否则低 DPI 设备也会下高清图 -
<picture>的<source>用media属性时，注意它只匹配媒体查询条件，不参与图片选择逻辑；真正决定加载哪张图的是srcset+sizes组合
最常被跳过的其实是内容顺序：视觉上左右并排的两栏，在 HTML 源码里如果把侧边栏写在前面，小屏折叠后它就会跑到主内容上方——这不是 CSS 能修的，得从最初写 <main> 和 <aside> 的顺序就开始想清楚。
