响应式布局本身不慢，慢的是结构冗余、媒体查询滥用和样式重排频繁；关键在减干扰而非加功能，应通过语义化html、合并媒体查询、合理选用flex/grid及按需加载来优化性能。
响应式布局本身不慢，慢的是结构冗余、媒体查询滥用、样式重排频繁。关键不在“加功能”，而在“减干扰”。
HTML语义化结构直接影响回流成本
浏览器构建 render 树前必须先解析 DOM，<div> 套 <code><div> 会延长解析时间，也增加 CSS 选择器匹配开销。尤其在小屏设备上，JS 执行能力弱，DOM 深度每多一层，首屏渲染延迟就明显一点。
<ul><li>用 <code><header></header>、<nav></nav>、<main></main>、<section></section> 替代无意义的 <div class="wrapper"> —— 不仅利于可访问性，也减少无效节点参与 layout 计算
<li>避免在 <code><main></main> 内嵌套多层 <div> 包裹图文卡片；直接让卡片作为 <code><section></section> 或 <article></article> 的子元素
display: none 而非 visibility: hidden 或 opacity: 0 —— 后两者仍参与 layout 和 paint 流程@media 查询写法影响 CSSOM 构建速度
浏览器解析 CSS 时，所有 @media 规则都会被读入 CSSOM，即使当前不匹配。大量分散、重复的断点声明会让 CSS 文件体积膨胀，也拖慢样式计算。
- 合并同类断点：把所有
@media (max-width: 768px)下的规则集中到一个块里，而不是每个组件都写一遍 - 避免嵌套媒体查询（如 Sass 中的
@media嵌套在选择器内）—— 编译后易生成冗余规则，且无法被 CSS 压缩工具有效去重 - 慎用
orientation或hover等动态媒体特性：它们触发重计算的频率高，且部分低端 Android 设备对其支持不稳定 - 移动端优先时，基础样式写默认态（小屏），只用
@media (min-width: 769px)描述大屏增强，而非反向堆叠
CSS Grid / Flexbox 的渲染代价差异
Grid 和 Flex 都是现代布局利器，但 Grid 在初始 layout 阶段计算量略高，尤其当显式定义了 grid-template-areas 或大量 grid-column 行内声明时。
- 对简单一维排列（如导航项、图文列表），优先用
display: flex—— 浏览器优化更成熟，兼容性调试成本更低 - Grid 更适合二维控制场景（如响应式九宫格、复杂仪表盘），但应避免在每个卡片上都写
grid-column: span 2；改用grid-auto-flow: dense+grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)) - 不要在动画中频繁切换
display: grid↔display: flex—— 这会强制触发完整回流，比单纯改transform重得多
最常被忽略的点：性能瓶颈往往不在“怎么写响应式”，而在于“哪些本不该响应”。比如一个仅用于打印的 @media print 样式块，如果混在主 CSS 文件里且未压缩，它照样参与 CSSOM 构建——哪怕用户永远不点打印。拆分用途、按需加载，比调优单条媒体查询更有效。
