原生仅支持单值选择，不支持区间语义；实现双滑块范围选择必须用两个独立range元素配合JavaScript实时互锁逻辑，强制校验并修正left≤right，否则必然出现非法反序状态。
原生 <input type="range"> 不支持双向滑块，所谓“区间选择器”必须用两个独立 range 元素 + JavaScript 实时互锁逻辑来模拟，否则 left > right 的非法状态必然出现。
为什么不能只写一个 range 标签就实现区间
浏览器规范里 range 是单点控件，DOM 上只有 value 属性，没有 minValue 或 maxValue 接口。你看到的“双把手”效果，要么是 CSS 画的假象，要么是两个 range 叠在一起但没做数值约束——后者在用户快速拖拽或键盘输入时，极易触发 left.value = 90、right.value = 10 这类反序状态。
表单提交时，它们各自按 name=value 发送，后端收不到“这是一个区间”的语义；无障碍阅读器也只会分别读出两个独立滑块，不会识别为“价格范围”或“时间区间”。
input 事件中怎么写互锁逻辑才不抖动
关键不是视觉对齐，而是每次值变更前强制校验并修正对方边界。只监听 change 会漏掉拖拽过程中的中间态，导致 UI 和数据短暂错位。
立即学习“前端免费学习笔记（深入）”；
- 左滑块拖动时，新值不能大于右滑块当前值；右滑块拖动时，新值不能小于左滑块当前值
- 用
event.target.valueAsNumber读值，避免parseInt在step="0.1"下因浮点误差出错 - 修正时别直接赋
value = other.value，加一个微小偏移（比如+ 0.1）防止粘连：right.value = (left.valueAsNumber + 0.1).toFixed(1) - 必须同时监听键盘输入（
keydown+input），否则用户手动改value输入框内容会绕过约束
移动端上两个 range 的兼容性坑有哪些
iOS Safari 对 range 的触摸响应延迟高、精度差，Android WebView 则可能把 input 事件合并触发，导致拖拽卡顿或跳变。更麻烦的是，两个滑块共用一条轨道时，iOS 上经常发生 touch 事件穿透——手指明明在左滑块上，却触发了右滑块的更新。
这些不是 JS 能完全解决的底层限制：
- Safari 在 iOS 15.4 之前完全忽略
appearance: none，清除默认样式后轨道直接消失，必须手动重绘 - thumb 伪元素设
display: block会让 Safari 中的滑块消失 - 移动端没有“松手”概念，
change触发时机不可靠，实时反馈必须绑input并配合requestAnimationFrame节流 - 两个
range的min/max是各自独立的，A 的max不会自动限制 B 的min，得靠 JS 手动同步
什么时候该放弃原生 range 改用 NoUiSlider
当你需要稳定互锁、触摸适配、键盘控制（←→Home/End）、无障碍支持（完整 aria- 属性）且不想反复踩坑时，NoUiSlider 是更省事的选择。它原生支持 range 模式，初始化即保证 start: [min, max] 合法，connect: true 自动高亮中间区间，update 事件返回数组，不用自己拼逻辑。
但要注意：它不替换语义，仍需包裹在 <label></label> 中，并手动把值同步到隐藏的 <input type="hidden"> 供表单提交——否则 screen reader 用户无法感知区间变化。
真正难的从来不是“怎么让两个滑块看起来像一根轨道上的两个把手”，而是让它们在任意交互路径（鼠标、触屏、键盘、屏幕阅读器、缩放、DPI 变化）下都维持 left ≤ right 这个不变量。这个约束一旦松动，后续所有业务逻辑（价格筛选、时间过滤、数据聚合）都会失效。
