结论：用于语义强调，仅作纯视觉加粗；两者渲染相同，但可访问性、SEO和工具解析差异显著，富文本中应优先使用并确保安全过滤与正确渲染。
HTML富文本里怎么用<strong></strong>和<b></b>加粗
直接说结论：在HTML富文本中，<strong></strong>是语义化加粗，<b></b>是纯样式加粗。浏览器渲染效果一样，但编辑器、可访问性工具、SEO解析会区别对待——别图省事全用<b></b>。
常见错误是把富文本内容直接拼接<b>xxx</b>后塞进innerHTML，结果被XSS过滤或解析失败。实际要用时得看上下文：
- 用户输入后由前端富文本编辑器（如Quill、Tiptap）生成的HTML，它默认用
<strong></strong>，你只需确保输出不被二次转义 - 后端返回的富文本HTML字符串，必须确认是否已做过安全过滤（比如用DOMPurify白名单允许
<strong></strong>，但禁掉<script></script>） - 手动构造富文本片段（比如日志高亮），优先用
<strong></strong>，避免用<b></b>——后者在某些无障碍阅读器中不会读作“重要”
富文本编辑器里触发加粗的底层命令是document.execCommand('bold')
这个API虽然已被标记为废弃（MDN写的是“deprecated but still widely supported”），但至今仍是大多数轻量级富文本工具的底层实现。它不直接插入标签，而是根据当前选区自动包裹<strong></strong>或<b></b>，具体用哪个取决于浏览器默认行为（Chrome/Edge用<strong></strong>，旧版Safari可能用<b></b>）。
实操注意点：
- 调用前必须确保编辑区域有焦点，且
contenteditable="true"属性生效 - 不要在React/Vue等框架的受控组件里混用——它会绕过虚拟DOM，导致状态错乱
- 如果需要统一输出格式，建议监听
input事件后，用正则把<b></b>批量替换成<strong></strong>：html.replace(/<b>(.*?)/gi, '<strong>$1</strong>')</b>
用CSS的font-weight模拟加粗，但不是真正的富文本加粗
有人想绕开HTML标签，直接用style="font-weight: bold"或CSS类。这能改变视觉，但破坏了富文本的结构语义——复制粘贴到其他编辑器、导出为Markdown、屏幕阅读器识别都会出问题。
典型误用场景：
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 给整个
<div contenteditable>设<code>font-weight: bold，结果所有文字都粗，无法局部加粗 - 用
span套font-weight做“伪加粗”，但富文本编辑器无法识别该格式，撤销/重做时容易丢失 - 服务端渲染时硬编码
style，导致前端编辑器初始化失败（因为编辑器依赖标签结构解析格式） - 检查后端是否对HTML做了
htmlspecialchars（PHP）或escape（Node.js模板引擎）——如果是，得明确区分“富文本字段”和“普通文本字段”，对前者跳过转义 - 查看富文本字段在数据库里存的是原始HTML还是JSON结构（如ProseMirror的JSON schema），别用
TEXT类型硬存带标签的字符串却没配好ORM的escape策略 - 前端渲染时，别用
textContent，必须用innerHTML；但要用DOMPurify.sanitize()先清洗，白名单里加上strong、b、em等基础格式标签
真要兼容性兜底，不如用<strong></strong> + CSS微调：strong { font-weight: 700; }，既保留语义又可控。
后端存储和渲染时，<strong></strong>被过滤或显示为明文怎么办
这是高频踩坑点：前端发过去<strong>你好</strong>，后端存进数据库，再渲染时变成纯文本<strong>你好</strong>，或者干脆被WAF拦截。
关键判断链路：
最常被忽略的是：富文本字段在API响应里被JSON序列化时，双引号没转义，导致"content": "<strong>test</strong>"变成非法JSON——得确保后端正确处理特殊字符，或前端用DOMParser解析字符串而非直接插HTML。
