该用 而不是 时：强调内容强重要性（如警告、必填字段、关键参数），以支持可访问性与语义化； 仅用于纯视觉加粗且无语义需求的场景（如品牌名首次出现）。
什么时候该用 <strong></strong> 而不是 <b></b>
浏览器渲染效果几乎一样，但语义完全不同：<strong></strong> 表示内容有强重要性（比如警告、关键参数），<b></b> 只是视觉加粗，不带任何语义权重。搜索引擎、读屏软件、自动化工具都依赖这个区别。
常见错误现象：用 <b></b> 包裹错误提示文字，结果屏幕阅读器不加重语气；或在 API 文档里用 <b></b> 标记必填字段，导致无障碍测试失败。
- 表单校验失败提示 → 用
<strong></strong> - 品牌名、产品名首次出现（纯样式需求）→ 可用
<b></b> - 代码块内需要加粗某个变量名（如
const <strong>user</strong> = ...）→ 用<strong></strong>更合理，因它强调语义角色，而非单纯字体变化
<strong></strong> 在可访问性（a11y）中的实际影响
读屏软件（如 NVDA、VoiceOver）默认对 <strong></strong> 提高音调或稍作停顿，而 <b></b> 完全被忽略。这不是“听起来更重”，而是传达结构意图。
使用场景：后台管理系统的操作风险提示（如“删除后不可恢复”）、支付页的金额数字、权限变更弹窗里的关键词。
- 若页面需通过 WCAG 2.1 AA 级认证，
<strong></strong>是推荐方式；<b></b>不违规，但放弃语义增强机会 - 不要嵌套
<strong></strong>来“加大力度”——多次嵌套不会叠加语义，反而可能干扰辅助技术解析 - CSS 中可通过
font-weight单独控制粗细，无需靠标签堆叠
CSS 覆盖 <strong></strong> 默认样式的注意事项
浏览器默认给 <strong></strong> 设了 font-weight: bold，但如果你重置了全局 font-weight（比如设为 400），它就失效了——这不是 bug，是 CSS 层叠规则生效。
容易踩的坑：团队统一用了 font-weight: 400 基础样式，结果所有 <strong></strong> 看起来没加粗，误以为标签失效，转而乱加 !important 或换回 <b></b>。
- 稳妥做法：显式重定义
strong { font-weight: 600; }，避免依赖 UA 默认值 - 别用
strong { font-weight: inherit; }—— 这等于主动放弃语义对应的视觉反馈 - 若项目用 Design Token 管理字重，确保
strong映射到 token 中的 “emphasis” 层级，而非随意指派
React/Vue 等框架中动态生成 <strong></strong> 的边界问题
JSX 或模板语法里写 <strong>{value}</strong> 很自然，但当 value 是空字符串、null 或 undefined 时，某些框架会渲染空标签甚至报错（尤其搭配 SSR 或严格类型检查）。
性能影响不大，但逻辑断裂会导致 DOM 结构意外缺失，进而让依赖父元素样式的 CSS 失效。
- React 中建议：
{value && <strong>{value}</strong>}或用三元判断兜底 - Vue 模板里避免直接插值：
<strong v-if="value">{{ value }}</strong> - 服务端渲染时，若
value异步加载中，先占位再替换比留空<strong></strong>更稳妥
<strong></strong> 和后台弹窗里的 <strong></strong>，语义强度是否匹配，这得靠人判断，没法靠规则自动对齐。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
