html input[type="number"] 默认只接受整数，不设 step 时输小数会失败或被截断；valueasnumber 返回 nan 是因值未落在 min + n×step 合法序列上；inputmode="decimal" + step="any" 较稳妥，但需测试机型；应优先用 parsefloat(input.value) 替代 valueasnumber，并结合 validity 校验与手动步长对齐。
HTML input[type="number"] 默认只接受整数，不设 step 时输小数会失败或被截断——这不是 bug，是规范行为。
为什么输入小数后 valueAsNumber 变成 NaN？
浏览器内部对 type="number" 的解析严格依赖 min、max 和 step 三者组合。哪怕 DOM 中 value 是 "3.14"，只要它不落在 min + n × step 的合法序列上，valueAsNumber 就返回 NaN。
-
min="0"+step="1"→ 合法值：0、1、2…；输入"0.5"直接触发validity.stepMismatch === true -
min="0"+step="0.01"→ 合法值：0、0.01、0.02…；输入"0.005"也会报错 -
step="any"表示“不限制精度”，但部分安卓 WebView 会忽略它，仍只弹整数键盘
移动端小数点不显示？先检查 inputmode
inputmode 比 step 更直接影响键盘类型。iOS 和多数安卓浏览器优先按 inputmode 决定是否显示小数点键。
- 必须显式写
inputmode="decimal"，不能只靠step="0.1" -
inputmode="numeric"在某些安卓机型上只出数字键盘（无小数点） -
inputmode="decimal"+step="any"是目前最稳妥的组合，但需测试目标机型
如何安全地读取实时数值？别依赖 valueAsNumber
用户敲下 "-" 或 "." 的瞬间，valueAsNumber 必然为 NaN，此时监听 input 事件再读它，逻辑就断了。
- 用
parseFloat(input.value)替代input.valueAsNumber，它对中间态更宽容（如"-"返回NaN，但可手动判断） - 校验前先检查
input.validity.badInput或input.validity.stepMismatch，比反复 parse 更轻量 - 若需自动对齐步长（如输入
"4"在min="1"+step="2"下应转为"5"），得自己算：Math.round((val - min) / step) * step + min
step="any" 不等于“随便输”，它有隐含风险
step="any" 确实放开精度限制，但它会让浏览器放弃所有步长校验，包括原生箭头增减逻辑——点一下向上箭头可能跳到 1.0000000000000002，而不是你预期的 1.1。
- 它不解决粘贴超长小数（如
"3.14159265358979323846"）的问题 - 服务端收到这种值，浮点误差可能引发比较失败（比如
===判定不通过） - 真正需要高精度（如金融金额），建议用
type="text"+inputmode="decimal"+ JS 格式化（保留两位小数并四舍五入），而非依赖step="any"
精度控制的本质不是“让用户输得多准”，而是“让最终提交的值落在业务可接受的离散点上”。min/max/step 是声明式约束，inputmode 是体验层适配，而 parseFloat + 手动对齐才是可控落地的关键一环——尤其当用户能粘贴、拖拽、甚至改 DOM 的时候。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
