ol不能直接设contenteditable，否则编号消失、结构错乱、可访问性失效；应仅对li设contenteditable，用css counter控制编号，并手动提取内容提交。
ol 本身不能直接提交数据，也不支持原生编辑；想让列表内容可编辑，必须用 contenteditable，但要小心破坏语义和可访问性。
为什么不能直接给 ol 加 contenteditable="true"
浏览器允许对 ol 设置 contenteditable，但实际效果不可控：编号会消失、li 可能被意外拆分、粘贴富文本时结构错乱，且屏幕阅读器无法正确播报“第 X 项”。更严重的是，ol 的语义是“有序步骤”，不是“编辑容器”——一旦用户删掉一个 li，编号逻辑就断了，start 和 reversed 属性完全失效。
常见错误现象：ol 里文字能点选编辑，但回车新增行变成 div 而非 li；复制粘贴后出现嵌套 p 或 span，导致校验失败或样式崩坏。
正确做法：只对 li 内容启用编辑，保留 ol 结构
把编辑能力下放到每个 li 的文本节点，而不是整个 ol。这样既维持了语义层级，又避免编号被破坏。
-
li元素上设contenteditable="true"，不要设在ol上 - 禁用默认序号（
ol { list-style: none; }），改用 CSScounter控制编号显示，确保编辑前后序号始终连续 - 为每个
li显式设置display: list-item，防止 flex/grid 布局干扰编号渲染 - 用
li::before插入编号，内容来自counter(item)，而非依赖 HTML 原生编号
示例：
<ol id="steps"> <li contenteditable="true">安装 Node.js</li> <li contenteditable="true">初始化项目</li> </ol>
CSS 配合：
ol { counter-reset: item; list-style: none; padding-left: 0; }
ol li { counter-increment: item; display: list-item; }
ol li::before { content: counter(item) ". "; font-weight: bold; }
提交前怎么把可编辑 li 转成表单数据
ol 不参与表单序列化，必须手动提取内容并塞进隐藏字段或 FormData。
- 监听
input或blur事件，实时更新<input type="hidden" name="steps">的value - 提取时用
li.textContent.trim()，别用innerHTML—— 否则会把contenteditable产生的冗余标签（如<div>、<code><br>）一起发过去 - 若需多值提交（如 PHP 接收
steps[]=xxx），得用FormData.append('steps[]', text)或拼接steps[]=A&steps[]=B - 注意空项过滤：用户可能删光文字却没删
li，得检查textContent.length === 0并跳过 - 或干脆禁用回车换行：
event.preventDefault()+ 提供「+ 添加步骤」按钮作为唯一增项入口
最容易被忽略的坑：编辑后编号不重排、回车行为失控
用户在 li 末尾按回车，默认会分裂出新 li 吗？不会。浏览器只会插入 <div> 或换行符，导致 DOM 结构污染。解决方法只有两个：
<ul>
<li>拦截 <code>keydown 中的 Enter 键，手动创建新 li 并聚焦，同时调用 ol.insertBefore(newLi, nextLi)
另外，动态增删 li 后，CSS counter 会自动重算，但如果你用了 start 或 reversed，它们已失效——别回头依赖这些属性，从一开始就不该用。
