一眼判断html语义是否到位：看dom结构中是否存在“靠class活着”的区块，即div占比超60%、无header/nav/main等语义容器包裹、用div class="btn"替代button、img缺alt或alt=""未配role="presentation"、form内input未正确关联label；同时警惕语义漂移，如滥用article替代card导致机器误判为独立条目。
怎么一眼判断HTML语义是否到位
别翻MDN查标签定义，直接看DOM结构里有没有“靠class活着”的区块。打开DevTools Elements面板，选中一个
header里、也没被nav或main等语义容器包含，基本就是语义空转。
常见信号包括：
-
div占比超过页面总元素60%，且多数div只带class不带语义功能 - 用
div class="btn"模拟按钮，却没用button或加role="button" -
img没alt，或写了alt=""但没同步加role="presentation" -
form里input没配label，或for和id不匹配
替换语义标签时最常踩的嵌套坑
不是所有div都能无脑换，关键看内容是否具备独立性与上下文职责。比如把一段介绍文字包进article，结果它只是主页上的一个简介模块——这违反了article“可独立分发”的语义前提。
必须守住的硬规则：
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
-
main只能出现一次，且不能是article、aside、nav的子元素 -
header和footer必须是body或最近的section/article的直系子元素 -
nav只包主导航链接组；面包屑、分页、文章内锚点链接不属于它 - 嵌套层级超过4层（如
div→section→article→figure→img）时，JS查询和CSS选择器开销明显上升，建议拆成多个section或用template
重构后怎么验证是不是真变好了
别只盯着代码漂亮了。真正有效的验证是“关掉CSS再读一遍”：纯文本状态下，内容是否仍按视觉流顺序自然呈现？标题层级是否连贯？Tab键焦点是否从上到下依次落在导航、主内容、侧栏、页脚？
实操验证步骤：
- 运行
Lighthouse→ Accessibility审计，重点盯heading-levels、landmark-roles、logical-tab-order三项是否全绿 - 在Chrome DevTools Elements面板右键任意元素 →
Break on→Attribute modifications，观察DOM变更是否集中在预期区域（避免全局重渲染） - 执行
document.querySelectorAll("*").forEach(el => el.children.length > 50 && console.warn("deep container:", el))，快速揪出子元素爆炸的容器节点 - 用屏幕阅读器（如NVDA）朗读页面，确认
nav能被快捷键N跳转，main能被M直达
为什么有些重构越改越烂
最容易被忽略的是“语义漂移”：比如把旧版<div class="card">全替换成<code><article></article>，结果每个卡片都带了pubdate、author等冗余属性，反而让机器误判为独立新闻条目；或者给所有section加aria-labelledby，却忘了它们根本没对应的h2——这些细节不会报错，但会让无障碍工具和SEO解析器集体困惑。
真正卡住后续迭代的，往往不是语法错误，而是语义与实际业务意图错位。多花10秒确认：section是否真代表一个逻辑主题块？aside里的内容是否确实“可删不影响主干”？time标签里的datetime值是否真实可解析？
