应使用 而非 实现语义化强调，因 传达逻辑重要性，支持可访问性、SEO 和辅助技术，而 仅保留视觉加粗且语义缺失。

为什么不是“加粗就完事”的快捷键

很多人把 当成排版快捷键，点一下富文本编辑器的「B」按钮就输出 ，结果整页都是视觉加粗但语义全无。它确实会让文字变粗，但浏览器、屏幕阅读器、搜索引擎看到的只是一个「没意义的粗体」—— 不会改变语音语调，不提升 SEO 权重，也不参与可访问性树的结构构建。

常见错误现象： 被塞进表单标签（如 用户名）、错误提示（

不能为空

）、甚至整段说明文字。这些地方真正需要的是语义强调，而不是纯样式。

• 的合法用途极窄：产品名首次出现（iPhone 15）、技术术语（JSON）、字典条目中的词头
• 它不触发任何辅助技术行为，NVDA 或 VoiceOver 读到 内容时，音调、节奏、停顿完全不变
• CSS 失效时， 还能保底显示为粗体；但若你本意是强调，这层“保底”毫无信息价值

什么时候该用而不是

用 的唯一判断标准是：这段文字是否在逻辑或信息层级上必须被用户（尤其是依赖辅助技术的用户）识别为「重要内容」？不是“看起来重要”，而是“确实重要”。

典型使用场景：

• 表单校验失败时的关键字段名：

  请确认 邮箱地址 格式正确

  （只包字段，不包整句）
• 高风险操作警告：

  点击 删除 将永久移除所有数据

• 法律条款中的责任限定词：

  本公司 不承担间接损失 责任

  

  htmlppt.skill

  把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。

  下载

嵌套 没有意义——双重强调 不会让屏幕阅读器读两遍，也不会让字体更粗，反而可能干扰解析。

font-weight: bold 和 标签根本不是一回事

CSS 的 font-weight 是纯样式控制，而 是一个 HTML 元素。两者目标不同，不能互相替代，也不该混用。

容易踩的坑：

• 全局重置了 * { font-weight: 400; }，结果所有 看起来没加粗，于是开发者手动给每个 加 style="font-weight: bold"——这属于用样式补语义缺陷
• 写 b { font-weight: 700; } 合理，但写 strong { font-weight: normal; } 虽然技术可行，却等于主动放弃语义对应的视觉反馈，违背设计初衷
• 用 包裹变量名（如 user）不如用 user，因变量名在代码上下文中具有明确角色语义

CMS 或编辑器默认输出是个隐患

多数富文本编辑器（包括 WordPress 默认编辑器、TinyMCE、Quill）点「加粗」按钮，后台默认生成 。这不是 bug，是历史兼容性妥协。但如果你的页面需通过 WCAG 2.1 AA 认证，或要适配企业级 SEO 规范，这就成了真实风险点。

实操建议：

• 检查 CMS 富文本配置项，看是否支持将「加粗」映射为 （WordPress 可通过 tiny_mce_before_init 钩子修改）
• 服务端渲染前做一次正则替换：(.+?) → $1，但注意避开已有的 或
  块
• 前端 JS 注入方案风险高，不推荐；SSR 或构建时处理更稳妥

真正容易被忽略的是：加粗只是信息分层的第一步。一段文字是否加粗，和它是否配色、是否有图标、是否在焦点顺序中可抵达、是否在暗色模式下仍清晰——这些从来不是单靠选对 或 就能解决的。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！