Bootstrap不强制语义化，依赖class控制样式与行为；Semantic UI倾向语义化标签但class仍主导；二者均不自动生成aria属性，需手动补充；React/Vue项目中应优先通过组件封装保障语义，而非框架选型。
Bootstrap 不强制语义化，靠 class 做样式和行为
Bootstrap 的设计哲学是“样式优先”，div 用得理直气壮。它不关心你用不用 nav、article 或 section，所有组件都通过 class 控制外观和交互。比如一个导航栏，Bootstrap 官方示例里写的是：
<div class="navbar"></div>，而不是
<nav class="navbar"></nav>。这本身不违法，但会削弱 HTML 的结构表达力。
常见错误现象：
• 把 div 套满整个页面，全靠 class="container"、class="row" 维持布局
• 屏幕阅读器无法从标签本身推断内容类型（比如分不清哪块是主导航、哪块是侧边栏）
• SEO 工具抓取时丢失语义层级
实操建议：
• 手动把 Bootstrap 的 div 替换为语义化标签：用 nav 包 .navbar，用 main 包 .container，用 aside 包 .col-md-3 侧边栏
• 不依赖 Bootstrap 的 JS 插件自动识别结构（它基本不识别）
• 注意某些组件（如 modal）的 DOM 结构较深，替换外层标签时别破坏 data-bs-* 属性的生效位置
Semantic UI 默认用语义化标签，但 class 名仍占主导
Semantic UI 在文档和源码中更倾向使用 nav、header、button 等原生标签——不是为了“教人写语义 HTML”，而是因为它的 class 命名本身就基于语义（ui button、ui menu、ui segment）。但它并不阻止你写 <div class="ui button">，只是官方示例几乎都用 button 标签。
使用场景：
• 需要快速构建有基础可访问性的界面（比如内部管理后台）
• 团队对 HTML5 标签已有共识，不想额外加抽象层
• 和 React/Vue 等框架搭配时，组件封装常保留语义标签，比 Bootstrap 更自然
实操建议：
• 直接用 button 写按钮，别用 div + ui button；否则键盘 Enter / Space 触发不了点击
• menu 应该包在 nav 里，否则 role="navigation" 不会被自动注入（Semantic UI 的 JS 不补这个）
• 注意 ui input 是个 div，但推荐套一层 form 或 label 来补语义缺失
无障碍支持差异：class 不能代替 role 和 aria-* 属性
两者都不自动生成 aria- 属性或修正角色（role）。比如 Bootstrap 的 dropdown 默认没有 role="menu"，Semantic UI 的 ui modal 也不会自动加 role="dialog" 和 aria-modal="true"。光靠语义化标签远远不够。
容易踩的坑：
• 认为用了 nav 就等于满足 WCAG 2.1 的导航要求（其实还要 aria-label 或 aria-labelledby）
• 模态框没锁住焦点，键盘用户能 tab 出去
• ui accordion 展开/折叠状态没同步到 aria-expanded
实操建议：
• 手动补关键 aria- 属性：模态框加 aria-modal="true"、下拉菜单加 role="menu"、选项卡加 role="tablist"
• 使用 focus-trap 类库控制模态框焦点，不要只信框架自带 JS
• 测试时关掉样式，用屏幕阅读器读一遍 DOM 结构，看是否能听出层级和功能
React/Vue 项目里怎么选：看团队对语义的容忍度
在组件化环境里，语义化更多取决于你怎么封装，而不是框架本身。但 Semantic UI 的 class 命名（ui button primary）天然比 Bootstrap 的（btn btn-primary）更贴近自然语言，也更容易映射到组件 props。
性能与兼容性影响：
• Semantic UI 的 CSS 文件更大（约 500KB 未压缩），且部分选择器嵌套过深（如 .ui.menu .item .text），CSSOM 构建稍慢
• Bootstrap 5 移除了 jQuery 依赖，但它的 class 命名抽象度高，反而让语义意图更模糊（btn-outline-success 是按钮？还是状态提示？）
• 两者都不支持 CSS :has() 等新特性做语义驱动样式，仍需 JS 辅助
实操建议：
• 如果项目已用 Bootstrap，别为了语义强行迁移到 Semantic UI；改用 asChild 或 as="nav"（在 Radix UI 或 Headless UI 中）更实际
• 若从零开始且重视可访问性，Semantic UI 的命名习惯会降低新人误用概率
• 无论选谁，都要配一套 lint 规则（如 eslint-plugin-jsx-a11y），检查 div 是否被滥用、button 是否缺 type 属性
真正难的不是选哪个框架，而是每次写 div 之前，多问一句：这里有没有更贴切的语义标签？框架不会替你决定，它只提供 class。
