step属性仅对type="number"和type="datetime-local"有效，设小数易因浮点精度校验失败，推荐改用整数单位或JS手动校验。
直接用 step 属性，但必须配合 type="number" 才生效；设成小数时大概率因浮点精度校验失败，别硬扛，得换思路。
step 只对 type="number" 和部分时间类型起作用
step 不是万能的：它对 type="text" 完全无效，对 type="date" 也基本被忽略（iOS/Android 均不按 step 跳周），只有 type="number" 和 type="datetime-local" 是明确支持的场景。
在 type="datetime-local" 中，step 单位是秒，且必须是整数——step="3600" 表示 1 小时，step="60" 表示 1 分钟；设成 step="30.5" 会被截断为 30。
- 移动端 Safari 的数字键盘不随
step变化，始终只提供整数键 - Android Chrome 长按小数点后最多输一位，
step="0.01"在那里几乎没意义 - 屏幕阅读器一般不播报
step值，也不会提示“步长不匹配”
为什么 step="0.1" 输入 0.3 会校验失败
这不是 bug，是浏览器内部用 (value - min) % step === 0 判断合法性，而 0.1 在 IEEE 754 中无法精确表示，导致余数计算偏差。
立即学习“前端免费学习笔记（深入）”；
例如：min="0" step="0.1" value="0.3"，实际计算可能是 0.30000000000000004 % 0.1 !== 0，结果为 false。
- 推荐用整数单位替代：金额存“分”，
step="1"，显示时除以 100 - 或改用
step="0.01"+min="0"+ JS 格式化显示，避免用户直接输0.1 - 禁用原生验证，用 JS 手动校验：
Math.abs((parseFloat(val) - min) % step)
min/max 和 step 共同决定合法值序列
min 不是“起点”，而是下界；浏览器会向上取最近的合法值作为第一个可选值。
比如：min="1" step="5"，第一个合法值是 5（因为 1 不满足 (1 - 1) % 5 === 0）；min="1.5" step="0.2"，合法值从 1.5 开始，然后是 1.7、1.9、2.1……
- 若
min="1" max="2" step="0.3"，部分浏览器会忽略step验证，仅保留 UI 增量行为 -
value初始值必须满足value === min + n × step，否则 Chrome 会静默修正，导致拖动卡顿或跳变 - 动态修改
step后，要立刻重置value并调用checkValidity()
想自定义箭头点击行为？别监听 click，用 change 事件
浏览器不暴露步进器箭头的 DOM 节点，也无法直接监听其 click。但每次点击箭头导致值变化并失焦时，一定会触发 change 事件。
你可以借此做自定义逻辑：比如后端要求精度到 0.00000001，但希望箭头一次增减 0.01，那就设 step="any" 或极小值，再在 change 里用 parseFloat + 四舍五入修正。
- 不要依赖
input.stepUp()处理小数，它仍走浮点运算；优先用原生方法，如el.stepUp(1) - 粘贴、开发者工具改值、输入法绕过等行为，
step完全无约束——服务端必须重验 -
step="any"不等于“放开一切”：上下箭头仍按 ±1 整数增减，且不触发stepMismatch
真正麻烦的从来不是写 step，而是用户粘贴非法值、第三方输入法绕过所有原生约束、以及旧版 WebView 对 step 的降级处理——这些地方 step 根本不起作用。
