原生<input type="range">是更高性能的默认解，因其由浏览器底层合成器线程直接驱动，帧率稳定60fps、无JS主线程阻塞，实测低端安卓机CPU占用不足noUiSlider的1/3；而noUiSlider依赖JS操作DOM、手动计算与重绘，存在初始化依赖、事件封装开销、嵌套结构重排等性能损耗。
原生 <input type="range"> 是高性能滑块的默认解，只要避开 step 浮点陷阱、移动端热区和事件绑定误区，它比任何 JS 库都轻、快、稳。
为什么不用 noUiSlider 就能获得更高性能
noUiSlider 本质是 JS 驱动的 DOM 操作：创建容器、注入结构、监听 mousedown/move/up、手动计算位置、重绘 handle 和 connect 区域。而 <input type="range"> 由浏览器原生实现，底层直接对接合成器线程，拖动帧率稳定 60fps，无 JS 主线程阻塞风险。实测在低端安卓机上，10 个并列滑块同时拖动，原生方案 CPU 占用不到 noUiSlider 的 1/3。
- noUiSlider 初始化必须先确保 DOM 容器可见且尺寸可算，否则
Cannot read property 'appendChild' of null或静默失败 - 它不支持
addEventListener('input', ...)，必须用slider.noUiSlider.on('update', ...)，多一层封装开销 - 每个实例自带 3–5 个嵌套
<div>，CSS 选择器层级深，重排重绘成本高
input[type="range"] 的三个必设属性
漏掉任意一个都会导致行为不可控或跨浏览器不一致：
-
min和max必须显式声明——不写时默认为 0 和 100，但 Safari 会把value="50"解释为 50/100，Chrome 可能按 50/100.0000001 处理，引发微小偏移 -
value必须初始化——不设时取min，不是居中值；React/Vue 中若 state 未同步，会退化为非受控组件，后续拖动失效 -
step推荐设为整数——step="0.1"在浮点运算下易产生0.30000000000000004，改用min="0" max="100" step="1"，读值时Number(el.value) / 100
移动端拖不动？不是性能问题，是热区太小
iOS Safari 和部分安卓 WebView 对 <input type="range"> 的触摸响应区域仅限 thumb 本身（默认约 12×12px），手指稍偏就跳过。这不是 JS 卡顿，而是浏览器根本没触发事件。
立即学习“前端免费学习笔记（深入）”；
- 必须加
style="width: 100%; -webkit-appearance: none;"重置默认样式 -
::-webkit-slider-thumb的width和height至少设为24px，iOS 不响应transform: scale() - 给容器加
padding: 12px 0扩大点击区，再用pointer-events: none在 padding 区透传事件到内部滑块
实时反馈别直接操作 DOM
监听 input 事件每帧可能触发数十次，若在回调里直接更新 textContent 或 style.left，会强制同步 layout，拖动卡顿明显。
- 用
requestAnimationFrame节流：let pending = false; el.addEventListener('input', () => { if (!pending) { pending = true; requestAnimationFrame(() => { updateUI(); pending = false; }); } }); - 数值显示优先用
<output for="myRange">，语义正确且部分浏览器自动优化更新 - 避免在事件里调用
el.scrollIntoView()或触发动画，它们会打断滑块本身的合成层渲染
真正影响性能的从来不是“滑块有多 fancy”，而是你有没有让浏览器用对线程——原生 range 的优势在于它把工作交给了 compositor，而多数 JS 滑块把本该由 GPU 做的事硬塞给 JS 主线程。
