stepMismatch触发时validationMessage返回浏览器默认提示（如“值必须为0.1的整数倍”），具体文案因浏览器而异；需用setCustomValidity()动态设置并清空，不可依赖原生step校验做业务精度控制。

stepMismatch 错误触发时，validationMessage 返回什么

当 input type="number" 的值不满足 min/max/step 组合规则（比如 value="3.14" 但 step="0.1"），浏览器会将 input.validity.stepMismatch 设为 true，此时 input.validationMessage 通常返回类似“值必须为 0.1 的整数倍”这样的文案——但具体措辞由浏览器决定，Chrome 和 Safari 不一致，且无法直接修改。

用 setCustomValidity() 覆盖 stepMismatch 提示的正确时机

不能在 input 事件里无条件调用 setCustomValidity()，否则会卡死校验状态。必须先判断是否真出错，再设文案；校验通过时必须清空并触发反馈：

• 监听 input 或 blur 事件，检查 input.validity.stepMismatch 是否为 true
• 若为 true，调用 input.setCustomValidity("请输入符合精度要求的数字，例如保留两位小数")
• 若为 false，**必须**先 input.setCustomValidity("")，再调用 input.reportValidity()（仅需一次，用于刷新 UI）
• 注意：reportValidity() 在 display: none 或不在 <form> 内时静默失败

step="any" 能绕过 stepMismatch 吗？它有什么副作用

step="any" 确实会让 validity.stepMismatch 永远为 false，但它不解决底层问题：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 输入 "123.456789" 后，input.valueAsNumber 在 Safari 可能截断为 123.45678900000001，parseFloat(input.value) 也可能失真
• input.value 仍是字符串，提交到后端前你仍要自己解析和校验
• 旧版 iOS Safari 会忽略 step="any" 并回退到 step="1"，务必加 JS 兜底判断
• 如果同时用了 min 或 max，却没设 step，Chrome 控制台会警告，并隐式启用 step="1"

真正可控的提示方案：放弃依赖原生 step 校验

原生 step 校验不可靠，尤其涉及浮点精度或业务特定格式（如“金额必须两位小数”）。更稳的做法是：

立即学习“前端免费学习笔记（深入）”；

• 把 input 改成 type="text"，加 inputmode="decimal" 和 pattern="[0-9]*\.?[0-9]*"
• 监听 input 事件，用正则过滤非法字符（如多个小数点、开头负号后跟小数点），保留原始字符串
• 提交前用 const num = parseFloat(value) + isFinite(num) + 业务精度检查（如 value.split(".")[1]?.length <= 2）
• 错误时调用 input.setCustomValidity("金额须为数字，且最多两位小数")，再 input.reportValidity()

stepMismatch 提示看似是浏览器的事，实际是浮点精度、输入方式、浏览器实现差异共同暴露的接口裂缝。越想靠它做业务精度控制，越容易掉进验证通过但数值已错的坑里。