直接在<li>内使用<strong>即可，它合法、语义正确且不破坏编号逻辑；错误写法是将<strong>包裹整个<li>，会导致DOM被浏览器修正而失效。
直接在 <li> 里用 <strong> 就行
HTML 有序列表的 <li> 是普通流内容容器，允许嵌入任何短语级元素，<strong> 完全合法且语义正确。不需要额外 wrapper、不用 JS、不破坏编号逻辑。
常见错误是试图把 <strong> 套在整条 <li> 外面（比如 <strong><li>...</li></strong>），这违反 HTML 结构规范，浏览器会自动修正为 <strong></strong><li>...</li>，导致加粗失效。
-
<li>这是正常文本，<strong>这是加粗部分</strong>，后面继续文本</li>✅ -
<li><strong>整条都加粗</strong></li>✅（语义上合理时可用） -
<strong><li>整条加粗（错误写法）</li></strong>❌ 浏览器会剥离并重排 DOM
<strong> 和 <b> 选哪个
优先用 <strong>：它表示「重要性」，屏幕阅读器会加重语气，SEO 更友好，CSS 默认就是加粗，所有现代浏览器支持无死角。
<b> 仅适用于纯视觉加粗、无语义强调的场景（比如关键词高亮、产品名样式化），但这类需求其实更适合用 class + CSS 控制。
立即学习“前端免费学习笔记（深入）”；
- 医疗指南里强调「Code only confirmed cases」——用
<strong> - 某段代码中显示
<b>E03.9</b>作为编码标识（非强调，仅样式）——<b>可接受，但<span class="code">更清晰 - 别为了“少打几个字母”用
<b>，语义债后期难还
加粗后样式异常？先看 computed styles
加了 <strong> 却没变粗，大概率不是标签问题，而是被 CSS 覆盖了：
- 父级设置了
font-weight: normal，会继承给子元素（<strong>默认font-weight: bold，但会被继承值压制） - 自定义字体未声明
font-weight: bold或700字重，导致 fallback 到普通字重 - CSS 中写了
strong { font-weight: normal !important; }这类强覆盖（查 DevTools 的 Styles 面板）
调试建议：打开浏览器开发者工具 → 选中加粗文字 → 看右侧面板的 Computed 标签页，确认 font-weight 实际值是不是 700 或 bold。
嵌套层级深时，<strong> 会不会影响编号连续性
完全不会。<strong> 是行内元素，对 <ol> 的计数器、嵌套结构、可访问性树都没有任何干扰。只要 <ol> 和 <li> 的嵌套关系合法（子 <ol> 在父 <li> 内部），编号就按预期递进。
真正容易出错的是结构本身：比如把子列表写成兄弟节点而非嵌套在 <li> 里，这时编号重置，但那和 <strong> 无关。
复杂点在于，多人协作时有人会下意识用 <p> 包裹列表项内容再塞 <strong>，结果破坏了 <li> 的语义容器角色——这种写法看着像加粗成功了，实则让屏幕阅读器无法识别列表结构。
