组件内部必须用语义化标签而非div堆砌，因HTML无原生组件概念，语义嵌套才能表达内容关系、保障可访问性与JS稳定性。
组件内部结构必须用语义化标签，不是靠堆深度
HTML 本身不提供“组件”概念，所谓“组件内部逻辑编套”，本质是用语义化嵌套表达内容关系。硬套 <div> 层层包裹，只会让结构松散、JS 选中不稳定、屏幕阅读器失效。
-
<main> 必须全局唯一，不能嵌在 <section> 或 <div> 里——W3C 明确禁止，否则语义崩塌
- 导航区域写成
<nav><ul><li>...</li></ul></nav>，而不是 <div class="nav"><ul>...</ul></div>；前者能被辅助工具识别为导航区，后者只是视觉分组
- 步骤条必须用
<ol>，不是 <ul> 或 <div>：序号、aria-current="step"、counter-increment 全依赖它
- 列表嵌套只允许在
<li> 内部放 <ul> 或 <ol>，跨层级或交叉闭合（如 <ul><li><ol>...</ul></ol>）会触发解析错误
嵌套超过 3 层时，大概率是结构没想清，不是 CSS 没写好
常见现象：一个卡片组件写成 <div class="card"><div class="card__body"><div class="card__content"><p>...</p></div></div></div>。这不是“精细控制”，而是职责模糊、样式耦合、JS 难维护。
- 每层
<div> 应有明确语义边界：比如 <article> 包正文，<header> 包标题和元信息，<footer> 包操作按钮——不是为了“看起来像”，是为了让浏览器和 JS 知道“这一块是什么”
- 深层嵌套常伴随 class 名爆炸（
card__content__text__highlight），说明本该用更上层语义标签收束，而非靠 class 模拟结构
- 用 CSS Grid 嵌套比 DOM 嵌套更轻量：一个
<section> 设为 display: grid，其子元素再设 display: grid 即可实现“逻辑列下的多子列”，无需额外 <div>
动态生成嵌套结构时，优先用 document.createElement 而非 innerHTML
当 JS 需构建带状态的组件（如步骤条、表单卡片），innerHTML 容易引入 XSS 风险且无法精准控制属性；document.createElement 虽稍冗长，但可控性强、语义清晰。
- 不要这样写：
el.innerHTML = '<div class="step"><span>' + title + '</span></div>' —— 标题未转义就直接拼入，XSS 风险；class 名和结构混在一起，难复用
- 推荐封装函数：
createStep({ title, status: 'active' }) 返回完整节点，内部用 document.createElement('li') + setAttribute('data-status', status)，状态交由 data 属性驱动
- 避免在循环中反复调用
appendChild；先建 DocumentFragment，一次性 append，性能更好
<iframe> 是页面级嵌套，不是组件级逻辑编排
有人把“组件嵌套”误解为用 <iframe> 加载另一个 HTML 文件。这是页面隔离方案，不是逻辑编排——<iframe> 内外 DOM 不互通，CSS 不继承，JS 不共享，无法响应父组件状态变化。
立即学习“前端免费学习笔记（深入）”；
-
<iframe src="widget.html"> 适合嵌入第三方内容（如地图、支付控件），不适合构建主应用内的可交互组件
- 若真需复用 HTML 片段，优先用 Web Components 的
<template> + JS 实例化，或服务端 SSI/模板引擎预编译
-
loading="lazy" 可加，但别指望它优化组件内部逻辑——它只影响资源加载时机，不影响结构语义
实际写的时候，最常被忽略的是：**语义标签不是装饰，是契约**。浏览器、辅助技术、甚至你半年后写的 JS 查询，都依赖这个契约。一旦用 <div> 替代 <nav> 或 <ol>，问题不会立刻报错，而是在某次无障碍测试、某次 SEO 抓取、某个新同事接手时突然暴露。
HTML 本身不提供“组件”概念，所谓“组件内部逻辑编套”，本质是用语义化嵌套表达内容关系。硬套 <div> 层层包裹，只会让结构松散、JS 选中不稳定、屏幕阅读器失效。
-
<main>必须全局唯一，不能嵌在<section>或<div>里——W3C 明确禁止，否则语义崩塌 - 导航区域写成
<nav><ul><li>...</li></ul></nav>，而不是<div class="nav"><ul>...</ul></div>；前者能被辅助工具识别为导航区，后者只是视觉分组 - 步骤条必须用
<ol>，不是<ul>或<div>：序号、aria-current="step"、counter-increment全依赖它 - 列表嵌套只允许在
<li>内部放<ul>或<ol>，跨层级或交叉闭合（如<ul><li><ol>...</ul></ol>）会触发解析错误
嵌套超过 3 层时，大概率是结构没想清，不是 CSS 没写好
常见现象：一个卡片组件写成 <div class="card"><div class="card__body"><div class="card__content"><p>...</p></div></div></div>。这不是“精细控制”，而是职责模糊、样式耦合、JS 难维护。
- 每层
<div>应有明确语义边界：比如<article>包正文，<header>包标题和元信息，<footer>包操作按钮——不是为了“看起来像”，是为了让浏览器和 JS 知道“这一块是什么” - 深层嵌套常伴随 class 名爆炸（
card__content__text__highlight），说明本该用更上层语义标签收束，而非靠 class 模拟结构 - 用 CSS Grid 嵌套比 DOM 嵌套更轻量：一个
<section>设为display: grid，其子元素再设display: grid即可实现“逻辑列下的多子列”，无需额外<div>
动态生成嵌套结构时，优先用 document.createElement 而非 innerHTML
当 JS 需构建带状态的组件（如步骤条、表单卡片），innerHTML 容易引入 XSS 风险且无法精准控制属性；document.createElement 虽稍冗长，但可控性强、语义清晰。
- 不要这样写：
el.innerHTML = '<div class="step"><span>' + title + '</span></div>'—— 标题未转义就直接拼入，XSS 风险；class 名和结构混在一起，难复用 - 推荐封装函数：
createStep({ title, status: 'active' })返回完整节点，内部用document.createElement('li')+setAttribute('data-status', status)，状态交由 data 属性驱动 - 避免在循环中反复调用
appendChild；先建 DocumentFragment，一次性 append，性能更好
<iframe> 是页面级嵌套，不是组件级逻辑编排
有人把“组件嵌套”误解为用 <iframe> 加载另一个 HTML 文件。这是页面隔离方案，不是逻辑编排——<iframe> 内外 DOM 不互通，CSS 不继承，JS 不共享，无法响应父组件状态变化。
立即学习“前端免费学习笔记（深入）”；
-
<iframe src="widget.html">适合嵌入第三方内容（如地图、支付控件），不适合构建主应用内的可交互组件 - 若真需复用 HTML 片段，优先用 Web Components 的
<template>+ JS 实例化，或服务端 SSI/模板引擎预编译 -
loading="lazy"可加，但别指望它优化组件内部逻辑——它只影响资源加载时机，不影响结构语义
<div> 替代 <nav> 或 <ol>，问题不会立刻报错，而是在某次无障碍测试、某次 SEO 抓取、某个新同事接手时突然暴露。
