step仅对type="number"和type="range"生效，合法值由min + n×step决定，非简单取模；step="any"禁用对齐但不放开其他约束；浮点误差需用整数单位规避。
step 属性不是输入过滤器，也不是四舍五入开关，它只定义“哪些值算合法”，仅在特定场景下起作用——理解这点，就能避开 80% 的误用。
step 只对 type="number" 和 type="range" 生效
给 type="text" 或 type="tel" 加 step，浏览器完全无视，控制台也不会报错。它只在 type="number"（影响上下箭头、键盘方向键、checkValidity()）和 type="range"（松手时自动吸附到最近合法点）中被解析。其他类型如 date 虽也支持，但规则不同（例如 step="7" 表示按周跳转，step="0.5" 会被静默忽略）。
合法值由 min + n × step 决定，不是 value % step === 0
浏览器判断一个值 v 是否合法，用的是 (v − min) % step ≈ 0（浮点安全比较），而非简单看 v 是否为 step 的整数倍。这意味着：
-
min="1.5" step="0.2"→ 合法值是1.5、1.7、1.9… -
min="1" step="0.3"→1本身不满足(1 − 1) % 0.3 === 0？等等，0 % 0.3 是 0，所以它理论上合法；但实际中 Chrome 可能因浮点误差静默修正value到1.2，Safari 可能直接放行——行为不一致的根源就在这儿。 -
value初始值必须显式满足该公式，否则浏览器可能卡顿、跳变或静默覆盖。
step="any" 不等于“随便输”，它只是禁用步长对齐
step="any" 的真实含义是：取消对齐逻辑，但不放开其他约束。
- 用户可手动输入任意精度小数（如
3.1415926），表单提交时不会触发validity.stepMismatch - 但上下箭头和
stepUp()/stepDown()仍按 ±1 整数增减（哪怕当前值是2.5，点 ↑ 变成3.5，不是2.6） - 粘贴、拖动 range 滑块、第三方输入法等操作依然绕过所有原生限制——这些地方
step根本不参与
浮点精度问题会让 step="0.1" 失效，别硬扛
0.1 在二进制中无法精确表示，导致：
- 用户输入
0.3，浏览器校验时算出(0.3 − 0) % 0.1 !== 0，报“值必须为 0.1 的倍数” - 连续调用
stepUp(1)两次，可能得到0.30000000000000004 - 旧版 Chrome 曾把
step="0.1"直接降级为step="1"
解决办法不是加 toFixed()，而是换思路：min="0" 改成 min="0" 且单位下沉——金额用“分”，设 min="0" max="10000" step="1"；时间用毫秒，滑块映射再转换。真正需要小数时，统一用两位小数写法：min="0.00" step="0.01"，并确保 value 初始值也带两位小数。
最常被忽略的其实是初始值与 min/step 的对齐关系——哪怕属性都写对了，只要 value 不落在合法序列上，后续所有交互都可能异常。这不是 bug，是设计使然。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
