在表单开发中，限制输入框只能输入数字，是一个看似简单却暗藏玄机的需求。很多开发者习惯在 keydown 事件里，通过判断 e.key 是不是 0 到 9 来拦截输入。这个方法在大多数时候能工作，但一旦遇到“死键”，防线就瞬间崩溃了。
所谓死键，指的是那些需要按两次才能输出一个字符的按键，比如用来输入重音符（´）、抑扬符（^）或波浪号（~）的按键。第一次按下时，系统在等待组合，e.key 可能返回一个特殊的 'Dead' 值，甚至空字符串。此时你的校验逻辑很可能放行了它，等到用户第二次按下字母键，一个带着重音的非法字符就悄无声息地溜进了输入框。
✅ 推荐方案：input事件 + 正则清洗（最佳实践）
要彻底绕过死键的时机陷阱，最稳健的思路是换个战场：不再试图在按键按下时预判，而是等输入实际发生后再清理。这就是 input 事件的用武之地。它会在输入框的值发生任何变化后触发，无论是键盘输入、粘贴、拖放还是浏览器自动填充，都能捕获到。
具体做法很简单，监听 input 事件，然后用一个正则表达式，把不合法的字符当场替换掉。
const inputNumeric = document.getElementById("numeric");
// 定义允许的字符集：数字、小数点、正负号
const illegalChars = /[^0-9\.\-\+]/g;
inputNumeric.addEventListener("input", function (e) {
const currentValue = e.target.value;
// 实时清洗：移除非法字符
e.target.value = currentValue.replace(illegalChars, "");
});
这个方案的优势非常明显：健壮、简洁，并且一劳永逸地覆盖了所有输入场景。不过，有几点需要注意：
- 小数点的处理：上面的正则允许出现多个小数点，这显然不符合数字格式。如果需要严格的小数校验，需要在替换后或提交前，增加额外的逻辑来验证格式（例如，确保小数点最多出现一次）。
- 负号的位置：同理，如果支持负数，通常需要限制负号只能出现在开头。
- 慎用 type=”number”：有人可能会想，直接用
不就好了？这里有个坑。原生的 number 输入框会允许输入 “e”、“E”（科学计数法）和多个 “.”，并且在不同浏览器和移动设备上的行为不一致。对于需要严格控制的数字格式，它并不是一个可靠的选择。
⚡ 进阶方案：keydown + paste 双事件拦截
虽然 input 事件方案是首选，但在某些特定场景下，比如需要实现审计日志（记录每次按键）或追求极致的防误触体验（在非法字符出现前就阻止），我们可能还是需要拦截默认行为。这时，可以采取一个组合策略。
思路是同时监听 keydown 和 paste 事件。对于按键，我们依然尝试判断；对于粘贴，则直接检查剪贴板内容。关键在于，我们承认 keydown 判断可能因死键而失效，但后续的 input 事件清洗会作为最终兜底。
const numericField = document.getElementById("numeric");
const checkInput = (e, isPaste) => {
let textToCheck;
if (isPaste) {
// 从剪贴板获取文本
const clipboardData = e.clipboardData || window.clipboardData;
textToCheck = clipboardData?.getData("Text") || "";
} else {
// 获取当前按下的键（注意死键问题）
textToCheck = e.key;
}
// 进行校验，这里以纯数字为例
if (/[^0-9]/.test(textToCheck)) {
e.preventDefault(); // 阻止默认输入或粘贴行为
}
};
numericField.addEventListener("paste", (e) => checkInput(e, true));
numericField.addEventListener("keydown", (e) => checkInput(e, false));
? 总结
处理数字输入校验，核心在于理解不同事件的触发时机和局限性：
- 首选
input事件配合正则清洗。这是最健壮、可维护性最高的方案，能无差别处理键盘输入、粘贴、语音输入等所有输入方式，完美规避死键问题。 - 避免单独依赖
keydown事件进行校验。由于其无法可靠处理死键等组合键行为，单独使用会留下安全漏洞。 - 构建纵深防御。在前端，可以将上述Ja vaScript方案与HTML5的
pattern属性（如）结合使用。但切记，前端校验永远是为了用户体验，真正的安全闸门必须设在服务端，进行最终的数据验证。
