表单错误提示必须用strong而非b，因strong触发屏幕阅读器加重朗读和停顿、支持wcag 1.3.1合规，b仅视觉加粗且无语义，易致无障碍失败。
表单错误提示必须用 strong，不能用 b
屏幕阅读器（如 NVDA、VoiceOver）对 strong 会加重朗读并插入停顿，b 则完全被平读——用户可能根本听不出这是错误反馈。WCAG 1.3.1 合规性检查会直接失败。
- 动态插入提示时别手快写
el.innerHTML = '<b>邮箱格式不正确</b>'，应改为<strong></strong> - 富文本编辑器默认“加粗”输出
b，上线前必须拦截替换或配置为输出strong - 整段校验文案都套
strong反而稀释语义，只包裹真正需用户立即注意的部分，例如：<strong>邮箱格式不正确</strong>，而非整个句子
strong 在 API 文档和法律文本中是必需语义标记
搜索引擎和自动化文档解析工具依赖 strong 识别关键字段；b 在 DOM 中不可见，提取脚本无法捕获其内容。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 标记必填参数：
<strong>user_id</strong>（字符串，必需） - 法律主体或责任条款：
<strong>甲方</strong> 应承担违约责任 - 关键金额：
<strong>¥12,800.00</strong>—— 屏幕阅读器会提升音调，辅助用户确认数值 - 嵌套需克制：
<strong>删除<strong>后不可恢复</strong></strong>可接受（内层强调后果），但<strong><strong>危险</strong></strong>是冗余，无叠加效果
CSS 覆盖 strong 时常见误判
全局设了 font-weight: 400 后 strong 看起来没加粗，不是标签失效，而是 UA 默认样式被覆盖。语义仍在 DOM 中，只是视觉锚点丢失。
- 稳妥做法是显式声明：
strong { font-weight: 600; }，避免依赖浏览器默认值 - 别写
strong { font-weight: inherit; }—— 这等于主动放弃语义对应的视觉提示 - 若项目用 Design Token，确保
strong映射到font-weight-emphasis，而非随意指派为 heading 字重 - 给
b设font-weight: normal是自相矛盾；而strong { font-weight: normal; }完全合理，语义仍完整
什么场景下 b 理论上可用，但几乎总该换 CSS
b 在 HTML5 中明确定义为“无语义的视觉加粗”，合法使用极窄：比如 <pre class="brush:php;toolbar:false;">git <b>commit</b> -m "fix"</pre> 中突出命令词，且确认该词无需语义强调。
- 产品型号首次出现（如段落中第一次提
<b>iPhone 16 Pro</b>）—— 更推荐用class="product-name"+ CSS - CMS 或低代码平台若“加粗”按钮默认输出
b，且项目有无障碍要求，必须确认能否配置或拦截替换 -
b在 Shadow DOM 或自动化文档解析中基本不可见，API 提取脚本不会识别它包裹的内容为关键字段
strong 的语义，往往在测试阶段才暴露，但修复成本远高于编码时多敲几个字符。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
