step属性仅对type="number"、"range"、"time"、"date"、"datetime-local"、"month"、"week"生效；type="text"或"type=email"等无效，且type="date"多数浏览器忽略，type="datetime-local"和"time"的step单位为秒且需整数。
step属性只对哪些type生效
写step但没效果？大概率是type不对。它只在type="number"、type="range"、type="time"、type="date"、type="datetime-local"、type="month"、type="week"上起作用。给type="text"或type="email"加step，浏览器会解析但完全忽略——没箭头、不校验、stepUp()调用失败。
最常见误用：<input type="text" step="0.01">。想控小数精度？必须改成type="number"才触发步进逻辑。
type="date"的step多数浏览器直接忽略；type="datetime-local"的step单位是秒且只接受整数（如step="60"表示1分钟）；type="time"的step也是秒，15分钟得写step="900"。
step="0.1"为什么总报“值必须为 0.1 的倍数”
这不是拦截，是提交时原生校验在起作用：validity.stepMismatch被触发。浏览器要求输入值必须满足 value === min + n × step（n为整数）。比如min="0"、step="0.1"，合法值只有0、0.1、0.2……0.15不在此列，提交就被拦。
立即学习“前端免费学习笔记（深入）”；
- 用户手动输入
2.05，失焦或提交时，Chrome/Firefox 会四舍五入到最近合法值（2.0或2.1），Safari 可能截断为2.0 - 旧版 Chrome 曾把
step="0.1"静默转成step="1"，导致所有操作按整数跳 - 浮点精度问题真实存在：二进制无法精确表示
0.1，0.1 + 0.2 !== 0.3就是根源
安全做法是换单位：金额统一用“分”，设min="100"、step="1"、value="199"表示1.99元。
初始value不匹配step会导致静默修正
浏览器不会校验你写的value是否合法，但会静默修正它。如果value不满足value === min + n × step，Chrome 和 Safari 可能直接把值改成最近合法值，导致 spinner 点不动、拖拽卡顿、第一次点↑就跳到意外数字。
错误写法：<input type="number" min="0" step="0.1" value="1.05"> → 浏览器可能悄悄改成1.0或1.1，DOM里看不出变化。
正确写法：<input type="number" min="0" step="0.1" value="1.0"> 或 value="1.1"，确保初始值本身就是步长整数倍。
更稳妥的写法是统一小数位：min="0.00"、max="10.00"、step="0.01"，避免混用min="0"和step="0.01"。
动态改step后必须重置value
直接赋值el.step = "0.25"不可靠——浏览器不会自动重算合法值集合，旧value很可能已越界，导致拖不动、松手跳变、方向键失灵。
正确流程：
- 用
el.setAttribute("step", "0.25")，部分浏览器响应更稳定 - 立即重置
value：el.value = (Math.round(parseFloat(el.value) / 0.25) * 0.25).toFixed(2) - 快速连续切换时，加
requestAnimationFrame延迟执行重置，避免状态残留 - 改完立刻调用
el.checkValidity()，必要时el.reportValidity()提示用户
真正麻烦的从来不是写step，而是用户粘贴、拖拽滚动条、第三方输入法——这些操作都绕过步长约束，业务层必须用 JS 或后端兜底校验。
