该用ul而非ol的关键在于内容是否依赖顺序：无序并列项（如导航菜单、标签云）用ul，有序步骤或排名（如安装流程、排行榜）必须用ol，误用会损害无障碍访问与SEO。
什么时候该用 ul 而不是 ol
关键看内容是否依赖顺序。如果项目之间没有先后、优先级或步骤关系，比如导航菜单、产品分类、兴趣标签，就用 ul；如果明确需要编号逻辑（如安装步骤、考试流程、排行榜名次），必须用 ol。误用 ol 做纯展示会带来无障碍问题——屏幕阅读器会读出“第1项、第2项”，而实际并无序号意义，反而干扰理解。
常见错误现象：ol 里硬塞一堆并列新闻标题，或用 ul 写“第一步→第二步→第三步”文字。前者浪费语义，后者丢失结构信息。
-
ul默认符号可被 CSS 完全覆盖，适合做纯视觉菜单 -
ol的编号是浏览器自动生成的，不能手动写1.、2.——那样既不可访问，也不响应reversed或start属性 - 嵌套时，
ol里套ul（如“第三步：准备以下工具”）很自然；反过来也成立，但别在ol里套另一个ol表示“子步骤”，除非真有二级编号需求
dl 不是“装饰性列表”，而是语义容器
dl 的核心作用是表达“术语-定义”对，不是为了缩进或换行。它常被误用于做侧边栏链接组或图标+文字说明，结果破坏了语义结构，也让键盘导航和语音助手难以正确解析。
典型适用场景：FAQ 页面、技术文档中的参数说明、网页底部的“关于我们/联系方式/版权声明”分组。
立即学习“前端免费学习笔记（深入）”；
- 每个
dt应该是独立、可识别的名词或短语，不能是长句或操作指令 - 一个
dt可对应多个dd（比如一个术语有多个解释角度），但一个dd不应跨多个dt - 不要用
dl替代ul+span做“标题+描述”布局——CSS 可以做到同样效果，且语义更干净
用 CSS 控制列表样式比 HTML type 属性更可靠
ul 和 ol 的 type 属性（如 type="square" 或 type="A"）已被现代浏览器弱化支持，尤其在移动端或高对比度模式下表现不稳定，且无法设置颜色、大小、间距。真正可控的方式是用 CSS 的 list-style-type 和 list-style-image。
-
list-style-type: none是清除默认符号最安全的方式，比type="none"兼容性好得多 - 要用图标替代圆点，优先用
background-image+padding-left，而非list-style-image——后者不支持尺寸缩放，也不受background-size控制 - 修改
ol编号样式时，counter-reset和counter-increment比type灵活得多，比如实现“Step 1”、“Step 2”带前缀的编号
本地双击打开 HTML 文件时列表可能不渲染
这不是列表标签本身的问题，而是浏览器对 file:// 协议的安全限制导致的常见副作用：当 HTML 文件含相对路径引用的 CSS 或 JS（比如 link href="style.css"），本地双击打开时因 CORS 策略失败，样式丢失，列表就变成无缩进、无符号的纯文本块，看起来像“没生效”。
- 直接检查浏览器开发者工具（F12）的 Console 和 Network 面板，看是否有 “Not allowed to load local resource” 报错
- 临时解决办法：用 VS Code 的 Live Server 插件、Python 的
python -m http.server，或 Node 的http-server启一个本地服务，让地址变成http://localhost:xxxx/ - 特别注意：某些 CSS 重置库（如 normalize.css）依赖网络字体或外部资源，本地打开时也会导致列表样式异常
dl 布局导航，或为“省事”用 div + br 代替 ul。 
