浏览器不会自动修正stepmismatch时的input.value，需手动对齐合法值并调用reportvalidity()；动态改step必须用setattribute并重置value；金额输入应转整数单位规避浮点误差。
step 属性触发 stepMismatch 错误时，浏览器不会自动重置 value
用户手动输入 1.25、但 step="0.1" 且 min="0" 时，表单提交会报 Please enter a valid value. The two nearest valid values are 1.2 and 1.3. —— 这是 validity.stepMismatch === true 的表现。但此时 input.value 仍是 "1.25"，浏览器**不会主动改它**，也不会弹窗或清空。你得自己处理。
常见错误是以为加个 form.reset() 就能解决：它只恢复到初始加载时的 defaultValue，和当前 step 是否匹配无关。如果初始 value="1.05" 就已非法，reset() 后还是非法值，spinner 依然卡死。
- 必须先校验：
if (input.validity && input.validity.stepMismatch) - 再手动对齐：
input.value = (Math.round(parseFloat(input.value) / parseFloat(input.step)) * parseFloat(input.step)).toFixed(2) - 最后调用
input.reportValidity()主动触发提示（可选）
动态修改 step 后 value 不重置，会导致拖拽/方向键失效
比如把 input.step 从 "0.1" 改成 "0.25"，但没碰 input.value，那原来的 "1.1" 就不再属于新步长序列（min + n × 0.25），结果就是：拖不动滑块、按 ←→ 键跳变、点击 ↑ 按钮直接跳到 1.25 或 1.0。
根本原因不是 step 没生效，而是浏览器在每次交互前都会检查 value 是否仍在合法集合内；不合规就静默“拉回”最近合法值，造成 UI 卡顿或跳变。
- 必须用
input.setAttribute('step', '0.25')，而非直接赋值input.step = '0.25'（部分浏览器不响应后者） - 紧跟着重置 value：
const newStep = 0.25; input.value = (Math.round(parseFloat(input.value) / newStep) * newStep).toFixed(2) - 若连续切换 step，加
requestAnimationFrame(() => { /* 重置逻辑 */ })避免状态残留
金额类输入别碰浮点 step，用整数单位换算最稳
step="0.1" 在 Chrome 旧版可能被降级为 step="1"，Safari 对 0.1 的二进制表示不稳定，用户输完 1.99 提交却报错，后端收到的还是字符串，但前端校验已经崩了。
真实项目里，金额一律转“分”：min="100"、step="1"、value="199" 表示 1.99 元。这样完全避开浮点误差、浏览器兼容性、step 解析歧义三重坑。
- 显示层用 JS 格式化：
(value / 100).toFixed(2) - 提交前传整数，后端无需做小数截断
- 初始化、动态改 step、用户粘贴——全都不用担心精度对齐问题
step="any" 不是重置方案，而是放弃原生校验的兜底选择
设 step="any" 后，用户可以输任意小数（如 "3.1415926"），提交也不报 stepMismatch。但它带来的副作用很实在：stepUp() 和上下箭头退化为 ±1 整数步进，required 校验也可能失效。
这适合科学参数微调等场景，但绝不该用来“绕过重置难题”。如果你发现不得不靠 step="any" 才能让输入不报错，说明真正的问题是 min/step/value 三者没对齐，或者业务本就不该依赖原生 step 校验。
最麻烦的永远不是写 step，而是用户粘贴、第三方输入法、语音输入——这些行为完全绕过所有原生约束，step 形同虚设。真要可靠，得靠 input 事件监听 + 手动截断 + 后端兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
