最容易误用的语义标签是和，常被当作纯视觉的顶部/底部div滥用；它们实际表示内容区块的页眉页脚，可嵌套在或内，且应与等元素保持语义独立。
<main></main> 必须每页只出现一次，且不能嵌套在 <article></article> 或 <section></section> 里；<nav></nav> 不是“所有导航链接”的通用容器，只适用于主导航——面包屑、页脚链接、侧边推荐都不算。
哪些语义标签最容易误用
真实项目里，<header></header> 和 <footer></footer> 被当成“顶部 div / 底部 div”滥用最多。它们不是视觉定位标签：<header></header> 可以出现在 <article></article> 内部（比如每篇文章自己的标题区），<footer></footer> 也能嵌套在 <section></section> 末尾（比如某章节的作者署名）。但若把整个页面顶部导航栏硬塞进一个全局 <header></header>，再在里面塞 <nav></nav>，就违背了语义层级：导航应独立于头部内容存在。
-
<section></section>必须有明确主题，且理想情况下带<h1></h1>–<h6></h6>标题；纯样式分隔不用它，直接用<div> <li> <code><aside></aside>不等于“右边栏”，而是指与当前内容相关但可分离的信息（如术语解释、引用来源）；广告位、登录框、全局推荐仍该用<div> <li> <code><time></time>必须带datetime属性（如<time datetime="2026-04-11">今天</time>），否则只是普通文本，无机器可读价值 - 多个格式兼容写法必须用
<source></source>嵌套，而非多个src属性 -
<video></video>内部的 fallback 文本（如“您的浏览器不支持 video 标签”）只在完全不支持时渲染，不是占位符 - 移动端对
autoplay和playsinline（防止全屏）有强依赖，漏掉playsinline可能导致 iOS 上强制跳转全屏 -
placeholder是提示，不是 label；无障碍要求必须配<label></label>或aria-label -
required属性触发表单提交前校验，但 JS 中仍需用checkValidity()主动判断 -
pattern配合正则使用，但错误提示文案由title属性提供，不是自动翻译
video 和 audio 标签的关键控制点
<video></video> 和 <audio></audio> 的核心价值是免插件播放，但默认行为常被忽略：controls 属性决定是否显示原生控件，不加就黑屏无声；autoplay 在多数现代浏览器中被策略限制（需静音或用户交互后触发）；preload 影响初始加载策略（"metadata" 最轻量，"auto" 可能提前拉取全部资源）。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
表单增强不是“多几个 type 就完事”
type="email"、type="date" 这类输入类型真正起效的前提是：浏览器原生支持 + 用户未禁用表单验证（novalidate 属性可关闭）。但更关键的是语义传达：type="search" 触发系统搜索键盘，type="tel" 唤起数字键盘，min/max 对 number 或 date 才有约束力。
语义标签的“正确性”不体现在渲染效果上，而在于 DOM 结构是否经得起屏幕阅读器跳转、搜索引擎抓取和 RSS 解析——<main></main> 里混进页脚链接，<nav></nav> 里塞进搜索框，这些细节在视觉上毫无破绽，却会让辅助技术彻底迷失。
