语义化标签（如、、）比更省事，因其被浏览器和辅助工具直接识别为导航区、主内容锚点、独立节区，提升可访问性与seo，避免后期重构。
直接用语义化标签 + 流式容器 + 移动优先的媒体查询，就能写出真正简洁又可用的响应式 HTML 结构——不需要框架、不依赖 JS、不堆砌 div。
为什么 <nav><main><section></section></main></nav> 比 <div class="header"> 更省事
<p>不是为了“规范”，而是浏览器和辅助工具靠这些标签推断结构。比如 <code><nav></nav> 被读屏器识别为“导航区”，<main></main> 告诉键盘 Tab 从哪开始聚焦；漏掉语义，后期加无障碍支持时就得重写结构。
-
<header></header> 包住 logo 和主导航，别再套两层 <div>
<li>
<code><nav></nav> 必须直接包含 <ul><li><a></a></li></ul>，否则移动端 checkbox 控制菜单时 :checked ~ .menu 会失效
-
<section></section> 替代 <div class="card">：它自带文档节区含义，SEO 和打印样式都自动适配
<li>避免 <code><div id="wrapper"> 这类空泛容器——90% 场景下，<code><main></main> 或 <article></article> 就是它的语义替代
max-width 和 width: 100% 在容器上怎么选
关键看“是否要限制最大宽度”。桌面端内容太宽会降低可读性，但移动端又不能被截断。
- 外层容器用
max-width: 1200px + margin: 0 auto，文字行宽控制在 60–80 字符内
- 但这个容器必须同时设
width: 100%，否则小屏下会留白（因为 max-width 不会自动收缩到 100%）
- 错误写法：
.container { max-width: 1200px; } → 小屏下实际宽度还是 1200px，溢出滚动
- 正确写法：
.container { width: 100%; max-width: 1200px; margin: 0 auto; }
媒体查询断点别硬写 768px 和 1024px
这些数字来自旧 iPad，现在大量安卓平板、折叠屏、Chromebook 的宽度根本不在这个区间。真正在意的是“内容开始挤”或“行宽过长”的临界点。
- 先写移动样式（无媒体查询），再逐步加
@media (min-width: ...)
- 用内容驱动断点：比如导航项文字换行了，就在此刻加
@media (min-width: 480px)
- 避免多个断点叠写：不用为“iPhone SE / iPhone 12 / Pixel 5”各写一条，用
clamp(1rem, 4vw, 1.25rem) 配合单个 @media (min-width: 600px) 覆盖更广
- 注意：IE11 不支持
clamp()，如需兼容，退回到 font-size: 1rem; + 媒体查询内改
图片和 iframe 怎么写才不破坏流式布局
它们是响应式中最容易失控的元素，因为默认按原始尺寸渲染。
- 所有
<img> 必须加 width: 100% 和 height: auto，否则在 flex/grid 容器里会撑开父级
- 如果图片需要居中且不拉伸，用
object-fit: cover + object-position: center，而不是 background-image
-
<iframe></iframe>（比如嵌入地图）必须包一层容器，并设 aspect-ratio: 16/9 或用 padding-bottom hack；单独设 width: 100% 会导致高度塌陷
- 慎用
srcset + sizes：简单项目里，一张 WebP + max-width: 100% 已足够，过早优化反而增加维护成本
最常被忽略的其实是字体大小和行高——它们没设相对单位时，放大页面或切换系统字号就会让整个布局错位。用 rem 基于根字体，配合 line-height: 1.5 这类无单位值，才能让文字真正“流动”起来。
<header></header> 包住 logo 和主导航，别再套两层 <div>
<li>
<code><nav></nav> 必须直接包含 <ul><li><a></a></li></ul>，否则移动端 checkbox 控制菜单时 :checked ~ .menu 会失效<section></section> 替代 <div class="card">：它自带文档节区含义，SEO 和打印样式都自动适配
<li>避免 <code><div id="wrapper"> 这类空泛容器——90% 场景下，<code><main></main> 或 <article></article> 就是它的语义替代
max-width 和 width: 100% 在容器上怎么选
关键看“是否要限制最大宽度”。桌面端内容太宽会降低可读性，但移动端又不能被截断。
- 外层容器用
max-width: 1200px+margin: 0 auto，文字行宽控制在 60–80 字符内 - 但这个容器必须同时设
width: 100%，否则小屏下会留白（因为max-width不会自动收缩到 100%） - 错误写法：
.container { max-width: 1200px; }→ 小屏下实际宽度还是 1200px，溢出滚动 - 正确写法：
.container { width: 100%; max-width: 1200px; margin: 0 auto; }
媒体查询断点别硬写 768px 和 1024px
这些数字来自旧 iPad，现在大量安卓平板、折叠屏、Chromebook 的宽度根本不在这个区间。真正在意的是“内容开始挤”或“行宽过长”的临界点。
- 先写移动样式（无媒体查询），再逐步加
@media (min-width: ...) - 用内容驱动断点：比如导航项文字换行了，就在此刻加
@media (min-width: 480px) - 避免多个断点叠写：不用为“iPhone SE / iPhone 12 / Pixel 5”各写一条，用
clamp(1rem, 4vw, 1.25rem)配合单个@media (min-width: 600px)覆盖更广 - 注意：IE11 不支持
clamp()，如需兼容，退回到font-size: 1rem;+ 媒体查询内改
图片和 iframe 怎么写才不破坏流式布局
它们是响应式中最容易失控的元素，因为默认按原始尺寸渲染。
- 所有
<img>必须加width: 100%和height: auto，否则在 flex/grid 容器里会撑开父级 - 如果图片需要居中且不拉伸，用
object-fit: cover+object-position: center，而不是 background-image -
<iframe></iframe>（比如嵌入地图）必须包一层容器，并设aspect-ratio: 16/9或用 padding-bottom hack；单独设width: 100%会导致高度塌陷 - 慎用
srcset+sizes：简单项目里，一张 WebP +max-width: 100%已足够，过早优化反而增加维护成本
最常被忽略的其实是字体大小和行高——它们没设相对单位时，放大页面或切换系统字号就会让整个布局错位。用 rem 基于根字体，配合 line-height: 1.5 这类无单位值，才能让文字真正“流动”起来。
