HTML本身不参与排列组合计算，性能瓶颈在于JavaScript全排列逻辑及DOM高频操作；推荐Heap’s算法替代递归，用documentFragment批量插入，生成即校验即丢弃以避免内存爆炸。
不会——HTML 本身不参与排列组合计算，所谓“HTML 排列组合拖慢算法”是典型的误解。真正影响性能的是 JavaScript 中实现全排列的逻辑，以及是否在 DOM 中高频操作节点。
全排列必须用递归？for 循环 + swap 更可控
很多初学者一看到“abc → acb/bac/…”就默认要用深度递归，结果栈溢出或内存爆掉。实际生产中更推荐基于索引的迭代法（如 Heap’s algorithm），避免函数调用开销和堆栈限制。
-
Heap’s algorithm只需 O(1) 额外空间，交换次数最少，适合长数组（比如 8 个以上元素） - 递归版
AllRange()在 Chrome 中处理长度 > 10 的数组就容易触发RangeError: Maximum call stack size exceeded - 若输入是字符串，先转为
Array.from(str)，别直接对str[i]赋值（字符串不可变）
sort() 不等于全排列：混淆这两者会出大问题
常见错误是把 arr.sort() 当成生成所有排列的方式——它只返回一个有序结果，不是所有可能顺序。全排列输出数量是 n!，而 sort() 输出唯一。
-
[1,2,3].sort()永远只得到[1,2,3]（升序）或[3,2,1]（加reverse()），绝不会输出[2,1,3]等中间态 - 想用
sort()枚举排列？得配合Math.random()打乱（arr.sort(() => Math.random() - 0.5)），但这是伪随机、不可控、无法遍历全部组合 - 真要穷举，必须用回溯或迭代生成器，不能绕开
n!时间复杂度
DOM 插入全排列结果时，documentFragment 是必选项
如果把每种排列都生成一个 <tr> 然后直接 <code>appendChild() 到表格里，10 个元素的全排列有 3628800 种，浏览器瞬间卡死。关键不是算法慢，是 DOM 操作太重。
立即学习“前端免费学习笔记（深入）”；
- 批量插入前，先创建
documentFragment，把所有<tr> append 进去，最后只执行一次 <code>tbody.appendChild(frag) - 更现实的做法：只渲染前 100 个排列，加“加载更多”按钮，用
Generator+yield控制节奏 - 避免在循环里反复读取
table.rows.length或调用getBoundingClientRect()，这些触发重排（reflow）
真正容易被忽略的点：全排列结果通常不需要全部保留在内存里。生成一个、校验一个、丢弃一个，才是处理大数据量排列的合理路径——否则你不是在跑算法，是在给浏览器喂内存炸弹。
