step属性只控制合法停靠点，不决定渲染精度；必须确保min、max、step构成等差数列，否则浏览器自动截断；小数步进易因浮点误差失准，推荐整数缩放或js主动校准。
range input 的 step 属性到底控制什么？
step 并不决定滑块“能不能跳过中间值”，而是规定合法取值的最小增量。只要 min、max 和 step 三者能构成等差数列（即 (max - min) % step === 0），滑块就只会在这些离散点上停驻；否则浏览器会自动截断到最接近的合法值，但用户仍可能拖出“非预期”的中间值（尤其在移动端或低精度拖拽时）。
怎么确保滑块真正在指定数值间跳跃？
光靠 step 不够，必须配合 min 和 max 精确对齐。比如想做“10 / 25 / 40 / 55”四个档位：
- 设
min="10"、max="55"、step="15"→ 合法值为 10, 25, 40, 55 ✔️ - 设
min="10"、max="60"、step="15"→ 合法值是 10, 25, 40, 55，但 60 不合法（因为60 - 10 = 50，50 ÷ 15 ≈ 3.33），此时滑块可能卡在 55 或“假性停在 60”（实际 value 是 55）⚠️ - 用 JS 主动校准：监听
input事件，把event.target.value四舍五入到最近的合法步进点，再赋回.value
遇到小数步进（如 0.1）为什么总不准？
浮点数精度问题会让 step="0.1" 实际产生 0.30000000000000004 这类值。解决方法只有两个：
- 改用整数倍数：比如想支持 0.1～1.0 每 0.1 步，就设
min="1"、max="10"、step="1"，然后 JS 层除以 10 显示和使用 - 不依赖浏览器自动对齐，完全用 JS 控制：隐藏原生滑块，用
div+mousedown/mousemove模拟，点击/拖拽时只允许落到预设数组中的值（如[10, 25, 40, 55]）
移动端 touch 事件下 step 容易失效的原因
某些 Android 浏览器（尤其旧版 Chrome）对 range 的 step 解析不严格，拖动时 value 会连续变化。这时候必须加兜底：
- 监听
change（而非仅input），因为change在释放后才触发，更稳定 - 在 handler 里用
Math.round((value - min) / step) * step + min强制取整，再写回value - 避免同时监听
input和change做重复校准，否则可能触发两次 DOM 更新
真正起作用的是 min/step/max 三者的数学关系，不是 step 单独说了算；JS 校准不是“锦上添花”，而是跨端一致性的必要手段。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
