step 属性仅定义合法值序列的数学规则，不自动对齐；初始 value 必须满足 value === min + n × step，否则浏览器静默修正导致交互异常。
step 属性不是“设了就自动对齐”的开关，它只定义合法值序列的数学规则；value 初始值必须满足 value === min + n × step（n 为整数），否则浏览器静默修正——这是拖不动、点不准、跳变异常的根源。
type="number" 的 step 必须配合 min 和 value 对齐
浏览器不会校验你写的 value 是否合法，只在交互时强制对齐到最近的 min + n × step 值。一旦初始值不满足该式，用户还没点箭头，输入框内部状态就已经错乱。
-
min="0"且step="0.1"时，value="0.15"是非法的 → Chrome 可能悄悄改成"0.1"或"0.2"，但 DOM 中input.value看不出变化 - 正确写法：
min="0.00"、step="0.01"、value="1.99"（注意补零，避免浮点隐式转换） - 金额类场景强烈建议用整数单位：设
min="100"、step="1"、value="199"表示 1.99 元，显示时再除以 100
step="0.1" 点两次 ↑ 变成 0.30000000000000004？不是 bug，是 JS 浮点误差
0.1 在二进制中无法精确表示，parseFloat("0.1") + 0.1 + 0.1 必然失真。浏览器原生 stepUp() 方法内部绕过了 JS 浮点运算，所以更可靠。
- ❌ 别手动算：
input.value = (parseFloat(input.value) + 0.1).toFixed(2) - ✅ 改用原生方法：
input.stepUp(1)（严格按当前step执行） - ✅ 按钮点击后可加格式化：
input.value = parseFloat(input.value).toFixed(2)，避免界面上出现超长小数 - ⚠️ 旧版 Chrome 曾把
step="0.1"静默四舍五入为step="1"，现在虽已修复，但兼容性仍需警惕
动态改 step 后滑块/数字框失灵？重置 value 是必须动作
直接赋值 input.step = "0.25" 不会触发浏览器重算合法值集合，旧 value 很可能已越界，导致后续所有交互失效。
立即学习“前端免费学习笔记（深入）”；
- ✅ 推荐写法：
input.setAttribute('step', '0.25')（部分浏览器响应更稳定） - ✅ 紧接着重置 value：
input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2) - ✅ 快速连续切换时，加
requestAnimationFrame延迟执行重置，避免状态残留 - ✅ 改完立刻调用
input.checkValidity()主动校验，必要时input.reportValidity()提示用户
step="any" 并不等于“不限制”，而是退化为 ±1 整数步进
step="any" 只禁用步长对齐逻辑，不关闭其他校验，也不允许任意精度输入——上下箭头和 stepUp() 全部退化为整数增减。
- 若当前
value="1.5"，点 ↑ 变成2.5（不是1.6） - 用户仍可手动输入
"1.23456789"，提交前也不会报validity.stepMismatch - 粘贴、拖拽滚动条、第三方输入法等行为完全绕过
step约束，业务层必须用 JS 或后端兜底 - 适合科学坐标、高精度参数等需要自由输入但又想保留原生 spinner 的场景，不是偷懒的“关校验”方案
真正麻烦的从来不是写 step，而是用户粘贴、拖拽、输入法上屏这些绕过所有原生约束的行为——step 在这些场景下根本不起作用。
