应配置白名单允许strong/b标签，统一编辑器输出为strong或b，检查CSS覆盖和字体字重，并按语义区分使用strong（表重要性）与b（纯视觉加粗）。
保存富文本时和被自动过滤或转义怎么办
后端或富文本编辑器常把 <strong> 和 <b> 当作潜在 XSS 风险直接删掉或转成 <strong></strong>。这不是 bug，是默认安全策略在起作用。
关键不是“怎么保留标签”，而是“让过滤器知道哪些标签是可信的”。常见做法是用白名单机制，比如：
- DOMPurify 配置中显式加入
ALLOWED_TAGS: ['strong', 'b'] - 后端模板（如 Django）用
|safe前，确保输入已过 HTML 清洗，且白名单包含strong和b - 若用服务端渲染（如 Next.js、Nuxt），别依赖
dangerouslySetInnerHTML直接塞原始 HTML，应先用库做净化
前端编辑器输出的被存成<b>或反过来，怎么统一
Quill、Tiptap、Slate 等编辑器底层调用 document.execCommand('bold')，而浏览器实现不一致：Chrome 默认插 <strong>，旧 Safari 可能插 <b>。你看到的“混用”其实是浏览器行为差异导致的。
保存前做一次归一化最稳妥：
立即学习“前端免费学习笔记（深入）”；
- 用正则批量替换：
html.replace(/<b>(.*?)<\/b>/gi, '<strong>$1</strong>')（注意：只在 DOM 解析前、字符串处理阶段用） - 如果语义明确该用
<b>（比如搜索高亮），就反向统一：html.replace(/<strong>(.*?)<\/strong>/gi, '<b>$1</b>') - 别在 React/Vue 的
v-html或dangerouslySetInnerHTML里再做替换——此时 HTML 已解析为 DOM，正则失效
保存后页面渲染时加粗失效，检查这三点
标签存在，但没变粗？大概率不是标签问题，而是样式层覆盖或字体限制。
- CSS 中写了
b, strong { font-weight: normal !important; }—— 检查全局样式表或 UI 框架重置规则 - 当前字体（如某些 Web Font）只提供 400 字重，
font-weight: 700会回退到 400，导致<strong>看不出变化；可用font-weight: bold强制触发浏览器映射 - 富文本内容被包裹在
contenteditable区域外又未设user-select: text，部分 iOS Safari 会抑制默认加粗渲染
要不要把和全替换成CSS类再保存
可以，但没必要一刀切。用类名（如 <span class="font-bold">）确实利于主题切换和 CSS-in-JS 管理，但代价是丢失语义。
真实项目里更合理的分层是：
- 业务逻辑强相关的加粗（价格、警告、操作按钮）→ 保留
<strong>，确保可访问性不降级 - 纯视觉装饰（产品名、关键词高亮、UI 文案）→ 用
<b>或class="text-emphasis"，但必须保证类名不带语义暗示（比如别叫text-important） - 完全动态生成的加粗（如搜索高亮）→ 后端/前端统一走
<b>，并禁用其在无障碍树中的暴露（aria-hidden="true"可选）
真正容易被忽略的是语义边界的模糊性：同一个“免费”字样，在 banner 上是营销话术（用 <b>），在协议条款里是法律义务（必须用 <strong>）。保存前不判断上下文，后期可访问性审计一定会报错。
