高频改版需靠“改得准”：用data-module锚定模块、语义标签定义DOM接口、<template>隔离副作用，三者缺一不可。
高频改版不是靠“写得快”，而是靠“改得准”——结构语义清晰、模块边界明确、JS/CSS锚点稳定，才能让每次改动只动该动的地方，不牵一发而动全身。
用 data-module 替代 class/id 做模块锚点
改版时最常崩的是 JS 查询逻辑：一个 $('.header-nav') 在新设计里被重命名为 class="top-bar-menu"，脚本就静默失效；document.getElementById('product-list') 在商品卡片循环渲染时直接重复，只取到第一个。
-
data-module是专为模块化设计的属性，不参与样式、不影响可访问性，且不会因视觉调整而变更 - 每个独立功能区块加根级
data-module="header"、data-module="product-grid"，版本号可同步加data-version="2.3" - JS 查询统一用
document.querySelectorAll('[data-module="header"]')，CI 流程可校验版本是否匹配文档 - 禁止在
data-module值里塞动态内容（如data-module="product-{{id}}"），它应代表抽象模块类型，不是实例标识
嵌套超三层必须重构，不是警告是红线
审查元素点开四层才看到 <p>，说明结构已失去可读性。高频改版下，这种嵌套会让每次增删字段都像拆炸弹：改一个 div 可能影响 CSS 选择器、JS 路径、甚至无障碍标签顺序。
- 块级容器层级建议 ≤3：例如
<main><section><article>，再深就该考虑拆成子模块或用<template> - 避免装饰性包裹：
<div><div><div><p>文本</p></div></div></div>—— 没有语义、没有样式钩子、没有 JS 目标，纯属历史债务 - Chrome DevTools 中右键节点 → “Break on” → “Attribute modifications”，能快速暴露冗余包裹层
- 合并语义一致的相邻容器：两个连续
<section>若主题相同，不如合并并用<h2>分隔子区块
HTML 片段必须用 <template> 包裹，禁用 display: none 或内联字符串
把页头 HTML 写在 <div style="display:none"> 里，或者拼接字符串插入 innerHTML，短期省事，长期必踩坑：样式未加载、脚本不执行、相对路径 404、无 DOM 生命周期控制。
立即学习“前端免费学习笔记（深入）”；
-
<template>不渲染、不计算样式、不触发资源加载，JS 克隆后插入才是干净起点 - 构建时静态加载推荐 Vite 的
import headerHtml from './header.html?raw'，Webpack 配html-loader - 运行时 fetch 加载后，若片段含
<script>，需手动创建并插入，否则逻辑断链 -
<img src="logo.png">在 fetch 返回的字符串中会 404，除非已设<base href="/">或路径写成绝对
语义标签不是“锦上添花”，是改版时的 DOM 接口契约
当设计师说“把导航移到右边”，你改的不该是 CSS 的 float，而是把 <nav> 从 <header> 移到 <aside> —— 标签本身定义了它“是什么”，而不是“在哪”。
-
<main>每页只能有一个，这是 W3C 强制要求，axe 等工具会报错，屏幕阅读器依赖它定位主体 -
<section>必须带<h2>或更高阶标题，否则辅助技术无法识别其主题，SEO 也会降权 -
<aside>不等于“右边栏”，而是与当前上下文相关但可独立存在的补充内容（如文章旁的作者简介） - 用
<time datetime="2026-07-02">今天</time>替代纯文本日期，机器可解析，改版时无需额外适配时间格式逻辑
高频改版真正难的不是写新代码，而是判断“哪一段 HTML 属于哪个模块、谁在用它、改了会影响什么”。data-module 定义归属，<template> 隔离副作用，语义标签锁定 DOM 接口——这三样缺一不可，少一个，改三次就累垮一个人。
