step属性需与min、max、value对齐才生效，仅type="number"或"range"支持，初始value必须满足value===min+n×step，否则浏览器静默修正导致交互异常。
step 属性不是设了就自动生效的开关，它必须和 min、max、value 三者对齐，否则浏览器会静默修正值——你点不动、拖不顺、提交报错，八成卡在这儿。
type="number" 或 type="range" 才支持 step
给 type="text" 或 type="tel" 写 step="0.1" 完全无效，浏览器解析但不执行，DevTools 里能看到属性，但 spinner 按钮、方向键、校验全无反应。必须显式声明：<input type="number" step="0.1"> 或 <input type="range" step="0.25">。
-
step对date、time、week等类型也有效（如step="7"表示按周跳） -
step="any"不是“不限制”，而是禁用步长对齐逻辑：手动输入任意小数允许，但上下箭头和stepUp()会退化为 ±1 整数增减 - 省略
step时，type="number"默认为step="1"；但若min="0.5"，Chrome 可能推导出step="0.5"，Firefox 则不会——跨浏览器行为不一致，务必显式写
value 初始值必须满足 value === min + n × step
这是最常被忽略的硬约束。浏览器不会校验你写的 value 是否合法，但会在加载时静默修正它。比如 min="0" step="0.1" value="1.05"，Chrome 可能悄悄改成 1.0 或 1.1，DOM 中看不出变化，但后续拖动/点击就会跳变或卡住。
- 正确写法：
<input type="number" min="0" step="0.1" value="1.0">（确保1.0 === 0 + 10 × 0.1） - 错误写法：
<input type="number" min="1" step="0.3" value="1.0">→1.0不满足1 + n×0.3，第一个合法值其实是1.3 - 移动端 iOS Safari 对
step 支持极差，部分版本直接降级为 <code>step="1"，慎用
浮点精度问题真实存在，别信 0.1 + 0.2 === 0.3
step="0.1" 在二进制中无法精确表示，旧版 Chrome 曾静默四舍五入为 step="1"；点两次 ↑ 后显示 0.30000000000000004 是 JS 浮点误差，不是 bug。
立即学习“前端免费学习笔记（深入）”；
- 金额类场景一律用整数单位：
min="100"（对应 1.00 元）、step="1"、value="199"（对应 1.99 元） - 必须用小数时，统一小数位数：
min="0.00"、max="10.00"、step="0.01"，避免混用min="0"和step="0.01" - 实现 ± 按钮时，别用
parseFloat(val) + 0.1，改用原生input.stepUp(1)和input.stepDown(1)，它们严格按当前step执行，不走 JS 浮点运算
动态修改 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) - 快速连续切换
step（如从 0.01 切到 1）时，加requestAnimationFrame延迟重置，避免状态残留 - 改完立刻调用
el.checkValidity()主动校验，必要时el.reportValidity()提示用户
真正麻烦的从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法——这些行为完全绕过所有原生约束，step 根本不起作用。
