HTML原生无排序机制，实际排序需JS操作DOM；依赖data-*属性可免清洗，否则须正则/类型转换提取有效值；缺失字段需业务逻辑处理；推荐Array.from+sort+appendChild重排，避免innerHTML丢失状态；服务端已排序时前端勿重复排序。
HTML原生排序不依赖数据整理，但实际效果取决于DOM结构
浏览器对 table 或列表元素本身不做自动排序；所谓“HTML排序”，本质是用JS读取现有DOM节点、提取内容、排序后再重排DOM。你页面里写的是乱序的 li，浏览器不会主动给你重排——它只负责渲染你给它的顺序。
常见误解是以为加个 sort 属性或CSS就能触发排序，其实HTML标准里根本没这种机制。真正起作用的是JS逻辑，而它是否需要“数据整理”，取决于你怎么取值：
- 如果每行/每个项有清晰的
data-*属性（如data-price="299"、data-date="2024-03-15"），JS可直接读取，无需额外清洗 - 如果文本混着单位、空格、括号（如
"¥ 1,299.00"），就必须先用正则或parseFloat/new Date()提取有效值，否则字符串排序会出错（"10"排在"2"前面） - 如果某些项缺失关键字段（比如有的
li没写data-score），排序时得决定是置顶、置底，还是过滤掉——这属于业务逻辑，不是HTML能替你判断的
用 Array.from() + sort() 重排 DOM 是最稳的路径
别用 innerHTML 拼接字符串再重写，容易丢失事件监听器和表单状态。正确做法是把目标元素转成数组，排序后用 appendChild 逐个归位——DOM 节点移动不触发重绘，性能也更好。
示例：按 data-weight 升序排列一组 div.product
立即学习“前端免费学习笔记（深入）”；
const items = Array.from(document.querySelectorAll('div.product'));
items.sort((a, b) => parseFloat(a.dataset.weight) - parseFloat(b.dataset.weight));
items.forEach(item => item.parentNode.appendChild(item));注意点：
-
dataset只读取data-开头的属性，且自动转为小驼峰（data-item-id→item.id） - 用
parseFloat而非parseInt，避免把"3.5"截成3 - 不要在循环中反复调用
querySelectorAll，DOM 查询开销大
服务端已排序的数据，前端再排就是冗余甚至错误
如果你的HTML是模板渲染出来的（比如PHP/Python/Jinja），且后端已经按价格、时间等字段排好序，前端JS再跑一遍排序，不仅浪费CPU，还可能因格式解析不一致导致顺序错乱（比如后端按数字排，前端按字符串排）。
验证方式很简单：打开开发者工具，看元素顺序是否和源码一致。如果一致，且没有动态增删，就别加JS排序逻辑。
- 适合加前端排序的场景：用户可切换排序维度（价格/销量/评分）、数据来自API异步加载、或需支持离线筛选
- 不适合的场景：静态商品列表页、SEO敏感内容、移动端低端机上大量节点（>200）
- 若必须兼顾SEO和交互，建议服务端输出多套有序HTML，前端用
display: none切换，比运行时排序更可靠
中文、货币、日期字段排序最容易踩坑
默认的 String.prototype.localeCompare() 看似能处理中文，但不指定语言环境时行为不稳定：Chrome可能按拼音，Safari可能按Unicode码点，结果不一致。
正确写法要带选项：
items.sort((a, b) => a.dataset.name.localeCompare(b.dataset.name, 'zh-CN', { sensitivity: 'base' }));其他典型陷阱：
- 日期字符串用
new Date(str)解析前，确认格式是YYYY-MM-DD；"2024/03/15"在部分iOS版本会返回Invalid Date - 货币字段含符号和千分位（
"¥1,299.00"），正则推荐用/[\d.]+/g提取，再parseFloat，比replace(/[^.\d]/g, '')更安全 - 布尔型排序（如“是否包邮”），别直接比
a.dataset.free === b.dataset.free，应统一转成数字：Number(a.dataset.free) - Number(b.dataset.free)
真实项目里，排序逻辑往往卡在字段提取这一步，而不是算法本身。花十分钟理清数据形态，比调两小时 sort 参数更有效。
