html列表语义正确性取决于是否用表达内在顺序（如步骤、排名），或表达并列关系（如菜单、标签），错误选择会损害无障碍、seo及可维护性。
直接说结论：不是“编辑器怎么制作列表”，而是“你写的 HTML 标签是否语义正确”——编辑器只负责输入和渲染，真正决定是无序还是有序的，是你手敲的 <ul></ul> 还是 <ol></ol>。
什么时候必须用 <ol></ol>，不能用 <ul></ul>
关键看内容有没有内在顺序。浏览器默认给 <ol></ol> 加数字、给 <ul></ul> 加圆点，但这只是视觉表象；语义错误会导致屏幕阅读器读错、SEO 权重稀释、后续加 ARIA 时逻辑断裂。
- 必须用
<ol></ol>：安装步骤、法律条款编号、考试评分排名、导航菜单（如果逻辑上存在操作先后） - 该用
<ul></ul>：产品特性罗列、标签云、侧边栏链接组、“热门城市：北京、上海、广州”（城市之间无优先级） - 别为了“看起来像编号”硬套
<ol></ol>——比如把一堆并列的 FAQ 项塞进<ol></ol>，会误导辅助技术认为它们有执行顺序
<ol></ol> 的 start 和 type 属性还在用吗
还在用，但仅限简单场景。现代项目更倾向用 CSS 的 counter-reset + counter-increment 控制编号逻辑，因为更可控、可嵌套、不依赖 HTML 属性。
-
start="5"可以让列表从 5 开始编号：<ol start="5"><li>第五步</li></ol> -
type="A"或type="i"是 HTML4 遗留写法，部分老 IE 支持不稳；Chrome/Firefox 虽能识别，但无法与 CSS list-style-type 混用，容易冲突 - 真正需要罗马数字或字母编号时，优先用 CSS：
ol { list-style-type: upper-roman; }
嵌套列表时第一眼该查什么
嵌套本身合法，但出问题时 90% 是样式塌陷或语义断裂，不是语法错。
- 检查父级
<ul></ul>或<ol></ol>的padding-left是否被全局 CSS 重置为 0——很多 reset.css 或 modern-normalize 会干这事，导致子列表“贴到左边” - 避免三层以上嵌套：
<ul><li><ul><li><ul>…</ul></li></ul></li></ul>，人眼难分辨层级，屏幕阅读器也常跳过中间层 - 子列表如果是解释性内容（比如某个
<li>下要展开说明），<details><summary></summary></details>或<dl></dl>比嵌套<ul></ul>更语义准确
空 <li> 为什么不能留
看似只是少写一行文字，实际会触发 DOM 解析异常和可访问性故障。
- 在 Safari 旧版本中，空
<li>渲染为不可点击占位符，:hover失效 -
<li> </li>（含空格）不匹配:empty伪类，但视觉仍是空白，CSS 选择器逻辑混乱 - 服务端模板（如 Jinja、EJS）动态生成时，if 判断漏掉空值过滤，会导致
<li>直接上屏，破坏列表结构一致性 - 稳妥做法：前端 JS 插入前加
if (text?.trim())，服务端模板里用{% if item %}包裹 - {{ item }}
最常被忽略的一点：语义选错标签，不是“先跑起来再修”，而是“第一行就定生死”——后续所有无障碍测试、SEO 优化、甚至 CMS 内容迁移，成本都成倍放大。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
