必须用<strong>而非<b>当文字承载不可省略的重要性，如表单错误提示、操作风险警告、API必填字段、关键数据等；<b>仅限纯视觉加粗且无语义需求的极少数场景。
该用 <strong> 时别碰 <b>，除非你明确只需要视觉加粗且不关心语义、SEO 和读屏体验。
什么时候必须用 <strong> 而不是 <b>
核心判断标准是：这段文字是否承载「不可省略的重要性」？
- 表单校验失败提示里的关键词，比如
<strong>邮箱格式错误</strong>—— 屏幕阅读器会加重语气，用户能立刻感知风险 - 操作确认弹窗中的后果描述，如
<strong>删除后不可恢复</strong>—— 搜索引擎识别为高权重内容，WCAG 测试也认这个语义 - API 文档中标记必填字段：
<strong>user_id</strong>（必填）—— 不仅人眼看到加粗，自动化文档解析工具也能提取约束信息 - 后台系统中金额、权限级别等关键数据，例如
<strong>¥12,800.00</strong>—— 可访问性测试项直接检查这类节点是否用了<strong>
哪些场景 <b> 还算合理（但仍有更好替代）
<b> 的合法存在空间极小，HTML5 规范里它被降级为“纯样式用途”，且已明确建议优先用 CSS 替代。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 品牌名首次出现（如段落中第一次提
<b>React</b>），但更推荐用font-weight: 600+ class 控制，避免语义污染 - 代码块内需要突出某个无语义的符号或缩写（比如
<pre>git <b>commit</b> -m "fix"</pre>），此时<strong>反而误导——它暗示“这个命令很重要”，其实只是想让它显眼 - 富文本编辑器导出的 HTML 中保留原始加粗样式（无结构意图），但上线前应通过 DOMPurify 过滤，而非直接信任
<b>
CSS font-weight 替代方案的实操要点
现代项目里，90% 的加粗需求其实不该靠标签解决。
立即学习“前端免费学习笔记（深入）”；
- 全局重置了
font-weight: 400？那<strong>默认就失效了——得补一句strong { font-weight: 600; }，不能依赖 UA 样式 - 别用
font-weight: bolder，它依赖父元素字重计算，嵌套深了容易失控（比如父是 500，子设 bolder → 600；再下一层又 bolder → 700；但若父是 400，结果可能还是 400） - Design Token 管理项目中，确保
strong映射到font-weight-emphasistoken，而不是随手配成font-weight-heading - React/Vue 中动态渲染
<strong>{msg}</strong>前，务必检查msg是否为空或 null，否则 SSR 下可能生成空标签，破坏 DOM 结构
最容易被忽略的兼容性陷阱
不是浏览器兼容问题，而是辅助技术链路断裂。
- 用了
<b>包裹错误提示，NVDA 或 VoiceOver 完全不作停顿或变调——用户听不出这是警告，只当普通文本扫过 - 团队统一用 CSS 控制所有加粗，却忘了给
<strong>单独声明字重，导致无障碍测试报告里标红：“语义强调节点未呈现视觉反馈” - 在
<code>块里嵌<strong>强调变量名（如const <strong>token</strong> = get();），这没问题；但若用<b>，某些语法高亮库会把它当非法 HTML 处理，直接过滤掉
