<input type="range"> 的 value 始终为字符串，需用 Number() 或 valueAsNumber 转换；实时监听用 input 事件而非 change；step 约束合法值，浮点易致精度偏差，推荐整数缩放；移动端应保障热区尺寸并禁用缩放，优先使用原生控件以保可访问性。
range input 的基本行为和取值方式
浏览器原生 <input type="range"> 默认不提交值，且 value 始终是字符串——哪怕你设了 step="1"，input.value 仍是 "5" 而非数字 5。直接用它参与计算会隐式转为字符串拼接，比如 input.value + 1 得到 "51" 而不是 6。
获取当前数值的正确做法是显式转换：
const slider = document.querySelector('input[type="range"]');
const num = Number(slider.value); // 推荐，比 parseInt 更安全（能处理小数）
// 或 slider.valueAsNumber（仅支持现代浏览器，IE 不支持）
注意：valueAsNumber 在 min/max 未设置或非法时返回 NaN，而 Number(value) 更可控。
监听滑动过程中的实时变化
用 input 事件，不是 change。后者只在松手后触发一次，前者在拖拽过程中持续触发，适合做实时反馈（如预览、联动计算）。
常见错误是绑定 change 后发现“滑动时不更新”，本质是事件选错了。
-
input：每次值改变即触发（包括键盘上下键、鼠标拖拽、触屏滑动） -
change：仅在元素失去焦点且值发生过改变时触发（对 range 来说，基本等价于松手那一刻） - 不要用
mousemove或touchmove手动读取位置——绕过原生逻辑，破坏可访问性且难兼容
设置 step、min、max 时的精度陷阱
step 不仅控制点击轨道时的跳变步长，更关键的是约束用户最终能选中的所有合法值。如果 min="0"、max="1"、step="0.01"，那 0.333 就永远无法被精确选中——浏览器会自动向下取整到最近的合法值（如 0.33）。
这会导致两个问题：
- 显示值和实际值不一致（UI 显示
0.333，但value是"0.33"） - 若后端校验严格按 step 校验，可能拒绝看似合法的输入
-
step="any"可绕过限制，但失去步进语义，且部分旧版 Safari 对其支持不稳定
建议：明确业务需要的最小粒度，用整数倍放大（如百分比用 min="0" max="100" step="1"，再除以 100），避免浮点误差干扰。
移动端 touch 交互的兼容性补救
某些 Android WebView 或老版本 iOS Safari 中，input[type="range"] 的 touch 支持较弱：滑动迟滞、松手后跳回、甚至不响应。这不是 bug，而是原生控件在 Webview 中渲染层缺失所致。
务实解法不是重写整个滑块，而是加一层轻量级防御：
- 确保
<input>有足够触摸热区（最小尺寸建议 ≥44×44px，可用padding扩展） - 禁用默认缩放：
<meta name="viewport" content="width=device-width, user-scalable=no"> - 极少数场景下需 fallback：监听
touchstart→ 手动触发focus()，再监听touchmove模拟拖拽（仅当原生完全失效时才启用）
大多数现代环境无需额外处理，优先信任原生 range——它自带键盘导航、屏幕阅读器支持、高对比度模式适配，这些自定义实现很难完整覆盖。
