step 属性不能精确控制浮点增减，精度控制必须依赖整数换算、初始值对齐和 stepUp/stepDown 方法；0.30000000000000004 是 JS 浮点误差所致，非浏览器 bug；金额应以“分”为单位，小数场景需补零并用 stepUp/stepDown；value 必须满足 min + n×step，否则触发静默修正；动态改 step 后需重置 value；step="any" 实为退化为 ±1 整数步进，不关闭校验；粘贴、拖拽等行为绕过所有原生约束。
step 属性本身不能“精确控制”浮点增减，它只定义合法值序列的数学规则；真正能靠得住的精度控制，必须靠整数换算、初始值对齐和原生 stepUp/stepDown 方法。
为什么 step="0.1" 点两次 ↑ 变成 0.30000000000000004
这不是浏览器 bug，是 JavaScript 浮点数在二进制中无法精确表示 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" - 别手动算
parseFloat(val) + 0.1，改用input.stepUp(1)—— 它严格按当前step执行，不走 JS 浮点运算
value 初始值不满足 min + n × step 就会卡住
浏览器会静默修正非法 value，导致拖不动滑块、点 ↑ 跳到非预期值、spinner 按钮失灵。这不是 UI 问题，是数学约束未满足。
-
min="1"且step="0.3"时，合法值是1.0、1.3、1.6、1.9… 所以value必须显式设为其中之一（如value="1.0"） - 动态改
step后，必须立刻重置value：input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2) - 推荐用
input.setAttribute('step', '0.25')而非直接赋值input.step = '0.25'，部分浏览器响应更稳定
step="any" 不是“不限制”，而是“退化为 ±1”
step="any" 仅禁用步长对齐逻辑，上下箭头和 stepUp() 全部退化为整数增减，且表单验证不再触发 validity.stepMismatch。
立即学习“前端免费学习笔记（深入）”；
-
value="1.5"时点 ↑，变成2.5（不是1.6） - 用户仍可手动输入任意小数（如
"1.23456789"），提交前也不报错 —— 业务校验必须由 JS 或后端兜底 - 它适合科学坐标、高精度参数等需要自由输入但又想保留原生 spinner 的场景，不是偷懒的“关闭校验”方案
最麻烦的从来不是写 step，而是用户粘贴、拖拽滚动条、第三方输入法——这些行为完全绕过所有原生约束，step 根本不起作用。
