step仅对type="number"和type="range"有效；需确保value与min、step数学匹配，否则浏览器静默修正；动态改step须重置value；浮点误差应通过stepup()等原生方法规避。
step 属性只对 type="number" 和 type="range" 生效
给 type="text" 或 type="email" 加 step="0.01" 完全没用——浏览器解析但静默忽略，spinner 按钮不出现、上下键无效、校验不触发。必须显式写成：<input type="number" step="0.01">。type="range" 虽支持 step，但它的“跳变点”仅影响拖动和方向键行为，视觉上根本感知不到 step="0.001" 和 step="0.1" 的区别。
value 初始值不匹配 step 就会卡住
step 不是独立开关，它和 min、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="0.1" 点两次 ↑ 变成 0.30000000000000004 是浮点误差，不是 bug
这是二进制浮点表示 0.1 时的固有缺陷。旧版 Chrome 甚至会把 step="0.1" 当作 step="1" 处理。别自己写 parseFloat(val) + 0.1，改用原生方法：
-
input.stepUp(1)严格按当前step执行，不引入 JS 浮点误差 - 金额类场景，统一用“分”：
min="100" step="1" value="199"表示 1.99 元 - 必须用小数时，显式写满位数：
min="0.00" max="10.00" step="0.01"，避免min="0"和step="0.01"混用
step="any" 不是“关闭校验”，而是“退化为 ±1”
step="any" 不放开所有限制，它只是禁用步长对齐逻辑：
- 上下箭头、
stepUp()全部退化为整数增减：当前value="1.5"，点 ↑ 变成2.5，不是1.6 - 手动输入
"1.23456789"完全允许，表单提交前也不报stepMismatch - 它适合需要任意精度输入（如坐标、科学数据）且仍想保留原生 spinner 的场景，不是偷懒的“关闭校验”方案
- 真实麻烦从来不是写
step，而是用户粘贴、拖拽滚动条、第三方输入法——这些行为完全绕过step约束
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
