打造现代化高可维护性HTML代码架构

使用场景：SEO 提升、辅助设备适配、自动化测试定位、团队协作时无需注释解释“这个 div 是导航”。

1. 、、
   、
   、、 必须成对出现，且
   应唯一
2. 避免
   这类无语义包裹；两个连续

   若主题相同，不如合并并用

   分隔子区块
3. 用于可独立分发的内容（如博客、新闻）；
   用于逻辑分组，不可替代
4. 标题层级必须严格：从 开始，
   是
   的首级标题，禁止跳级或用

   当首标 <template> 是 HTML 片段的唯一合法容器

   把页头 HTML 写在

   里，或拼字符串插入 innerHTML，短期省事，长期必踩坑：样式未加载、脚本不执行、相对路径 404、无 DOM 生命周期控制。

   性能影响：内联字符串会触发多次解析与重排；<template> 不渲染、不计算样式、不触发资源加载，JS 克隆后插入才是干净起点。

   1. 构建时静态加载推荐 Vite 的 import headerHtml from './header.html?raw'，Webpack 配 html-loader
   2. 运行时 fetch 加载后，若片段含 <script>，需手动创建并插入，否则逻辑断链
   3. <img src="logo.png"> 在 fetch 返回的字符串中会 404，除非已设 <base href="/> 或路径写成绝对
   4. 禁用 innerHTML += 拼接，每次都会重新解析整个字符串，且丢失已有事件监听器

   目录结构和文件组织决定后期改版成本

   一个没规划的 index.html 和一堆散落在根目录的 JS/CSS，等于给每次改版埋雷。目录结构不是为了整齐，是为了让“改哪里、动什么、影响谁”一目了然。

   容易踩的坑：图片路径写死、CSS 引入顺序混乱导致覆盖失效、多页面导航逐页复制粘贴。

   1. 根目录只放 index.html；css/、js/、images/、pages/ 四个标准目录必须存在
   2. images/ 下按用途再建子目录（如 icons/、banner/），避免所有图挤在一个文件夹
   3. 多页面统一导航推荐前端动态注入：用 nav-loader.js 定义 const navHTML = ``，而非服务端包含或重复写 HTML
   4. partials/ 存放模块化 HTML 片段（如 header.html、footer.html），配合 <template> + fetch 加载，确保复用与隔离

   复杂点在于模块边界一旦模糊，data-module 就会退化成另一个 class，语义标签会被当成“可有可无的装饰”，<template> 会被绕开直奔字符串拼接——这些不是技术选择问题，而是协作契约是否被真正执行的问题。