HTML与CSS是同步协同而非线性先后的关系：1. 语义化结构与布局意图需在写首个标签时共同决策；2. 必须全局设box-sizing: border-box避免尺寸失控；3. Flex/Grid使用前需明确主轴、对齐与换行需求；4. grid-template-areas应按视觉草图声明，命名须严格匹配；5. 居中方案须匹配定位上下文，不可套用万能公式。
HTML结构和CSS不是“先写完HTML再套CSS”的线性流程，而是从第一行代码就开始互相影响的协作关系。结构不合理，CSS再怎么优化也救不回来；CSS滥用选择器或重排逻辑，会让语义清晰的HTML也卡顿。
HTML语义标签直接决定CSS可维护性
用 <nav> 替代 <div class="nav"> 不只是为了SEO，更是为了让CSS选择器能直击目标而不依赖冗余类名。比如：
- 写
nav ul li a比.header-nav__list-item__link更轻量、更不易因重构断裂 -
<main>作为唯一主内容容器，让main > article这类选择器天然具备层级约束，避免全局污染 - 滥用
<div>套娃后，CSS不得不靠多层类名（如.section-wrapper__content-inner）来定位，一旦结构调整，样式全崩
CSS选择器性能陷阱常源于HTML嵌套过深
浏览器匹配CSS是从右往左进行的。如果HTML里写了一串 <div><div><div><div><p>，而你用 div div div div p 选中它，引擎就得反复回溯——尤其在动画帧中频繁触发时，掉帧就来了。
- 优先用语义标签本身做选择器：
article h2比.post-content .title快且稳 - 避免无节制的后代选择器（空格），改用子选择器（
>）限定范围，前提是HTML结构支持 - 给需要高频操作的元素加明确的
id或短类名（如js-toggle），别指望靠深度遍历找它
display: contents 破解语义与布局的冲突
有时候你必须用 <section> 表达语义，但它默认是块级、带盒模型，干扰Flex/Grid布局流。这时 display: contents 能让该元素“消失”于渲染树，只保留子元素参与布局，又不破坏HTML语义。
立即学习“前端免费学习笔记（深入）”；
- 它不会移除元素本身，所以无障碍（a11y）和DOM结构依然完整
- 不兼容IE，但现代项目基本可放心用；若需兼容，得退回到包裹层+负margin等hack
- 慎用于含伪元素（
::before/::after）的元素——它们会随父元素一起“消失”
真正难的不是写出语义HTML或写出炫酷CSS，而是持续判断：这个标签在这里是否同时满足内容表达、样式可控、性能友好三个条件。多数卡顿和维护噩梦，都始于某次“先搞定功能再说”的妥协。
