strong 表示语义重要性，b 仅控制视觉加粗；错误提示、必填项等必须用 strong，b 仅适用于无强调意图的纯样式加粗场景，如产品型号首次出现。
strong 表示内容重要性，b 只是加粗显示
浏览器默认都把 strong 和 b 渲染成粗体，但它们在 DOM 层面的语义完全不同：strong 告诉浏览器、屏幕阅读器、搜索引擎“这段文字逻辑上很重要”，b 只说“请把它视觉上加粗”，不附带任何语气或权重含义。
错误提示、必填项、安全警告必须用 strong
常见错误现象是把表单错误信息写成 <b>邮箱格式不正确</b>，结果屏幕阅读器平读过去，用户完全感知不到风险。这类内容实际需要：
-
strong触发读屏器加重音或短暂停顿 - 搜索引擎可能将其包裹关键词识别为页面高优先级信号（但整段都包会被判堆砌）
- WCAG 2.1 AA 合规检查会直接报出
b在错误提示中的使用问题
纯样式加粗才考虑 b，但更推荐用 CSS
b 的合法使用场景非常窄，比如文章导语里首次出现的产品型号 <b>iPhone 16 Pro</b>，或古籍排版中需加粗但无强调意图的专有名词。但要注意：
- CMS 富文本编辑器点“加粗”按钮，后台常默认输出
b，需确认能否配置为strong或加后处理替换 - 现代实践中，纯视觉加粗更推荐用
class="highlight"+ CSS 控制，而非依赖b - 给
b设置font-weight: normal是自相矛盾的指令，而strong { font-weight: normal }完全合理——语义仍在
嵌套和工具识别行为完全不同
strong 允许有意义的嵌套：<strong>删除<strong>后不可恢复</strong></strong> 中内层表示更强的风险等级；而 <b>A <b>B</b> C</b> 只是两层无意义的加粗。更重要的是：
立即学习“前端免费学习笔记（深入）”；
- JavaScript 检测
el.tagName === 'STRONG'能精准筛选语义重点节点 -
b在 Shadow DOM 或自动化可访问性扫描工具中大概率被忽略 - 团队代码审查时，
b出现在权限说明、API 参数文档里，基本等于语义误用
strong 还是 b。 
