应通过dragend/drop监听拖拽结束→提取DOM中li的data-id顺序→JSON.stringify后存localStorage→页面加载时按ID数组查找并appendChild重排节点，而非依赖ol的value/start属性。
不能靠 ol 自身属性保存用户拖拽后的顺序——它只负责渲染编号，不记录或同步 DOM 位置变化。真正可行的路径是：监听拖拽结束 → 提取当前 DOM 顺序 → 序列化存入 localStorage → 页面加载时按存储顺序重排节点。
用 dragend + localStorage 持久化顺序
拖拽排序后，DOM 节点顺序已变，此时直接读取 ol 下的 li 顺序就是用户最终选择。关键不是“保存编号”，而是“保存元素身份与位置映射”。
- 别用
textContent作唯一标识——内容可能重复或含空格/换行，改用稳定 ID：li.dataset.id或li.id - 存的时候用
Array.from(ol.querySelectorAll('li')).map(li => li.dataset.id)，确保顺序和 DOM 一致 - 必须用
JSON.stringify()转字符串再存，localStorage只接受字符串值 - 记得加错误边界：存之前检查
localStorage是否可用（比如隐私模式下会抛错）
页面加载时用 JS 恢复 DOM 顺序
恢复不是“重写 HTML”，而是把现有 li 节点按存储 ID 列表重新插入 ol。强行 innerHTML 会清空事件绑定、表单状态、动态生成的内容。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 先从
localStorage读出 ID 数组，如['item-3', 'item-1', 'item-2'] - 遍历该数组，用
document.querySelector(`[data-id="${id}"]`)找对应li节点 - 用
ol.appendChild(li)逐个追加——这会自动移动节点，不重复创建 - 如果某 ID 对应的
li已不存在（比如后端删了数据），跳过即可，避免报错中断流程
value 属性和 start 属性对保存顺序没用
ol 的 value 和 start 只控制视觉编号显示，不影响 DOM 顺序，也不参与序列化逻辑。你拖动后即使编号看起来乱了（比如 <li value="5"> 后面跟着 <li value="2">），浏览器仍按 DOM 位置渲染，且 localStorage 里存的仍是真实节点顺序。
立即学习“前端免费学习笔记（深入）”；
- 不要在拖拽逻辑里手动改
li.value——它和顺序无关，纯属干扰项 -
start只影响初始渲染，后续 DOM 移动不会触发它更新，留着也无害，但没必要动 - 若需编号随顺序实时更新（比如显示“第1名”“第2名”），那是 CSS 计数器或 JS 渲染层的事，和顺序持久化正交
最易被忽略的是：拖拽 API 的 dragend 事件不保证在所有浏览器中都精准触发（尤其移动端或快速拖放时），建议加一个防抖的 setTimeout 延迟保存，或监听 drop 事件更稳妥；另外，如果列表项本身有异步加载内容（如图片、组件），恢复顺序前得等它们 ready，否则可能因 DOM 不完整导致查找失败。
