ol用于顺序敏感的内容（如步骤、条款），调换项序会改变语义；ul用于顺序无关的并列项（如菜单、标签）；FAQ应使用dl；ol的start和reversed是语义属性，影响辅助技术，不可用CSS替代。

ol 和 ul 的区别不在“有没有编号”，而在于内容是否依赖顺序——顺序一变，意思就错，必须用 ol；顺序可调，语义不变，只能用 ul。

判断标准：调换任意两项位置，意思是否改变？

这是唯一可靠依据，不是看 CSS 加没加数字，也不是看设计稿里是圆点还是 1.2.3。

• 教程步骤、安装流程、法律条款、时间线事件 → 调换后逻辑断裂 → 必须用 ol
• 导航菜单、技术栈、产品特性、标签云 → “React 在前还是 Vue 在前”不影响理解 → 只能用 ul
• FAQ 列表 → 不是列表，是键值对 → 应该用 dl，不是 ul 或 ol

ol 的 start 和 reversed 是语义属性，不是视觉开关

它们直接影响 DOM 行为和辅助技术播报，CSS 伪元素或手动写 “1.”、“2.” 完全无法替代。

• <ol start="5"></ol> 表示“这是第 5 步起始的连续序列”，后续 li 自动编号为 5、6、7
• <ol reversed></ol> 让屏幕阅读器明确读作“第三名、第二名、第一名”，不只是倒着显示
• <ol start="3" reversed></ol> 编号为 3、2、1（不是从最大值倒推）
• ul 不支持 start 或 reversed，写了浏览器直接忽略

嵌套时子列表类型必须独立判断

父级是 ol，不代表子项也得有序。每个子 ul 或 ol 都要单独问一句：“这些子项之间是否必须按此顺序执行/理解？”

DeepBI DHTML 页面生成器

生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

下载

立即学习“前端免费学习笔记（深入）”；

• 主步骤用 ol，每步下的“可选工具”是并列关系 → 子列表用 ul
• 导航菜单无论嵌套几层，菜单项之间仍是并列 → 全部用 ul，不能因为有下拉就套 ol
• 浏览器对 ol 嵌套生成的 1.1、1.2 编号不保证一致，也不该依赖；需要可控编号请用 CSS counter-reset/counter-increment

ul 没有 type 和 start 属性，这不是缺陷，是设计

HTML5 规范已移除 ul 的 type（如 type="square"），它本就不该携带顺序信息。

• 想改项目符号？用 CSS：ul { list-style-type: square; }
• ol 的 type（如 type="A"）仍被支持，但仅用于语义标注；样式控制仍应交给 CSS
• 用 ul 写 “1. 安装 2. 配置 3. 启动” 是常见错误：视觉像步骤，语义仍是无序 → 屏幕阅读器读作“项目、项目、项目”，SEO 和可访问性全丢

最容易被忽略的一点：语义一旦写错，CSS 再怎么修都补不回对屏幕阅读器和搜索引擎的影响——ol 和 ul 不是换行+符号的快捷键，它们是内容逻辑的声明。