ol 表示顺序不可互换的列表（如步骤），ul 表示并列关系的列表（如菜单），判断标准是调换项序是否改变语义；ol 支持 start 和 reversed 语义属性，ul 不支持；嵌套时子列表类型需独立判断；语义错误无法通过 css 修复。
ol 和 ul 的语义区别不是“有没有编号”
很多人看到带数字的列表就用 ol，看到带圆点的就用 ul，结果把“支持格式：PDF、DOCX、TXT”硬塞进 ol 里——这会误导屏幕阅读器和搜索引擎。真正决定用哪个的，是内容逻辑：ol 表示顺序不可互换（比如安装步骤），ul 表示项之间完全并列（比如技术栈、导航菜单）。
常见错误现象：
- 用
ol包裹产品特性点，只因 CSS 加了数字 —— 辅助技术仍读作“项目、项目、项目”，丢失顺序语义 - 把 FAQ 用
ul+ 手动加粗标题实现 ——dl才是正确结构，否则键值关系无法被解析
判断标准很简单：如果调换任意两项位置，意思是否改变？变了 → 用 ol；没变 → 用 ul。
ol 的 start 和 reversed 属性不能靠 CSS 模拟
start 和 reversed 是语义属性，不是视觉装饰。浏览器和读屏软件依赖它们理解列表起点与方向，CSS 伪元素或手动写数字无法替代。
使用场景：
- 接续上一页的步骤：用
<ol start="5"></ol>，后续li自动编号为 5、6、7 - 倒序排行榜：用
<ol reversed></ol>，辅助技术会明确播报“第三名、第二名、第一名” - 同时使用
start="3"和reversed→ 编号为 3、2、1（不是从最大值开始倒推）
注意：ul 不支持 start 或 reversed，写了也无效；旧版浏览器对 type="A" 支持不稳定，优先用 CSS 的 list-style-type 控制外观。
嵌套时子列表类型必须独立判断
父级是 ol，子项不自动继承“有序”语义。每个 ul 或 ol 都要单独问一句：“这些子项之间是否必须按此顺序执行/理解？”
典型错误：
- 在教程步骤（
ol）下，把“可选工具”也套ol，只为缩进或让编号变成 1.1、1.2 —— 实际上工具之间无依赖，该用ul - 导航菜单用
ol，只因下拉项有层级感 —— 菜单项是并列关系，无论嵌套几层都该用ul
正确写法示例：
<ol>
<li>安装软件</li>
<li>配置环境</li>
</ol>
- 设置代理
- 选择语言
- 启用日志
子 ul 的存在不影响父 ol 的编号连续性，也不改变其语义。
ul 没有 type 和 start 属性，这不是缺陷而是设计
ul 的 HTML 属性里压根没有 type、start、reversed —— 浏览器会忽略它们。所谓“ul type="square" 生效”，只是旧版兼容行为，HTML5 已移除。
想改项目符号？用 CSS：
- 方块：
ul { list-style-type: square; } - 无符号：
ul { list-style-type: none; } - 自定义图标：用
::marker或::before伪元素，比过时的type更可控
别用 ul 套 type="1" 来“重置编号”——那不是标准用法，start 只属于 ol。
最容易被忽略的一点：语义一旦写错，CSS 再怎么修都补不回对屏幕阅读器和 SEO 的影响。写完列表，先问自己一句：如果关闭样式，仅靠结构，用户还能否准确理解项之间的关系？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
