必须用<strong>标签时是语义强调而非单纯加粗，如警告文案、关键数据、表单必填项；<b>仅用于无语义的纯视觉加粗；font-weight应优先用700且需字体支持。
加粗不是排版问题，是语义+样式协同结果；直接用 <strong> 最省事也最稳妥，但得清楚它什么时候该出现、什么时候不该出现。
什么时候必须用 <strong> 标签
它不是“加粗开关”，而是告诉浏览器和屏幕阅读器：“这段内容删掉会影响理解或引发后果”。
- 警告类文案：
<strong>此操作不可撤销</strong>—— 读屏软件会加重朗读，用户不会跳过 - 关键数据：
<strong>API_KEY</strong>或<strong>¥199.00</strong>—— SEO 工具会识别为高权重文本 - 表单必填提示：
<label><strong>邮箱地址</strong>（必填）</label>—— 辅助技术可关联到输入框 - 别把它塞进
<p>里再套<div>，<strong>只能包裹行内内容，否则 HTML 校验失败、可访问性降级
font-weight 数值写多少才真加粗
写了 font-weight: 700 却没变粗？大概率是字体本身不支持——不是代码错了，是字重缺失。
- 绝大多数中文字体只提供
400（normal）和700（bold）两档，写600或800会 fallback 到最近可用值 -
font-weight: bold和font-weight: 700等价，优先用后者，更明确 - 避免
font-weight: bolder—— 它依赖父元素计算，嵌套三层后可能变成normal，行为不可控 - 用自定义字体时，
@font-face必须显式声明font-weight: 700对应的文件，漏了就回退成细体
为什么 <b> 还存在，但你几乎不该用
<b> 在 HTML5 里没被废弃，只是被重新定义为“无语义的视觉加粗”——适用场景极窄。
立即学习“前端免费学习笔记（深入）”；
- 词典条目中的词条名：
<b>apple</b>: a fruit... - 小说中角色首次出场：
<b>Sherlock Holmes</b> entered the room... - 纯装饰性加粗，且无法通过 CSS 实现（比如某些富文本编辑器导出限制）
- 别用它替代
<strong>来“规避样式加载失败”，现代项目已不需这种降级逻辑 - React/Vue 组件里硬编码
<b>，后期统一语义化改造成本远高于初期选对标签
真正卡住人的从来不是怎么写 <strong>，而是判断“这段文字到底重不重要”——比如“限时抢购”四个字，是促销氛围的一部分，还是独立的关键动作提示？这个边界没标准答案，得看上下文和用户预期。
