语义化标签是自定义组件的结构骨架而非装饰，需用<article><section><aside>等明确界定边界，内部按功能角色组织<header><nav><main><footer>，并与框架协同保持语义纯净，以提升可访问性与SEO效果。

语义化标签在自定义组件中不是装饰，而是结构骨架。它让组件既对人可读、对机器可理解，也便于在不同上下文中复用和组合。

组件边界需由语义容器明确界定

自定义组件常被封装为 Web Component 或框架内的独立单元，但若内部仍用 <div class="card-header"> 这类写法，就丢失了结构意图。应优先使用语义化外层包裹：

• <article> 适合完整、可独立分发的内容组件，如博客卡片、产品详情块，支持被 RSS 聚合或搜索引擎单独索引
• <section> 更适合作为主题分组型组件，例如“用户评论区”“配置选项卡”，需配 <h2> 或更高层级标题
• <aside> 用于附属信息组件，如侧边推荐栏、术语提示框，逻辑上可移除而不影响主内容完整性

内部结构按角色而非样式组织

组件内部不应因视觉位置决定标签，而应按信息功能分配：

• 顶部区域含标题、作者、时间——用 <header>，搭配 <time datetime="..."> 提供机器可读时间
• 导航类操作（如标签页切换、步骤引导）——统一用 <nav>，即使它在组件中部或底部
• 核心展示内容（图文混排、数据图表）——放入 <main>（仅当该组件自身是页面主要内容）或直接作为 <article> 的主体流
• 版权、来源、元信息等补充说明——放在 <footer>，不局限于页面最下方

与框架/构建工具协同保持语义纯净

React、Vue 等框架中容易因 JSX 语法或条件渲染弱化语义。需注意：

• 避免用 <div> 包裹整个组件后靠 CSS 控制布局；改用 <article> 或 <section> 作为根节点
• 动态渲染的导航项（如权限控制菜单）仍应保留在 <nav> 内，不可因“部分链接不显示”就降级为 <div>
• 使用 asChild（如 Radix UI）或 as="nav"（如 Chakra UI）等机制，让封装组件透传语义标签，而非覆盖为 <div>

辅助技术与 SEO 效果直接受组件语义影响

一个语义清晰的组件，在嵌入不同页面时能自动适配上下文：

• 屏幕阅读器可识别 <article> 并提供“跳转到下一篇文章”快捷键，无需额外 ARIA
• 搜索引擎将 <article> 内的 <h1> 视为该内容的主标题，权重高于普通文本中的关键词
• 当组件被 SSR 渲染或静态生成时，语义结构确保爬虫一次抓取即获得完整内容模型，不依赖 JS 补全