摘要指摘录文献要点或内容提要，含目的、方法、结果、结论四要素，适用于学术论文等，按功能分报道性、指示性及报道-指示性三类，字数通常100–300字，要求客观、概括、独立。
别用 b 替代 strong，除非你明确只需要视觉加粗且不传递任何语义。 两者默认都出粗体，但浏览器、屏幕阅读器、搜索引擎和后续维护逻辑全按“有没有语义”来区分对待。
什么时候必须用 strong
当内容在信息结构中具有不可忽略的权重时——比如表单错误提示里的“邮箱格式不正确”，法律条款中的“免责”，或安全警告中的“此操作不可撤销”。
- 屏幕阅读器会重读
strong内容，甚至插入停顿，辅助用户快速识别关键信息 - 搜索引擎可能将其包裹的文本视为页面内更高优先级的关键词信号（但整段都包会被判为堆砌）
- CSS 可以安全地覆盖其样式（比如改成红色+下划线），语义依然有效
- JavaScript 中用
el.tagName === 'STRONG'能精准筛选出语义重点节点
什么时候才该用 b
纯样式需求，且内容本身不带强调意图：比如文章导语里产品型号“iPhone 16 Pro”，古籍排版中需加粗但无语气变化的专有名词，或 CMS 富文本编辑器里用户点“加粗”但你确定它不该被读屏器特殊处理。
-
b是 HTML5 明确定义的“无语义加粗”，不是过时标签，而是有明确使用边界的工具 - 它不触发屏幕阅读器的语音加重，也不向搜索引擎发送权重信号
- 如果你给
b设置font-weight: normal，等于写了一句自相矛盾的指令 - 很多 CMS 默认输出
b，若项目有无障碍合规要求，得检查能否配置为strong，或加后处理替换
strong 和 b 的 CSS 行为差异
它们都能被 CSS 改样式，但意图完全不同：
立即学习“前端免费学习笔记（深入）”；
- 写
strong { color: #d32f2f; }合理——你在强化“重要性”的视觉表达 - 写
b { font-weight: 600; }更常见——你只是统一调整所有纯样式加粗的粗细 - 全局禁用加粗（
* { font-weight: normal !important; }）会让两者都失效，但strong的语义仍保留在 DOM 中 - 用 class 统一管理强调样式比依赖
strong的默认行为更可控，也避免语义与样式耦合过深
容易被忽略的实际影响点
真正卡住人的往往不是“该用哪个”，而是团队协作和系统集成时的隐性假设：
- 富文本编辑器点“加粗”按钮，后台存的是
b还是strong？没确认过就上线，无障碍测试大概率报错 - SEO 团队要求核心关键词用
strong包裹，但前端组件库里封装的“高亮文案”组件默认用b，结果白忙一场 - 用 JS 动态插入提示文案时，手快写了
el.innerHTML = '<b>请填写</b>'，而实际需要的是语义可访问的强调 - 把
strong当成“加粗开关”滥用，比如整段说明文字都包进去，反而稀释了真正关键信息的语义密度
