type="number"是step生效的前提；小数步长因浮点精度问题导致四舍五入，金额应使用整数单位；动态修改step需同步重置value并格式化；±按钮应调用stepup/stepdown而非parsefloat运算。
type="number" 是 step 生效的前提
step 属性在 type="text"、type="tel"、type="email" 上完全被忽略——DevTools 能看到属性，但 spinner 不出现、上下键无效、checkValidity() 不触发 stepMismatch。这不是 bug，是规范行为。必须显式写成 <input type="number" step="0.01">，否则一切配置都白搭。
小数步长失效的真正原因不是浏览器，是浮点精度
step="0.1" 在二进制中无法精确表示，旧版 Chrome 曾静默降级为 step="1"，Safari 可能截断输入值。用户输 0.15 失焦后变成 0.2 或 0.1，这是浏览器按规范做的四舍五入（满足 (value - min) % step === 0），不是可禁用的“矫正”。
- 金额类场景一律用整数单位：min="100"、step="1"、value="199" 表示 1.99 元
- 必须用小数时，统一补零：min="0.00"、max="10.00"、step="0.01"，避免混用 min="0" 和 step="0.01"
- 地理坐标、科学数据等需任意精度的，用
step="any"，但注意：此时stepUp(1)退化为 +1 整数，不是 +0.1
动态修改 step 后 value 不对齐，交互就崩了
直接赋值 input.step = "0.25" 不可靠。浏览器不会重算合法值集合，旧 value 很可能已越界，导致 spinner 卡死、拖动跳变、点击箭头跳到非预期值。
- 改用
input.setAttribute("step", "0.25")，部分浏览器响应更稳定 - 紧接着重置
value：input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换 step 时，加
requestAnimationFrame延迟执行重置，避免状态残留 - 改完立刻调用
input.checkValidity()，必要时input.reportValidity()提示用户
± 按钮别手写 parseFloat 加减
用 parseFloat(val) + 0.1 必然遇到 0.1 + 0.2 === 0.30000000000000004。这不是 step 的问题，是 JS 数值模型的固有表现。
- 优先调用原生方法：
input.stepUp(1)和input.stepDown(1)，它们严格按当前step执行，不走浮点运算 - 按钮点击后，建议再做格式化：
input.value = parseFloat(input.value).toFixed(2)，避免界面显示超长小数 - 粘贴、拖拽滚动条、第三方输入法输入的内容，完全绕过所有原生 step 约束——业务校验必须由 JS 或后端兜底
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
