优先使用，因其具语义重要性；仅用于无语义视觉加粗，如产品名、术语等。两者不可混用，须兼顾可访问性与SEO。
<b> 标签确实能让文字变粗，但它只做一件事：改变外观。它不告诉浏览器、搜索引擎或屏幕阅读器“这段文字重要”，只是说“请把它画得粗一点”。如果你的目标仅仅是视觉加粗，且明确不需要语义，那 <b> 可以用，但得清楚它在哪该用、在哪不该碰。
什么时候该用 <b> 而不是 <strong>
核心判断标准是：这段加粗文字是否承担逻辑权重？
- 产品名、品牌词、文章摘要里的重复关键词（如“
<b>React</b> 生态”、“<code><b>API</b> 设计原则”）——<code><b>合适，因为它们是识别性标记，不是警告或关键操作 - 菜单项中的状态标签（如“
<b>New</b>”、“<code><b>Beta</b>”）——视觉提示，无语义必要性</li> <li>纯排版需求，比如某段说明中需要突出一个术语，但上下文已足够传达其重要性（例如技术文档里第一次出现的缩写）</li> <li>反例：登录失败提示写成 <code><b>密码错误</b>
—— 屏幕阅读器不会加重语气，用户可能跳过；法律条款中“<b>免责条款</b>”—— 搜索引擎无法识别其权重，SEO 损失
<b> 的常见误用现象
这些不是样式问题，而是语义错位引发的实际后果：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 整段标题套
<b>，比如<h2><b>用户协议</b></h2>——<h2>本身已有语义层级，再加<b>是冗余，且干扰读屏节奏 - 按钮文字用
<b>包裹，如<button><b>提交订单</b></button>—— 按钮本身已是交互焦点，加粗无额外信息价值，反而让辅助技术多解析一层无意义标签 - 和
<strong>混用又不区分意图，比如<strong>请</strong>确认<b>邮箱地址</b>—— 语义断裂，“请”强调动作，“邮箱地址”却只视觉突出，逻辑不连贯
CSS 替代方案比 <b> 更灵活的场景
当加粗只是设计系统的一部分，而非内容意图表达时，CSS 更可控、更易维护：
- 需要统一控制粗细程度（如全部设为
font-weight: 600，而非默认的bold） - 响应式加粗：小屏下取消加粗以提升可读性，用媒体查询控制
font-weight - 与颜色、背景等其他视觉属性联动（如加粗 + 红色 = 错误状态），此时语义应由 class 承载，而非标签
-
<b>无法设置字体粗细梯度（如font-weight: 300到900），而 CSS 支持完整数值体系
嵌套 <b> 或混用 <b> 和 <strong> 会怎样
浏览器不会让文字变得更粗——多重 <b> 渲染效果和单层一样；但语义混乱风险真实存在：
-
<b>价格</b>含<b>税</b>没问题；但<b>¥</b><b>99.00</b>拆开包裹，既无必要，也增加 DOM 节点负担 -
<strong>限时</strong><b>优惠</b>：前半强调紧迫性，后半仅视觉提示，意图尚可区分；但若反过来写成<b>限时</b><strong>优惠</strong>，就本末倒置了 - HTML5 明确不鼓励用嵌套标签“增强语气”，真正需要多级视觉强度时，应该用 class（如
class="highlight critical"）配合 CSS 控制，而不是靠标签堆叠
最容易被忽略的一点是：<b> 不是“弱化版 <strong>”，它是另一条路——走纯样式路径就得彻底交出语义控制权，别一边用 <b>，一边指望读屏软件或 SEO 工具理解你的重点。
