HTML列表结构详解：ulolli使用教程

本文深入剖析HTML列表（ul、ol、li）的语义本质与正确用法，强调列表选择不应依赖视觉样式，而应由内容逻辑决定：无序内容用ul，有序依赖用ol；li不可省略或替代，必须严格嵌套以保障DOM完整性、可访问性与JS可控性；嵌套层级建议不超过三层，避免语义混乱、维护困难与交互异常，并指出常见误区如滥用type属性、用div冒充li、靠空格缩进替代CSS等，帮助开发者写出既符合标准又健壮实用的HTML列表结构。

HTML 列表不用“教程”也能写对，关键在分清语义和嵌套规则。

ul 和 ol 什么时候该用哪个

ul 表示项目之间无顺序依赖，比如导航菜单、标签云、一堆功能入口；ol 表示步骤、排名、时间线这类有天然次序的内容，比如安装步骤、比赛名次、文章目录。

常见错误现象：ol 里硬塞“热门标签”——浏览器会渲染数字序号，但语义错，影响可访问性和 SEO；反过来用 ul 写“第一步、第二步”，屏幕阅读器读不出顺序逻辑。

• 不靠视觉样式判断，看内容是否“换顺序就变意思”
• ol 支持 start、reversed、type 属性，但别为了改数字样式去滥用 type="A"，CSS 更可控
• 嵌套时，子列表用 ul 或 ol 都行，取决于子项自身是否有顺序，不是必须跟父级一致

li 标签不能省略，也不能乱放

li 是唯一合法的 ul/ol 直接子元素。浏览器会自动容错（比如把文字直接塞进 ul），但 DOM 结构残缺，JS 操作 document.querySelectorAll('ul > li') 会漏掉那些“隐形 li”。

使用场景：动态生成列表时，后端模板或 JS 拼字符串容易漏写 li，或者把 div 当 li 用。

• 永远用
• 内容
包住每一项，哪怕内容是空的或只有图标
• li 内部可以放任意流内容（p、div、img、甚至另一个 ul），但别把 ul 直接当 li 的替代
• 不要写
  错
  —— 这在 HTML5 中是无效结构，校验通不过

列表嵌套的层级和缩进陷阱

嵌套本身没限制，但每多一层，CSS 选择器复杂度和缩进管理成本就翻倍。真实项目里常见“三级菜单”写成三层 ul，结果 hover 效果错乱、移动端点击区域变小。

性能影响：深层嵌套不会拖慢渲染，但 JS 遍历 ul ul ul li 比平级慢，尤其在大量列表项时。

• 嵌套层级建议 ≤3 层；超过就该考虑用其他组件（如树形控件、折叠面板）
• 缩进靠 CSS 控制，别用   或 margin-left 堆砌，优先用 padding-left + list-style-position: inside
• 用 display: list-item 模拟列表行为？别试——语义丢失，辅助工具无法识别

最常被忽略的是 li 的隐式闭合规则：HTML 解析器遇到下一个 li 或父级结束标签时才闭合当前 li，所以写