ol嵌套必须写在li内，否则编号重置；type属性仅控制当前层样式，需显式声明；start仅对外层生效；缩进失效多因css干扰。
ol 嵌套必须写在 li 里面，否则编号重置
浏览器把每个 <ol></ol> 当作独立计数器，只要子 <ol></ol> 没包在父级 <li> 里，就会从头开始编号（比如 A. → A. 而不是 A. → B.）。这不是 bug，是规范行为。
常见错误现象：第二级列表始终显示为 “A.” 或 “1.”，不管前面有多少项；屏幕阅读器播报时跳过层级关系。
- 子
<ol></ol>必须是某个<li>的直接子元素，不能放在 外面，也不能塞进 - 用浏览器开发者工具选中子
<ol></ol>，往上查父节点，确认它的父节点确实是<li>，而不是<ol></ol>或 - 第一级：
<ol type="A"></ol> - 第二级：
<ol type="1"></ol>（必须放在某条<li>内部） - 第三级：
<ol type="a"></ol> - 第四级：
<ol type="i"></ol> - 注意：
type="I"（大写罗马）和type="i"（小写罗马）效果不同，别写反 - 外层用
start="34"，第三条<li>里嵌子<ol></ol>，那子列表就是该条目的展开，语义上自然属于 “36.” 下的内容 - 不要给内层乱加
start，除非真有跳号需求（比如条款修订后补了一条） -
start值必须是整数，start="a"或start="A"无效 - 检查是否全局重置了
* { margin: 0; padding: 0; }—— 它会干掉<ol></ol>默认的margin-left - 父容器用了
display: flex或display: grid？嵌套<ol></ol>会脱离文档流，缩进失效 - 用了
list-style-position: inside？项目符号挤进内容区，视觉上像没缩进，甚至文字被遮挡 - 修复建议：显式写
ol ol { margin-left: 1.5em; }，比依赖浏览器默认更可控
<p></p> 或 <div> 里<li>嵌套层级越深，越要检查每一层是否都满足“<code><ol></ol> → <li> → <ol></ol>”这个链条
type 属性只控制当前层编号样式，不继承也不联动
type="A"、type="1"、type="a" 这些只影响本层 <ol></ol> 的显示格式，和上/下层无关。你不能指望设了外层 type="A"，内层就自动变成 type="1"——得手动写。
使用场景：法规文档常用 A. → 1. → a. → i. 四级结构，每级都要显式声明 type。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
start 属性只对外层生效，内层需靠结构保证连续性
start="34" 这类属性只能用在外层 <ol></ol> 上，它让第一条显示为 “34.”，后续自动 +1。但内层列表不会因此偏移起始值——它的编号永远从 1 或 a 开始，除非你手动加 start。
容易踩的坑：想让子列表从 “2.” 开始，就给内层加 start="2"；但更常见的需求其实是“延续父项逻辑”，这时靠的是嵌套位置，不是 start。
缩进失效往往不是 HTML 写错，而是 CSS 干扰了默认流
即使嵌套结构完全正确，也可能看起来“没缩进”或“文字贴边”。这通常不是 <ol></ol> 本身的问题，而是 CSS 重置或布局方式覆盖了浏览器默认行为。
性能与兼容性影响：现代浏览器对嵌套 <ol></ol> 渲染一致，问题几乎全出在样式层。
嵌套层级越深，DOM 结构的容错率越低。一个空格、一次误删 、或多套一层 <div>，都可能让整个编号体系崩掉。与其事后调试，不如在写第一层时就用开发者工具实时验证父子关系。</div>
