step合法性判断公式为(value−min)%step===0，但因浮点误差需用Math.abs((v-min)%step)<Number.EPSILON校验；type="number"、min、max、step必须共存才生效。
step 属性的合法性判断公式是 (value − min) % step === 0
浏览器不检查 value 是否为 step 的整数倍，而是以 min 为起点构建等差数列。例如 min="1.5" step="0.2"，合法值是 1.5、1.7、1.9…；但若写成 min="1" step="0.2"，1 不满足 (1 − 1) % 0.2 === 0？实际是 0 % 0.2 === 0，所以 1 是合法起点——问题出在浮点误差：0.2 在二进制中无法精确表示，导致部分浏览器计算 (1.2 − 1) % 0.2 ≠ 0，进而触发 validity.stepMismatch。
验证时别手写 v % step === 0，应改用：
Math.abs((v - min) % step) < Number.EPSILON
DevTools 中直接查 input.validity.stepMismatch 比肉眼观察更可靠。
step="0.1" 为什么总校验失败
这不是 bug，是 IEEE 754 浮点数模型的必然表现。0.1 在内存中实际存储为 ≈0.10000000000000000555，累加三次后得到的 “0.3” 实际是 0.30000000000000004。浏览器用这个近似值参与模运算，自然不等于 0。
-
step="0.1"+min="0"→ 输入 "0.3" 会触发stepMismatch -
step="0.01"更危险：0.01 同样无法精确表示，且误差在小数点后两位放大 - 金额类场景必须用整数单位：比如以“分”为单位，
step="1"，避免所有浮点陷阱
微调按钮点击后 value 变化不等于 +step
点击上下箭头或按键盘方向键时，浏览器不是简单执行 value += step，而是查找最接近的合法值：即满足 min ≤ v ≤ max 且 Math.abs((v - min) % step) < EPSILON 的最近数。
这意味着：
- 当前值是 0.7、
step="0.3"、min="0"→ 点“+”不会跳到 1.0（因为 (1.0 − 0) % 0.3 ≠ 0），而是跳到 0.9 - 初始
value="0.15"配step="0.1"→ 失焦后可能被自动修正为 0.1 或 0.2，取决于浏览器实现 - 用
input.stepUp(1)比手动赋值安全：它内部走的是同一套查找逻辑，并触发input和change事件
type="number" 的 step 不生效的常见原因
最常踩的坑不是数值问题，而是类型或配置缺失：
- 写了
step="0.1"但没设type="number"→ 完全被忽略（type="text"或type="email"下 step 无效） -
step="any"或省略step→ Chrome/Edge 微调按钮消失，用户只能手输 -
step="0,5"（逗号小数点）→ 解析失败，等价于未设置 - 没配
min或max→ 合法性校验失去基准，stepMismatch判断失效 - 移动端 iOS Safari 对
step支持弱，尤其小数步长下微调按钮常不显示，需靠 JS 补按钮或监听手势
真正起作用的从来不是 step 单独，而是 type、min、max、step 四者共同构成的约束空间。漏掉任意一环，精度控制就断在半路。
