必须用ol而非ul当内容顺序改变会改变语义，如安装流程、法律条文、食谱步骤；导航菜单有路径优先级时也应用ol，纯并列则用ul。
该用 ul 还是 ol，不看“要不要编号”，而看内容换顺序会不会改变意思。
什么时候必须用 ol，而不是靠 CSS 加个数字
浏览器给 ol 加编号只是副作用，真正起作用的是语义：屏幕阅读器会读出“第1项、第2项”，搜索引擎会理解这是步骤或条款序列。
- 安装流程、法律条文、食谱步骤、搜索结果排名 → 必须用
ol - 导航菜单是否要用
ol？取决于逻辑：若菜单项有优先级（如“首页 > 产品 > 定价 > 联系我们”隐含路径顺序），ol更准确；纯并列入口则用ul - 硬套
ol写“热门城市：北京、上海、广州”，会导致读屏器错误播报顺序，后续加aria-属性也难修正
ul 和 ol 嵌套时，DOM 结构错在哪一行
合法嵌套只有一种写法：li 内直接包 ul 或 ol。任何跳层、错位都会让浏览器自动纠错，但 DOM 已不是你写的那样。
- 错误写法：
<ul> <li>A</li> <ul><li>B</li></ul> </ul>→ 第二个ul会被浏览器移到外面，变成两个平级列表 - 正确写法：
<ul><li>A<ul><li>B</li></ul> </li></ul>→ 子列表是li的子节点 - 动态生成时（如 Vue/JSX 或模板引擎），漏掉
li闭合或条件分支未覆盖空状态，极易产出这种结构断裂
列表符号不显示？先查这三处，别急着改 CSS
90% 的“编号消失”问题跟 list-style 无关，而是底层结构或解析异常。
- 检查
li是否被设了display: flex或display: grid—— 这些值会隐式禁用列表标记，需显式加list-style: inherit - 打开开发者工具的 “Computed” 面板，看
list-style-type最终计算值是不是none；如果是，往上查是否被全局 reset.css 或组件库样式覆盖 - 右键检查元素，确认
li真是ul/ol的直接子节点；如果看到ul > div > li，说明 HTML 结构非法，浏览器已重排 DOM
start 和 type 属性现在还值得用吗
能不用就不用。它们兼容性有限、不可扩展，且和现代 CSS 方案冲突风险高。
-
type="A"在 Safari 和旧版 Edge 中可能不渲染为大写字母；type="1"是唯一稳定值 -
start="5"只对单个ol有效，多个连续ol想“续号”，必须用 CSScounter-reset/counter-increment - 要加前缀（如
"Step 1."）、图标或 SVG，必须用list-style: none+li::before { content: ... }，type根本做不到
最常被忽略的一点：列表标签选错，不是样式问题，是语义污染——它会在无障碍测试、SEO 抓取、甚至 JS 的 querySelectorAll('ol > li') 中持续制造偏差，而且越往后改越疼。
