step属性仅对type="number"、type="range"、type="datetime-local"生效；type="text"等无效，且value必须满足value===min+n×step，否则浏览器静默修正。
step 属性只对哪些 type 生效
只有 type="number"、type="range"、type="datetime-local" 这三类 input 才真正响应 step；写在 type="text" 或 type="email" 上，浏览器解析但完全忽略——spinner 按钮不出现、增减无效、校验不触发。常见错误是：<input type="text" step="0.01"> 看似想控精度，实则等同于没写。
step="0.1" 为什么点两次 ↑ 变成 0.30000000000000004
这不是 bug，是浮点数在二进制中无法精确表示 0.1 导致的底层误差。Chrome 旧版本甚至会静默把 step="0.1" 当作 step="1" 处理。解决方法不是硬扛浮点运算：
- 金额类场景，统一用“分”：设
min="100"、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)，它严格按当前step执行，不引入 JS 浮点误差
value 初始值不匹配 step 就会卡住
step 不是独立开关，它和 min、value 构成数学约束：value 必须满足 value === min + n × step（n 为整数）。否则浏览器静默修正——你拖不动滑块、点 ↑ 却跳到非预期值、spinner 按钮失灵，八成卡在这儿。
- 例如：
min="1"、step="0.3"，却设value="1.0"→ Chrome 可能悄悄改成1.2或让控件失效 - 安全写法：
min="0.0"、step="0.1"，则value必须是"0.0"、"0.1"、"0.2"… 之一 - 动态改
step后，必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2)
step="any" 不是“不限制”，而是“退化为 ±1”
step="any" 并不放开所有限制，它只是禁用步长对齐逻辑：
立即学习“前端免费学习笔记（深入）”；
- 上下箭头、
stepUp()全部退化为整数增减：当前value="1.5"，点 ↑ 变成2.5，不是1.6 - 仍校验是否为合法数字（不能输
"abc"），但不再触发validity.stepMismatch - 手动输入
"1.23456789"完全允许，表单提交前也不报错——业务上必须靠 JS 或后端兜底 - 它适合需要任意精度输入（如坐标、科学数据）且仍想保留原生 spinner 的场景，不是偷懒的“关闭校验”方案
真实麻烦从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法，这些行为完全绕过 step 约束——它只管受控增减，不管自由输入。
