HTML本身不排序，所有排序效果均由JavaScript操作DOM实现；自定义属性如sort="true"被浏览器忽略；DOM顺序严格按源码，CSS和HTML属性不改变实际节点顺序；sort()需谨慎处理类型、中文、日期等，数据提取质量决定排序成败。
HTML 本身不排序，所以它对数据整理毫无直接影响。 所有“HTML 排序”效果都是 JavaScript 操作 DOM 的结果，数据整理是否高效，取决于你如何提取、清洗、转换和重写 DOM，而不是表格或列表写了几个 <tr> 或 <li>。
为什么 sort="true" 这类属性完全没用
浏览器解析 HTML 时会忽略任何类似 sort="true"、data-sortable 或 order="desc" 的自定义属性——它们不触发任何行为，也不改变 DOM 顺序。你看到的排序，100% 来自 JS 代码里调用的 Array.prototype.sort() 和后续的 appendChild() 或 innerHTML 覆盖。
- DOM 渲染顺序严格按源码中节点出现顺序，
<tr>在第 3 行就永远在第 3 行，除非 JS 显式移动它 -
<ol>的value属性只影响编号显示，改了也不会重排子元素 - CSS
order只改变 flex/grid 子项视觉位置，document.querySelectorAll('li')拿到的仍是原始 DOM 顺序
Array.prototype.sort() 默认行为容易踩坑
直接对从表格里提取的字符串数组调用 sort()，几乎必然出错：数值列会变成 “10, 100, 2”，日期列如 "2023-01-10" 和 "2023-01-2" 也会错乱（后者字符串比较更小）。
- 数值排序必须显式转类型：
(a, b) => parseFloat(a) - parseFloat(b)，并处理NaN（比如空单元格） - 中文字符串排序别用
a > b，要用a.localeCompare(b)，否则 “张三” 可能排在 “李四” 后面 - 日期字段优先用 ISO 格式（
"2023-01-10"），否则得先new Date(str)，且要判断isNaN(date.getTime()) -
sort()是原地修改，若需保留原始顺序，先[...rows].sort(...)
真实场景下，DOM 提取方式比排序逻辑更关键
排序出错，80% 不是因为比较函数写错了，而是因为从 <td> 里读到了错误的内容：换行符、隐藏 <span>、单位文字（如 “100元”）、空格、富文本残留。
立即学习“前端免费学习笔记（深入）”；
- 优先用
cell.dataset.sortValue，把干净可排序值存在属性里，避免运行时解析 - 不用
innerText（受 CSSdisplay: none影响，会合并空白），改用textContent.trim() - 表头点击后必须缓存当前排序状态（列索引 + 升降序），否则第二次点又回到升序，体验断裂
- 超过 500 行时，逐个
appendChild()会卡顿，该用DocumentFragment批量插入
最容易被忽略的一点：数据整理的瓶颈从来不在“怎么排”，而在于“排什么”。如果表格里混着 “¥100”、“100.00”、“一百”、“--”，再健壮的 sort() 函数也救不了——结构化数据源头没理清，JS 层只能打补丁。
