HTML原生<input type="range">不支持双值范围选择，因其仅有一个value属性且无minValue/maxValue接口；需用单range伪区间、双div手动实现或第三方库方案补足。
HTML 原生 <input type="range"> 本身只支持单点选择，无法直接实现“范围选择”（即双滑块选区间），所谓“HTML 滑块优化范围选择”，本质是绕过原生限制，用组合方案补足。
为什么不能直接用 type="range" 实现双值范围
浏览器规范里 <input type="range"> 只有一个 value 属性，DOM 上没有 minValue/maxValue 或类似接口；强行加两个 range 元素会失去联动约束（比如右滑块不能小于左滑块），且视觉上无法共用一条轨道。
- 原生不支持
multiple或range类型的双值语义 - 通过 CSS 重置两个滑块位置容易错位，尤其在缩放或不同 DPI 屏幕下
- 移动端 touch 事件穿透、拖拽冲突常见，
input和change事件触发节奏不一致
用单个 range + 自定义显示实现伪范围（轻量级方案）
适合仅需“显示区间提示”、不强制用户精确拖动两端的场景，比如价格筛选器显示「¥200–¥5000」但实际只提交一个中心值或预设档位。
- 保持一个
<input type="range">，用data-min/data-max存储业务范围 - 监听
input事件，把当前value映射为百分比，再按比例算出左右边界（例如：滑块值 0.6 → 左=40%，右=80%） - 用
<output>或<span>动态更新文本提示，CSS 用background: linear-gradient()模拟已选区间高亮 - 注意：此法无法真正限制用户选择「左 > 右」，仅作视觉反馈，后端仍需校验区间合法性
<input type="range" id="priceSlider" min="0" max="100" value="50"> <output id="rangeLabel">¥200 – ¥5000</output>
用 div + mousemove/touchmove 手动实现双滑块（可控性最强）
当必须支持独立拖动左右端点、实时约束（左 ≤ 右）、自定义样式或复杂交互（如吸附刻度、键盘微调）时，放弃原生 range，改用绝对定位的两个 <div class="thumb"> + 轨道容器。
立即学习“前端免费学习笔记（深入）”；
- 监听容器的
mousedown/touchstart，判断点击落在哪个 thumb 上，标记activeThumb = 'min' | 'max' - 在
mousemove中根据鼠标 X 坐标计算新位置，用Math.min/Math.max强制约束区间（如newMin = Math.min(newX, maxPos)） - 避免使用
getBoundingClientRect()频繁重排，缓存轨道宽度和偏移量 - 移动端务必同时处理
touchmove并调用event.preventDefault()防止页面滚动 - 键盘支持：给 thumb 添加
tabindex="0"，监听keydown处理方向键和 PageUp/PageDown
第三方库选型关键看这三点
如果项目允许引入依赖，noUiSlider、ion-rangeslider 或 @melt-ui/slider（基于 Headless UI）更稳妥，但要注意：
-
noUiSlider的start参数传数组即可启用双滑块，但默认不渲染 label，需手动绑定update事件更新 DOM -
ion-rangeslider已停止维护，v2.3.1 后不再更新，Chrome 115+ 出现 thumb 错位 bug，不建议新项目使用 - 若用 React/Vue，优先选框架原生兼容方案（如 MUI
Slider的value支持数组），避免 DOM 操作与虚拟 DOM 冲突 - 所有库在 SSR 环境下首次渲染时，需延迟初始化到
useEffect或onMounted钩子中，否则报document is not defined
双滑块真正的复杂点不在拖拽逻辑，而在边界同步、无障碍支持（ARIA 属性要分别标注两个 thumb 的 role/label）、以及缩放/横竖屏切换时的位置重算——这些细节一旦漏掉，用户在 iPad 或 Windows 缩放 125% 下就会卡住。
