浏览器会静默修正不满足 min + n×step 的 input value，导致交互异常；正确做法是确保 value 严格对齐合法刻度，金额类用“分”为单位，time 类型需换算秒数，动态改 step 后须手动重置 value 并校验。
value必须显式对齐step的数学约束
浏览器不会校验你写的value是否合法，但会静默修正它——只要value不满足 min + n × step（n为整数），Chrome、Safari 就可能把它改成最近的合法值，导致 spinner 按钮失灵、拖动卡顿、第一次点↑跳到意外数字。
常见错误现象：<input type="number" min="0" step="0.1" value="1.05"> 看似合理，实际浏览器可能悄悄把 value 改成 "1.0" 或 "1.1"，DOM 上看不出变化，但行为已异常。
- ✅ 正确写法：
value="1.0"、value="1.1"、value="0.0"（全部是0 + n × 0.1） - ❌ 错误写法：
value="1.05"、value="2.33"、value="0"（未补零，部分浏览器视为字符串解析失败） - 金额类场景建议绕过浮点：用“分”为单位，
min="100" step="1" value="199"表示 1.99 元
time类型中value必须秒数为0且分钟被step整除
type="time" 的 step 单位固定是秒，不是分钟，也不是字符串。写 step="30" 是每30秒一档（09:00 → 09:00:30 → 09:01:00），完全不是你想要的分钟粒度。
要实现「每30分钟一档」，必须换算：30 × 60 = 1800；「每15分钟」就是 900；「整点」即 3600。
- ✅ 合法
value："09:00"（隐含:00）、"14:30"（30 分钟档位，且秒数为 0） - ❌ 非法
value："09:07"（分钟不能被 30 整除）、"09:30:15"（含秒，破坏对齐） - 后端或 JS 初始化时也得确保传入的是
HH:MM格式，且分钟数能被步长整除
动态修改step后value必须立即重置
直接改 input.step = "0.25" 不可靠，浏览器不会自动重算合法值集合。旧 value 很可能已越界，导致拖不动、松手跳变、方向键失灵。
正确做法是先用 setAttribute 更新属性，再手动规整 value：
const input = document.querySelector('input[type="number"]');
input.setAttribute('step', '0.25');
input.value = (Math.round(parseFloat(input.value) / 0.25) * 0.25).toFixed(2);
- 别用
input.step = "0.25"，部分浏览器响应滞后或不触发重计算 - 重置
value后建议调用input.checkValidity()主动校验 - 快速连续切换
step时，用requestAnimationFrame延迟重置，避免状态残留
range滑块的value对齐比number更隐蔽
type="range" 的 step 决定滑块可停靠的刻度点。即使视觉上滑动平滑，实际取值仍强制对齐。但问题在于：这个对齐只在用户拖动或按方向键时生效，初始 value 若不合规，会导致滑块“卡住”或松手跳变。
例如：<input type="range" min="0" max="100" step="5" value="7">，浏览器可能静默把 value 改成 5 或 10，而你根本没意识到 DOM 已被改写。
- 调试技巧：打印
Array.from({length: 21}, (_, i) => 0 + i * 5)看真实刻度点 - min/max 与 step 必须构成等差数列，
min="1" max="10" step="2"的最大可选值是9，不是10 - 读取值时别直接信
input.value（返回字符串且可能被四舍五入），用parseFloat(e.target.value)+ 规整逻辑
复杂点在于：这种对齐不是 UI 层面的“显示误差”，而是底层数值约束。一旦初始值没对齐，后续所有交互都可能偏离预期——而你很难从 DevTools 里一眼看出浏览器已经偷偷改了 value。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
