HTML语义化错误会大幅增加CSS/JS维护成本、损害无障碍访问与SEO，需用等标签明确结构角色，避免滥用、纯表现类名及动态渲染丢语义。
HTML语义化标签选错会导致CSS和JS维护成本翻倍
用 <div> 套一切，短期写得快，半年后加个“跳转到正文”逻辑时，你得翻三遍HTML才能定位目标区域。屏幕阅读器、搜索引擎、甚至你自己写的 <code>document.querySelector 都依赖语义——<main></main> 就是主内容区，<nav></nav> 就是导航，<article></article> 表示独立可分发的内容单元。
常见错误现象：Uncaught TypeError: Cannot read property 'querySelector' of null，表面是JS找不到元素，根因常是结构里该用 <section></section> 却写了 <div class="section">，导致选择器依赖类名而非语义，一改类名全崩。
<ul><li>不要为“看起来像标题”就用 <code><h2></h2>，而忽略它在文档大纲里的层级意义；真正需要降级标题语义时，用 aria-level 配合 <div role="heading">
<li>
<code><button></button> 和 <div onclick> 在键盘焦点、空格/回车触发、禁用状态样式上行为完全不同，后者必须手动补全所有可访问性逻辑
<li>表单控件必须配 <code><label for="xxx"></label> 或包裹输入项，否则 document.getElementById("xxx").focus() 可能失效，自动化测试也容易漏交互点
CSS里过度依赖类名会拖慢重构节奏
当一个按钮样式靠 .btn-primary + .btn-large + .btn-rounded 组合出来，改设计时就得全局搜这仨类名；而如果用语义化结构配合作用域化CSS（比如用 article header button 表示文章页头的操作按钮），改样式只需动一处规则，且含义自解释。
性能影响：类名越多，CSS选择器匹配越慢，尤其在移动端低端机上，.header .nav .item.active 比 nav a[aria-current="page"] 多一次DOM树遍历。
立即学习“前端免费学习笔记（深入）”；
- 避免用
.red-text、.mt-2这类纯表现类名，它们把样式逻辑泄漏到HTML里，破坏关注点分离 - 组件级CSS（如CSS Modules）中，用
:global(.btn)接入语义化基础类，比全靠本地类名更利于跨项目复用 - 用
prefers-reduced-motion媒体查询时，依赖这种语义化标记，比每个组件单独监听更轻量
团队协作中，HTML结构不一致会让PR评审变成猜谜游戏
新人提交的代码里，同样一个面包屑导航，有人写 <ol class="breadcrumb"></ol>，有人用 <nav aria-label="Breadcrumb"><ul></ul></nav>，还有人直接 <div class="flex">。结果：组件库抽离失败、自动化a11y扫描报一堆重复警告、文案替换脚本误删导航文字。
<p>真实使用场景：CI流程中跑 <code>axe-core 扫描，region、banner、complementary 等ARIA landmark缺失，直接被标为阻断项；但这类问题无法靠JS自动修复，必须从HTML源头规范。
- 建立最小语义基线：强制要求每个页面含
<header></header>、<main></main>、<footer></footer>，并用role显式标注非标准区域（如侧边栏用<aside role="complementary"></aside>） - 用Prettier + ESLint +
eslint-plugin-jsx-a11y在保存时拦截<img alt="HTML语义化结构与网站可维护性的关系_清晰代码对团队协作的好处【总结】" >缺alt、<input>缺label等硬伤，比Code Review时口头提醒有效得多 - 组件文档里不只写props，还要注明“此组件输出的HTML片段必须包裹在
<article></article>内”，否则下游集成方可能无意破坏语义流
可维护性最脆弱的环节：动态渲染时丢掉语义
React/Vue里用 v-for 或 {list.map()} 渲染列表，很容易写出 <div v-for="item in list">{{ item.title }}</div>——它能显示，但丢失了 <ul><li></ul> 的列表语义，语音朗读会连读成一段话，无障碍工具无法识别项数和位置。
错误现象：Warning: validateDOMNesting(...): <div> cannot appear as a child of <ul> 这类警告常被忽略，但实际意味着结构已偏离预期语义模型。
<ul>
<li>服务端渲染（SSR）或静态生成（SSG）时，优先保证初始HTML语义完整，JS接管后再增强，别等JS加载完才补 <code><main></main>
React.Fragment 或 <template></template> 时，确认其父容器本身具备正确语义（比如 Fragment 外层是 <section></section> 而不是 <div>）
<li>富文本编辑器输出HTML，必须过滤掉 <code><font></font>、<center></center> 等废弃标签，并将 style="text-align:right" 转为 class="text-right" 再映射到语义化布局类语义不是加几个新标签就完事，而是每次写HTML前多问一句：这个元素在文档大纲里扮演什么角色？它的存在是否让机器和人都更容易理解上下文？这点一旦松懈，后面所有人——包括未来的你——都会在调试、测试、改版时反复踩同一个坑。
