应根据语义选择列表标签：需表达顺序、步骤、优先级时用，否则用；嵌套列表需注意可访问性与样式塌陷；空影响DOM结构与渲染一致性；语义错误将大幅增加后续无障碍修复成本。
html 列表不用“详解”，直接用 <ul></ul> 和 <ol></ol> 就能跑起来；关键不是“怎么写”，而是“什么时候该用哪个”、以及“嵌套或样式出问题时，第一眼该查什么”。
什么时候该用 <ul></ul>，什么时候必须用 <ol></ol>
语义决定标签，不是视觉效果。浏览器默认给 <ol></ol> 加数字序号，给 <ul></ul> 加圆点，但这只是渲染结果——真正重要的是：是否需要表达顺序、步骤、优先级。
- 用
<ol></ol>：安装步骤、评分排名、法律条款编号、导航菜单（如果逻辑上有层级顺序） - 用
<ul></ul>：产品特性罗列、标签云、侧边栏链接组、无关顺序的选项集合 - 别为了“看起来像编号”硬套
<ol></ol>—— 比如“热门城市：北京、上海、广州”，城市之间无先后，<ul></ul>更准确
<li> 里还能嵌套列表？但要注意缩进和语义断裂
可以嵌套，但嵌套后容易丢失可访问性（比如屏幕阅读器可能读错层级），也常导致 CSS 样式意外塌陷。
- 嵌套本身合法：
<ul><li>主项<ul><li>子项</li></ul> </li></ul> - 避免三层以上嵌套，人眼和辅助技术都难识别
- 如果子列表是“解释说明”，考虑改用
<details><summary></summary></details>或段落 +<dl></dl>，语义更清晰 - CSS 中
margin-left或padding-left被重置时，嵌套列表可能“贴到左边”，优先检查父级<ul></ul>或<ol></ol>的padding
列表项内容为空或只含空格，会出什么问题
看似小事，实际影响 DOM 结构、CSS 选择器匹配、甚至 SSR 渲染一致性。
-
<li>在部分老版本 Safari 中会渲染成一个不可点击的空白占位符，导致:hover失效 -
<li> </li>（中间是空格）会被解析为含文本节点，li:empty伪类不匹配，但视觉上仍是空的 - 服务端模板（如 EJS、Jinja）中动态生成列表时，容易因条件判断漏掉
<li>开闭合，造成 HTML 结构错乱，浏览器纠错后 DOM 可能和预期不一致 - 稳妥做法：服务端确保不输出空
<li>；前端 JS 动态添加前先if (text?.trim())过滤
最常被忽略的一点：列表语义一旦写错，后续加 ARIA 属性（比如 aria-labelledby）或做无障碍测试时，修复成本远高于初始选对标签。别想着“先跑起来再优化”，<ul></ul> 和 <ol></ol> 的选择，第一行就该定下来。
立即学习“前端免费学习笔记（深入）”；
