原生 range 滑块需显式设置 min、max、step、value 才可靠，监听 input 而非 change 事件以获取实时值，移动端需加 touch-action: manipulation 并扩大热区。
原生 <input type="range"> 不是“加个标签就能用”的控件，漏掉 min、max 或 value 会导致行为不一致甚至失效；它默认不显示数值、不响应键盘微调（除非有 step）、移动端热区小——这些不是 bug，是设计使然。
为什么 range 滑块拖动没反应或值不变
常见原因是监听了 change 事件而非 input。前者只在松手后触发一次，拖动中完全静默；后者在每次值变化时都触发，包括鼠标拖拽、触屏滑动、键盘方向键操作。
-
input事件能拿到实时字符串值，比如slider.value是"42"，必须用Number(slider.value)或+slider.value转数字才能计算 - 如果绑了
change，用户拖到 60 就停住，UI 还显示旧值，体验断裂 - 别用
oninput="handler()"行内写法，不利于复用和测试 - React/Vue 等框架中，若直接改 DOM 的
value属性却不同步 state，会退化为非受控组件，后续拖动失效
min/max/step/value 必须显式设置才可靠
浏览器对未设属性的 fallback 差异大：Chrome 默认 min="0" max="100" value="50"，Safari 可能忽略未设 value 的初始状态，IE 直接不渲染。不要依赖默认值。
-
min和max必须是合法数字字符串（如"0"、"100"），不能带单位或空格 -
value必须落在[min, max]内，否则被浏览器静默修正为min（例如min="10" max="20" value="5"→ 实际起始值是"10"） -
step不写等价于step="1"；要支持小数必须显式声明，如step="0.1"或step="any" - 精度陷阱：设
min="0" max="1" step="0.01"，用户永远选不到0.333，浏览器会自动取最近合法值（0.33），后端校验可能失败
双滑块区间选择只能靠两个 range + JS 约束
HTML 原生不支持单个 <input type="range"> 有两个滑块。所谓“双滑块”都是 JS + CSS 模拟，强行 hack 单个元素会导致无障碍崩溃、移动端触摸逻辑混乱、键盘导航失效。
- 用两个
<input type="range">，分别设id="minRange"和id="maxRange" - 二者
min、max、step必须完全一致，否则边界无法对齐（比如一个step="1"，另一个step="5"，min永远追不上max） - 监听双方的
input事件，实时校验并修正越界：if (+minInput.value > +maxInput.value) minInput.value = maxInput.value - 配合
<output for="minRange maxRange"></output>显示区间，但内容必须手动更新：output.textContent = `${minInput.value}–${maxInput.value}`，不能依赖<output></output>自动计算
移动端滑块卡顿、点不中？先加这行 CSS
iOS Safari 和部分安卓 WebView 中，input[type="range"] 拖动迟滞、松手跳回，本质是浏览器为保留双指手势预留了处理空间。这不是代码问题，是平台限制。
- 加
touch-action: manipulation到滑块样式里，告诉浏览器：“这个元素只处理单点拖动，不用留缩放/滚动余量” - 同时扩大热区：
width: 100%或用padding包裹，避免手指点在轨道边缘失焦 - 别为了“统一外观”强行重置所有伪元素样式——
::-webkit-slider-thumb和::-moz-range-thumb支持能力不同，圆角在 Firefox 里得用background-image模拟 - 真要跨平台像素级一致？用
<div> + <code>mousedown/touchstart自实现，但代价是放弃原生可访问性和键盘支持最易被忽略的是：value 始终是字符串，哪怕你写了
value="42"；step 不仅影响点击轨道跳变，更硬性约束合法值集合；双滑块方案里两个 input 的step必须一字不差——差一个字符，区间就卡死。
