ul 嵌套必须将内层 ul 作为父级 li 的直接子元素，否则结构断裂、编号重置、键盘导航失效；ul 本身无序号，层级编号需 css counter 实现；嵌套超三层应优先用 details/summary。
能嵌套，但必须把内层 ul 放在父级 li 里面，否则结构断裂、编号重置、键盘导航失效——这不是浏览器 bug，是 HTML 语义规则本身的要求。
子 ul 必须作为父 li 的直接子元素
这是最常出错的地方。很多人以为只要两个 ul 套着写就行，结果写成：
- 一级项
- 二级项
这其实是两个完全独立的列表，浏览器无法识别层级关系。正确写法是：
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 一级项
- 二级项
- 用开发者工具选中内层
ul，往上查parentElement，必须能一路回到某个li节点 - JS 操作如
li.querySelector('ul')只有在这种结构下才有效 - 屏幕阅读器读作“列表，1 项，包含子列表”，而不是“两个列表”
- 如果用了
aria-expanded或aria-controls，绑定目标也只认这种 DOM 路径
ul 嵌套后编号不连续？因为 ul 本就不编号
ul 默认用圆点（●）标记，没有序号概念，所以不存在“1.1”“2.3”这类问题。但如果你混用了 ol 和 ul，比如主项用 ol、子项用 ul，那子项依然从 ● 开始，不会继承父级数字。
- 想让无序列表也带层级编号（如 “1.1 ●”），必须用 CSS
counter，不能依赖type属性 -
list-style-type: none+::before+counters()是唯一可靠路径 - 别给
ul设type="A"—— 这个属性对ul无效，浏览器会忽略
嵌套超过 3 层时，ul 不再是最优选择
不是语法不允许，而是可访问性和用户认知开始吃力。4 层 ul 嵌套后，缩进可能超 160px，键盘 Tab 流会变长，屏幕阅读器播报层级也容易混淆。
- 超过 3 层优先考虑
<details><summary></summary></details>：原生支持空格/回车展开、焦点自动管理、无需 JS - 如果必须用
ul（比如要 hover 展开或联动控制），就得配 JS 管理open状态和 ARIA 属性 - 用
margin-left调缩进比依赖默认padding-left更可控，避免 UA 样式叠加失真 - 测试时关掉 CSS，纯靠语义结构看是否还能理清层级 —— 如果不能，说明 HTML 写得已经脱离内容本质了
真正难的不是怎么写嵌套，而是判断该不该嵌套。很多所谓“多级菜单”，其实用单层 ul + 分组 li + CSS Grid 就能更轻量地表达，没必要硬塞三层 ul。
