type="number"无法阻止非数字粘贴，需JS监听paste和input事件并正则过滤；valueAsNumber对格式敏感易返回NaN，建议用parseFloat()；移动端min/max/step兼容性差，应改用type="text"+inputmode；表单提交时后端必须校验并转换数字类型。
type=number 不能阻止非数字粘贴
浏览器原生 type="number" 只校验按键输入（比如按字母键无效），但对粘贴（Ctrl+V）完全放行——用户粘贴 "abc"、"12.3.4" 甚至 "1e5" 都能进输入框，提交时才可能报错或被截断。
真正需要“只接受数字”时，得靠 JS 拦截粘贴事件 + 实时过滤：
- 监听
input事件，用正则/^-?\d*\.?\d*$/检查当前值（注意：允许空字符串、负号、小数点，但不允许多个小数点或负号在中间） - 对
paste事件调用event.preventDefault()，再读取剪贴板内容，清洗后手动设值 - 别只信
change事件——用户可能没失焦就提交了表单
valueAsNumber 返回 NaN 的常见原因
input.valueAsNumber 看似方便，但它对格式极其敏感：只要值不是纯数字字符串（如 "123"、"-45.6"），就直接返回 NaN。空值、带空格、科学计数法（"1e2"）、全角数字、甚至末尾小数点（"7."）都会触发。
实际用法建议：
立即学习“前端免费学习笔记（深入）”；
- 优先用
parseFloat(input.value)替代valueAsNumber，它容错更强（自动忽略尾部非数字字符） - 如果必须用
valueAsNumber，先trim()再判断是否为有效数字字符串，避免静默失败 - 注意：Safari 对
valueAsNumber的实现比 Chrome 更严格，同一串值在不同浏览器可能表现不一致
min/max/step 在移动端的兼容性陷阱
这些属性在桌面端表现稳定，但在 iOS Safari 和部分安卓 WebView 中常失效：滑动选择器不响应 min、step 被忽略、甚至整个 type="number" 回退成文本框。
真实场景下更可靠的方案是：
- 用
type="text"+inputmode="decimal"（iOS/Android 键盘自动弹出数字键盘） - 配合 JS 校验范围和步长逻辑，而不是依赖原生属性
- 避免设
step="any"—— 它在部分旧版浏览器中会导致valueAsNumber始终为NaN
form 表单提交时 type=number 的隐式转换风险
当表单用 GET 提交时，type="number" 的空值会变成空字符串（name=&），而非被忽略；若设了 required 但用户绕过前端校验（比如禁用 JS），后端收到的仍是空字符串或非法字符串，不是数字。
关键提醒：
- 后端绝不能信任前端传来的“数字字段”，必须做类型转换 + 范围校验
- 不要用
parseInt()直接转——它会把"12px"变成12，而parseFloat()或Number()更安全 - 如果业务要求整数，别只靠
step="1"，要额外检查value % 1 === 0
最麻烦的其实是小数精度问题：用户输 0.1 + 0.2，JS 计算结果是 0.30000000000000004，这种细节在金额类输入里根本绕不开。
