子列表必须嵌套在 li 内部，否则语义断裂、编号重置、屏幕阅读器无法识别层级；正确结构为 ol → li → 内层 ol/ul，错误结构是 ol 并列书写；type 属性仅控制单层样式，多级连续编号需 CSS counter 实现。
子列表必须写在 li 里面，否则不生效
浏览器只认「ol 或 ul 在 li 内部」这种结构。直接把两个 ol 并列写，哪怕视觉上像层级，实际是两个独立列表，编号重置、语义断裂、屏幕阅读器也读不出嵌套关系。
常见错误现象：ol 里第二项显示为 A. 而不是 B.；ul 嵌套后子项没缩进或错位；用开发者工具检查发现子列表不在任何 li 的 DOM 子树中。
- 正确结构：外层
ol→li→ 内层ul（或另一个ol） - 错误结构：
ol→li→ 文本；然后另起一个ol放在父ol外面 - 验证方法：选中子列表，在 Elements 面板里往上找，必须能一路回溯到某个
li，再回到父ol或ul
list-style-type 只控制本层，跨层编号要靠 CSS 计数器
用 type="A" 或 style="list-style-type: lower-roman" 只影响当前 ol，子 ol 默认从 1 或 a 重新开始，不会继承父级序号。想实现「A. → 1. → a.」连续编号，必须用 CSS counter-reset 和 counter-increment。
性能与兼容性提示：现代浏览器（Chrome/Firefox/Safari/Edge）对 counter- 系列支持完整；IE10 及以下不支持，若需兼容旧环境，得用 JS 模拟或降级为静态文本。
- 基础写法：
ol { counter-reset: section; } ol li { counter-increment: section; } ol li::before { content: counters(section, ".") ". "; } - 每层用不同 counter 名（如
section、subsection、subsubsection），避免互相干扰 - 别依赖
type属性做多级编号——它只是单层快捷方式，无法跨层联动
缩进异常不是 HTML 错，是 padding-left 累加导致的
浏览器给每个 ul 和 ol 默认设了 padding-left: 40px（具体值因 UA 样式略有差异）。嵌套一层就加一次，两层就是 80px，三层 120px……看起来越来越歪，其实只是盒模型叠加。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
容易踩的坑：text-indent 对列表项完全无效；全局重置 ul, ol { padding-left: 0; } 会破坏所有列表默认对齐；用了 normalize.css 后发现缩进变小，是因为它已重设过 padding。
- 推荐做法：统一设
ul, ol { padding-left: 2rem; }，再用ol ol, ul ul { margin-left: 0; padding-left: 1.5rem; }微调 - 如果项目已用 CSS Reset，先查它对
ul/ol的padding设置，再决定是否覆盖 - 调试时打开开发者工具，直接 hover 查看 computed styles 里的
padding-left值，比猜快得多
dl 不参与常规嵌套，别硬塞进 li
dl 是定义列表，结构是 dt + dd，和 ul/ol 的 li 语义不同源。W3C 允许 dl 作为 li 的子元素，但实际中极少需要，且多数 UI 框架、CSS 重置库、屏幕阅读器对这种混用支持不一致。
真实使用场景有限：只有当某条列表项需要展开一组「术语+解释」时才考虑，比如文档目录中某章标题下跟多个定义。其他情况——尤其是导航、步骤、分类——一律用 ul/ol 嵌套更稳妥。
- 不要写：
li > dl > dt > ul这种嵌套链，既难维护，又增加无障碍复杂度 - 若真要用，确保每个
dt后紧跟至少一个dd，否则语义残缺 - 注意：部分旧版 JAWS 对
dl在li中的播报顺序不稳定，测试时务必用真实读屏软件验证
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
