语义化标签是DOM结构的硬约束，而非锦上添花：原生标签（如<header>、<nav>、<main>）自动进入无障碍树，使屏幕阅读器、搜索引擎可理解结构；用<div class="nav">替代<nav>将主动放弃该能力，导致SEO下降、Lighthouse评分低、JS类名绑定脆弱等问题。
语义化标签不是“锦上添花”，而是DOM结构的硬约束
浏览器解析HTML时，会同步构建两棵树：渲染树和无障碍树。只有原生语义标签（如 <header>、<nav>、<main>、<section>、<footer>）才能自动进入无障碍树——这意味着屏幕阅读器、搜索引擎、自动化测试工具能真正“理解”你的结构。用 <div class="nav"> 替代 <nav>，等于主动放弃这部分能力。
常见错误现象包括：SEO收录率低、Lighthouse可访问性评分卡在60分以下、JS通过 document.querySelector(".header") 绑定事件后，改个类名就全崩。
- 所有页面级容器必须用语义标签，禁止出现连续三层以上
<div>嵌套 -
<main>全局唯一，且不能作为<article>或<section>的直接父级 -
<time datetime="2026-07-02">这类带机器可读属性的标签，必须补全datetime值，否则等同于没写
嵌套深度超过4层时，首屏性能已开始受损
实测表明：DOM节点嵌套达5层时，在中低端安卓设备上可导致首屏延迟20–50ms。这不是理论值，而是真实用户可感知的卡顿。问题不在于你写了多少JS，而在于浏览器构建DOM树时多做了几次节点创建和样式计算。
容易踩的坑是把BEM类名逻辑直接映射到DOM结构——比如看到 card__content--large 就本能套一层 <div class="card__content">，结果 <div><div><div><p> 一气呵成。
立即学习“前端免费学习笔记（深入）”；
- 优先用
display: contents或 Flex/Grid 容器直排子元素，跳过无意义包裹层 - 检查 Elements 面板里的**实际渲染DOM**，不是源码缩进——JS动态插入或模板引擎拼接后可能更糟
-
<iframe>、<img>等替换元素自带隐式盒模型，别再在外层加<div class="wrapper">
Vite + HTML Modules 是当前最轻量的工程化落地路径
毕业设计或中小项目没必要上Webpack或React。Vite 启动快、热更新准、原生支持 import 语法，配合浏览器原生模块能力，就能实现真正的组件复用——比如导航栏抽成 nav.html，用 fetch() 加载后 insertAdjacentHTML 注入，比复制粘贴10次安全得多。
但要注意：Vite 默认不处理纯HTML文件的模块导入，需手动配置 vite-plugin-html 或用 <script type="module"> 加载逻辑。
- 所有公共片段（页头、页脚、侧边栏）统一放在
/src/partials/目录，命名与文件名严格一致 - 避免在HTML里写内联脚本；JS逻辑统一用
type="module"引入，利用ESM的静态分析优势 - 图片、字体等资源路径全部走
./assets/，Vite会自动哈希并注入正确路径，不用手写../..
class命名不是风格偏好，而是协作契约
当多人维护一个项目时，class="red-text" 和 class="btn-primary" 的区别在于：前者描述样式，后者描述意图。一旦设计系统换色，前者要全局搜索替换，后者只需改CSS变量。
更隐蔽的问题是命名冲突：.container 在Bootstrap里是固定宽度居中，在你自己写的轮播组件里却是相对定位容器——两个CSS文件一合并，样式就打架。
- 强制使用 kebab-case（小写+短横线），如
user-profile-card，禁用下划线或驼峰 - 禁止用纯样式词（
left、big、red），改用功能/内容词（sidebar-nav、hero-cta） - 布尔状态统一用双连字符修饰符：
is-loading、has-error，而不是loading或error
<div> 前是否真问过自己：这个节点有没有语义？它会不会被JS或CSS强依赖？它在无障碍树里存在吗？ 
