HTML嵌套超4层须立即检查，因浏览器同步构建DOM树，每增一层即多一次节点创建、样式计算与布局重排；实测5层以上在低端安卓机致首屏延迟20–50ms，根源在于BEM冗余wrapper、Vue组件未扁平化等真实诱因。
HTML嵌套超过4层就该立即检查
浏览器解析HTML是同步构建DOM树的过程，每多一层
，就多一次节点创建、样式计算和布局重排。实测显示：5层以上嵌套在低端安卓机上可导致首屏延迟20–50ms。这不是理论瓶颈，而是真实卡顿源头。
首屏图片加
常见诱因包括：
- BEM类名强绑定催生的冗余wrapper，例如
<div class="card__wrapper"><div class="card__inner">...</div></div> - Vue单文件组件未启用
<template>根节点扁平化，编译后自动包裹<div> - 为兼容老CSS硬加
clearfix容器，实际已可用display: flow-root替代
检查方式不是看源码缩进，而是打开开发者工具Elements面板，观察**构建后的真实DOM层级**——这才是浏览器真正要处理的结构。
语义化标签不是“锦上添花”，而是性能刚需
用<header>代替<div class="header">，不只是为了SEO或可访问性。浏览器对语义化标签的解析路径更短，CSS选择器匹配更快，且部分标签（如<main>）天然具备唯一性约束，减少无效遍历。
立即学习“前端免费学习笔记（深入）”；
关键规则：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<main>在页面中只能出现一次，且不应被<section>包裹——<section><main></main></section>会破坏语义并增加无意义节点 -
<nav>只用于导航链接集合，不用于侧边栏菜单或分页控件；非导航类列表请用<ul>或<ol>，而非<div>+ JS模拟 -
<figure>+<figcaption>必须成对出现，单独用<div>包图片+文字，会丢失语义关联，影响屏幕阅读器识别
Flex/Grid替代浮动时，别让布局引擎“二次决策”
传统浮动布局依赖“父清子浮”，必然引入额外<div class="row">；而现代布局引擎允许父级直接定义关系，子项无需包裹。但误用会放大性能代价。
选型原则：
- 一维线性排列（导航栏、表单控件）优先用
display: flex；避免在flex容器内再套grid做微调——这通常说明模块职责没切分清 - 二维布局（卡片流、仪表盘）用
display: grid，但必须显式声明grid-template-rows；否则隐式轨道（auto高度）可能触发多次重排 - 三列等宽布局，老写法需3层嵌套，新写法：
<main style="display: grid; grid-template-columns: 1fr 1fr 1fr;"><section>A</section><section>B</section><section>C</section></main>
首屏图片加loading="lazy"等于主动降级LCP
loading="lazy"确实能减少三屏外图片请求数，但滥用会直接拉垮LCP（最大内容绘制）。浏览器对首屏图片有严格加载优先级策略，加了lazy等于告诉它“这个不重要”。
必须遵守的底线：
- 首屏可见区域内的
<img>必须去掉loading属性，或显式设为loading="eager" - 所有带
loading="lazy"的图片，必须同时声明width和height属性，否则会引发CLS（累积布局偏移） -
<iframe>也支持loading="lazy"，但仅当其内容非首屏关键路径时才启用 - 服务端渲染动态拼接HTML时容易漏掉这些属性，建议用模板引擎预置校验规则
真正难的是平衡：DOM扁平化要求删掉wrapper，但某些CSS逻辑又依赖父容器存在；语义化标签强制单一职责，但业务组件常需复用结构。这些冲突点，才是优化落地时最该花时间权衡的地方。
