step 属性仅定义合法值对齐点而非拖动精度，浏览器在松手时强制将值对齐到 min + n × step；value 初始值或动态设置必须满足该规则，否则被静默修正，小数步长应转整数单位或用字符串避免浮点误差。

step 属性只定义合法停靠点，不是“拖动精度”

浏览器渲染滑块时，并不按 step 值切分像素轨道；它只是在松手瞬间把当前值强制对齐到最近的 min + n × step 点。用户拖动过程看似连续，但最终落点受 step 约束——这是绝大多数“卡顿”“跳变”“拖不动”的根源。

常见错误现象：

• min="0" step="0.1" value="0.15"：该 value 非法，Chrome 会静默修正为 0.1 或 0.2，DOM 中 input.value 看不出变化，但后续 JS 计算可能错乱
• 移动端 iOS Safari 对 step 小于 0.1 的支持极不稳定，部分版本直接降级为 step="1"

value 初始值必须满足 step 规则，否则浏览器自动修正

设了 min、max、step，不代表 value 就能随便写。浏览器加载时会校验：value === min + n × step（n 为整数）。不满足？就悄悄改掉。

实操建议：

立即学习“前端免费学习笔记（深入）”；

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 手动写 value 时，用计算式确保合法，比如 min="0.5" step="0.25" → 合法 value 只能是 "0.5"、"0.75"、"1.0"…别写 value="1.1"
• 动态生成时，用 Math.round((val - min) / step) * step + min 得到合规值，再转成字符串赋给 value
• 改完 step 后，必须重置 value，否则旧值大概率越界；推荐用 el.setAttribute("step", "0.25") + 重算 value + el.checkValidity()

小数步长慎用浮点运算，优先转整数单位

step="0.1" 在二进制中无法精确表示，JS 加减后容易出现 0.30000000000000004 这类误差。这不是 bug，是底层限制。

更稳妥的做法：

• 金额类场景：用“分”为单位，min="100" max="9999" step="1" value="199" 表示 1.99 元
• 必须用小数时，统一用两位小数字符串：min="0.00" max="10.00" step="0.01"，避免 min="0" step="0.01" 混用
• 微调操作别手写 parseFloat(val) + 0.1，改用原生 input.stepUp(1)，它严格按当前 step 执行，不走 JS 浮点

step="any" 不等于“无约束”，它只是关闭对齐逻辑

step="any" 会让浏览器放弃 min + n × step 校验，但带来新问题：

• 键盘上下键退化为 ±1 整数增减（哪怕当前值是 1.5，点 ↑ 变成 2.5，不是 1.6）
• input.stepUp() 和 input.stepDown() 失效，只能靠 JS 手动算
• 用户粘贴 1.23456789 或第三方输入法输入仍被允许，checkValidity() 不报 stepMismatch，业务层必须兜底校验

真正难处理的从来不是写 step，而是用户绕过所有原生约束的操作——这些地方，step 根本不起作用。