面试官考察的是语义化实战能力：能否根据内容意图准确选用标签（如新闻列表用<article>而非<div>），评估兼容性风险（如IE9需display:block），区分<article>（可独立复用）与<section>（依附上下文），并在SEO、无障碍、浏览器支持间合理权衡。
因为语义化标签不是“用不用”的问题，而是“会不会判断、敢不敢选、有没有踩过坑”的实战能力筛子。
面试官真正在考什么：语义化不是背标签列表
他们不关心你能背出 <article> 和 <section> 的定义，而是在看：你写一个新闻列表页时，会不会把每条新闻包进 <article> 而不是 <div>；你改一个老项目时，看到一堆嵌套 <div class="header">，能不能意识到该换成 <header> 并评估兼容性风险。
常见错误现象包括：
- 用
<section>替代所有逻辑分组，导致结构扁平、<h1>~<h6>层级混乱 - 在 Vue/React 组件中硬塞
<main>，却忽略单页应用里<main>应全局唯一（否则屏幕阅读器会误判） - 为兼容 IE8 强行降级用
<div role="navigation">，但忘了加 ARIA 属性或 fallback 样式
哪些场景下必须用、哪些可以不用
语义化不是银弹。实际项目里要权衡三件事：SEO 需求、无障碍要求、浏览器支持范围。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 内容型网站（博客、文档站、政府门户）：必须用
<header>、<nav>、<main>、<article>，搜索引擎和读屏器依赖这些做结构解析 - 后台管理系统 / 内部工具：可只对页面骨架语义化（比如外层
<header>+<aside>+<main>），表单、卡片、弹窗等交互模块用<div>更灵活 - 微信小程序或 Electron 桌面端：HTML 语义化基本无效——没有爬虫，也无原生读屏器支持，强行套用反而增加维护成本
<article> 和 <section> 的区别到底在哪
这是高频翻车点。关键不在“是不是区块”，而在“是否独立可复用”。
-
<article>：内容能脱离当前页面存在，比如一篇博客、一条微博、一个商品卡片——复制粘贴到 RSS 或另一个网站仍成立 -
<section>：只是文档内的逻辑分组，比如“用户评论区”“相关推荐”，离开上下文就失去意义 - 错误用法：
<section>里塞多个<article>是合理的；但反过来，把单篇新闻包进<section>就丢失了其独立语义
容易被忽略的兼容性和性能细节
很多候选人知道“语义化好”，但不知道它怎么悄悄影响运行时。
- CSS 重置成本：IE9+ 才原生支持语义标签样式，老项目若没引入
html5shiv，<nav>可能直接不渲染 - 无障碍陷阱：用了
<nav>却没加aria-label，屏幕阅读器只会念“navigation”，用户不知道这是顶部导航还是底部快捷链接 - SSR 注意点：服务端渲染时，
<main>必须且只能出现一次，重复会导致 Lighthouse 报错 “document has more than one <main>”
最复杂的其实是权衡——比如为了 SEO 用 <article>，但后端返回的数据结构不带发布时间、作者等字段，此时硬套语义反而让结构失真。这时候宁可用 <div role="article"> 加必要 ARIA，也别牺牲语义完整性。
