step属性仅定义min+n×step等差数列的合法值集合，不保证每次增减精确等于step；step="0.1"触发0.30000000000000004是因0.1二进制无法精确表示，导致模运算误差引发stepMismatch校验失败。
step 属性不能直接“实现精度控制”，它只定义合法值集合的数学规则；真要控精度，得靠整数换算、初始值对齐和 stepUp()/stepDown() 方法。
为什么 step="0.1" 点两次 ↑ 变成 0.30000000000000004
这不是浏览器 bug，是 JavaScript 浮点数在二进制中无法精确表示 0.1 导致的底层误差。Chrome 旧版本甚至会把 step="0.1" 静默降级为 step="1"。你看到的“跳变异常”“拖不动”“点一下跳两格”，八成是这个误差在触发浏览器内部的 validity.stepMismatch 校验。
-
step定义的是min + n × step这个等差数列，不是“每次加减 step” - 浏览器实际用
Math.abs((value - min) % step) 判断是否合法 - 别手写
v % step === 0做校验，它在小数场景下必然翻车 - 测试时直接查
input.validity.stepMismatch比肉眼观察更可靠
step="any" 并不是“关闭校验”，而是退化为 ±1 整数步进
step="any" 仅禁用步长对齐逻辑，上下箭头和 stepUp() 全部退化为整数增减，且表单验证不再触发 validity.stepMismatch。但它不解决浮点精度问题，也不影响 parseFloat() 解析行为。
- value="1.5" 时点 ↑，变成 2.5（不是 1.6）
- 用户仍可手动输入任意小数（如 "1.23456789"），提交前也不报错 —— 业务校验必须由 JS 或后端兜底
- 部分旧版 Safari 和 Edge 会忽略
step="any"，降级为step="1" - 若必须用
type="number"，请同时设置min、max和step="any"，否则 Chrome 会报 warning 并启用默认步长
金额类输入必须用“分”为单位，别碰小数 step
金额场景一律用整数单位：设 min="100"、step="1"、value="199" 表示 1.99 元。这是唯一能彻底避开浮点误差、跨浏览器一致、且无需 JS 补救的做法。
立即学习“前端免费学习笔记（深入）”；
- 不要写
min="0.00" max="10.00" step="0.01"——0.01同样无法精确表示，误差在两位小数放大 - 若非用小数不可，统一补零：
min="0.00"、max="10.00"、step="0.01"，并确保所有值字符串化后带两位小数 - 动态改
step后，必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2) - JS 调用增减时，优先用
input.stepUp(1)，它严格按当前step执行，不走 JS 浮点运算
step 生效的前提：type、min、value 必须全部对齐
step 只对 type="number" 和 type="range" 生效；没设 type，或 type="text"，step 形同虚设。而且它不是孤立开关 —— min 是起点，value 必须落在 min + n × step 上，否则浏览器静默修正，导致 spinner 失灵、拖拽卡顿、第一次点击 ↑ 就跳到意外数字。
- 错误写法：
<input type="number" min="0" step="0.1" value="1.05">→ 浏览器可能悄悄改成1.0或1.1 - 正确写法：
<input type="number" min="0" step="0.1" value="1.0">或value="1.1" - 移动端 iOS Safari 的 number 键盘甚至不保证显示小数点，
step="0.1"可能让用户根本输不了小数 - 粘贴、拖拽滚动条、第三方输入法完全绕过所有原生约束，
step在这些场景下不起作用
最麻烦的从来不是写 step，而是用户行为不可控——键盘方向键、鼠标滚轮、触摸滑动、粘贴、输入法上屏……这些操作要么绕过校验，要么触发隐式修正。真正可靠的精度控制，永远建立在服务端校验 + JS 主动规整 + 整数单位设计这三层之上。
