语义化标签是页面结构底线，样式模块化须与HTML语义对齐；错用section/article/nav等破坏大纲与可访问性，BEM类名须绑定语义容器，样式应基于类名而非标签，避免语义与布局耦合。
直接说结论：语义化标签不是“锦上添花”，而是页面结构的底线；样式模块化不靠工具堆砌，而靠类名逻辑与HTML结构对齐。两者脱节时，CSS越写越难维护，HTML越写越像“带class的div”。
header/nav/main/section/article/aside/footer 怎么选不混乱
选错标签的典型表现是：用 section 包裹整个页面、把导航塞进 div、在 article 里嵌套另一个 main —— 这些都会破坏大纲层级和辅助技术识别。
-
header和footer是“区域级”容器，可出现在页面级或模块级（比如每个article自带自己的header） -
nav必须包裹**导航链接组**，不是所有菜单都算——面包屑、分页、筛选栏建议加aria-label="breadcrumb"后再用nav -
main全局只能有一个，且不能嵌套在article、aside或section内部 -
article要满足“可独立分发”：复制整块 HTML 到别处仍语义完整（如 RSS 订阅、分享卡片） -
section必须有主题，且应带标题（h2–h6），否则不如用div
BEM 命名怎么跟语义化 HTML 对上号
很多人写 .card__title 却把标题放在 div class="card"> 里，这就断了语义链——div 没语义，card__title 再规范也白搭。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 先定语义结构：
-
__element只用于该语义块内部子节点，不要跨块使用（比如.post__title不能用于侧边栏文章摘要的标题） - 修饰符
--modifier应反映真实状态：.btn--loading可以，.btn--blue不行（这是样式细节，不是语义变体） - 避免双重语义：不用
，因为article已是语义块，“card”只是视觉表现，应通过 CSS 实现
怎么避免“语义化了但样式还是乱成一锅粥”
常见陷阱是：HTML 用了 aside，CSS 却写 aside { float: right; width: 30%; }——这等于把布局逻辑硬编码进语义标签，后续换布局就得改 HTML。
- 样式层只响应类名，不响应语义标签：写
.sidebar而非aside的样式规则 - 用
display: contents可让语义标签不参与盒模型（适合仅需语义、不占布局的场景） - 构建工具中复用模块时，用
或组件化方案（如 Lit、HTMX 片段），但模板内部仍要保持语义结构，不能吐出一堆div - 检查可访问性：用浏览器开发者工具的“Accessibility”面板看是否生成了合理的大纲树，若
article下没h2或标题跳级，屏幕阅读器会困惑
最容易被忽略的一点：语义化不是“把 div 换成 header 就完事”，而是每次写标签前问一句——这个元素在内容逻辑里扮演什么角色？它能不能被单独抽取、被搜索引擎归类、被语音助手朗读成一段完整信息？样式模块化同理，类名不是为了好写，而是为了下次别人（或三个月后的你）一眼看懂“这块东西到底是什么”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
