ul、ol、dl 分别表达并列项、有序序列、术语定义三种语义关系：ul 用于顺序无关的项目集合（如导航菜单），ol 用于必须保持先后逻辑的内容（如操作步骤），dl 专用于术语与解释的配对（如HTTP定义），三者均不可用 div 模拟，否则丧失语义化、无障碍及SEO能力。
ul、ol、dl 不是“换行排版工具”，而是表达三种明确关系的结构标签：并列项、有序序列、术语定义。用 div 套一堆 span 模拟列表，等于主动放弃浏览器解析、屏幕阅读器导航和搜索引擎抓取能力。
什么时候必须用 ul 或 ol？
只要内容天然具备“项目集合”属性，且每个子项地位平等（ul）或存在先后/层级/步骤逻辑（ol），就该用它们，而不是靠 CSS 伪造视觉效果。
- 导航菜单：
<nav><ul><li><a href="#">首页</a></li></ul></nav>——ul表达“可选入口集合”，li是语义原子单位，不能替换成div - 操作步骤说明：
<ol><li>下载安装包</li><li>双击运行</li></ol>—— 编号不是装饰，是语义承诺；改用div+ 计数器会丢失“顺序不可逆”的含义 - 错误提示列表：
<ul class="error-list"><li>邮箱格式不正确</li><li>密码长度不足8位</li></ul>—— 即使样式清空默认符号，语义仍生效
dl 不是“两列布局”，而是定义关系对
dl 的核心语义是“术语–描述”配对，不是为了实现左对齐右缩进。滥用它做纯视觉卡片布局，反而破坏结构可读性。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 正确场景：
<dl><dt>HTTP</dt><dd>超文本传输协议</dd><dt>HTTPS</dt><dd>加密版 HTTP</dd></dl>——dt是被解释项，dd是解释本身，二者绑定不可拆分 - 错误做法：用
dl展示商品参数表（如“品牌：Apple”“型号：iPhone 15”），除非这些字段确属“术语定义”而非“属性值对”；更稳妥的是用table或带 ARIA 的div容器 - 注意嵌套限制：
dd可包含段落、列表甚至div，但dt必须是纯文本或短语级内联内容，不能塞h3或p
别给列表外层硬加 div 包裹器
ul、ol、dl 本身已是语义完整的块级容器，加一层 div class="list-wrapper" 属于典型 divitis，既无结构价值，又干扰无障碍树构建。
立即学习“前端免费学习笔记（深入）”；
- 常见冗余写法：
<div class="nav-container"><ul><li>...</li></ul></div>—— 直接给ul加 class 即可，nav已提供上下文 - 例外情况：仅当需要插入非列表内容（如顶部说明文字、加载状态占位符）且无法用
caption或aria-hidden处理时，才考虑包裹；但优先用section+ 标题封装整个模块 - 性能影响：多一层 DOM 节点对渲染无实质影响，但会让 DevTools 中的结构树变臃肿，增加新成员理解成本
真正难的不是记住哪些标签可用，而是每次写 div 前问一句：这个容器有没有哪怕一丝语义线索？如果有，ul、ol、dl、nav、section 里总有一个比它更贴切——而漏掉这一步，后面补 ARIA 或重构 DOM 的代价远高于写对第一行。
