Vue el-input输入限制：键盘拦截、粘贴过滤与中文输入法兼容

这标题乍看是个小问题，其实是个典型的“看起来一分钟搞定，实际上线全是坑”的需求。日常工作里经常接到这种需求：这个输入框只能输数字，那个只能输字母下划线，还有的要允许小数点、要限制长度、要排除特殊字符。需求方往往就丢过来一句话，好像改个属性就能完事，但真正动手做的时候，你会发现涉及的东西远超预期：键盘事件、输入法组合态、粘贴拦截、正则边界、光标位置……每一个环节都可能翻车。

这篇就专门梳理一下在 Vue 生态里做 el-input（原生 input 也适用）输入限制的完整方案。不光是给一段能用的代码，还把每步推导的逻辑、为什么要拦这个事件、正则为什么要这么写都讲清楚，最后附上我自己踩过的一些坑。不管你是在做 Vue2 老项目还是 Vue3 + Element Plus，这套思路都可以直接搬过去。

1. 输入限制这块的常规套路拆解

1.1 方案一：v-model + 正则替换的“土办法”

先说很多人第一反应的做法：直接在 v-model 绑定的 setter 里过滤。Element UI / Element Plus 的 el-input，比较偷懒的写法是用 @input 事件去处理当前值，把不想要的字符 replace 掉。

<template> <el-input v-model="formData.username" placeholder="只允许数字、字母、下划线" @input="handleInput" /> </template> <script setup> import { reactive } from 'vue' const formData = reactive({ username: '' }) function handleInput(value) { formData.username = value.replace(/[^0-9a-zA-Z_]/g, '') } </script>

这个方案思路很简单，重点是理解[^0-9a-zA-Z_]这组正则的含意：它是“排除”写法，意思是“只要不是数字、不是大小写字母、不是下划线，一律拿掉”。g标志表示全局匹配，避免只删第一个非法字符。

它的优点是实现成本极低，一眼就能看懂，也几乎不会出现“绕过限制”的漏洞。因为不管字符是怎么进到输入框的——手敲、粘贴、拖拽、浏览器自动填充——最后都要过一遍这个 replace 过滤器。

缺点也很明显：它属于“先污染后治理”，不是真正意义上的拦截。用户打字的时候，会先看到非法字符闪了一下再被删掉。如果后面接了接口校验，可能因为 v-model 的值已经同步了但 DOM 里内容还没更新完，出现一瞬间的“脏值”。某些情况下（比如用户按下中文输入法的组合键），还可能触发两次 input 事件，导致光标跳动。

所以我的评价是：它适合“能跑就行、对体验要求不高”的场合，但生产环境里我更推荐下面这套事件级拦截方案。

1.2 方案二：拦截 keydown / keyup 键盘事件

这是从源头阻止非法字符进入输入框的做法。在 keydown 阶段判断这次按键是否合法，不合法直接preventDefault()，让字符根本没有机会出现在输入框里。

<template> <el-input v-model="formData.account" placeholder="只允许数字、字母、下划线" @keydown="handleKeydown" /> </template> <script setup> import { reactive } from 'vue' const formData = reactive({ account: '' }) function handleKeydown(event) { const allowedKeys = ['0','1','2','3','4','5','6','7','8','9', 'a','b','c','d','e','f','g','h','i','j','k','l','m', 'n','o','p','q','r','s','t','u','v','w','x','y','z', 'A','B','C','D','E','F','G','H','I','J','K','L','M', 'N','O','P','Q','R','S','T','U','V','W','X','Y','Z','_'] // 组合键和功能键直接放行，不拦截 if (event.ctrlKey || event.metaKey || event.altKey) return if (event.key.length > 1) return // key 是 'Shift'、'Backspace'、'ArrowUp' 这种 if (!allowedKeys.includes(event.key)) { event.preventDefault() } } </script>

这里有几个细节很多人第一次写会漏掉：

• event.key.length > 1这个判断是为了放行所有功能键和方向键。Backspace、Delete、ArrowLeft、ArrowRight这些 key 的字符串长度都大于 1，它们本身不是字符输入，但如果被拦截了，用户就没法删字、没法移动光标的左右键，输入框直接变成“只能输入不能修改”。
• 组合键Ctrl + C、Ctrl + V、Ctrl + A也要放行，否则用户的复制粘贴快捷键全都变成无效。
• 中文输入法下，用户按下一个字母（比如拼音的开头），keydown 会先触发，此时event.key可能是'Process'（老浏览器）或'Unidentified'，长度都大于 1，会被放行。这其实是好事，说明我们不用在键盘层面挡输入法，输入法的处理要单独在 composition 层面解决，后面第 2 节细说。

这个方案的优点是完全根治“闪烁”问题，输入框看起来非常干净，非法按键按下去不会有任何响应。缺点是它拦不住粘贴进来的内容，粘贴不是通过键盘事件产生的，用户选了一段“abc!@#”粘进来，keydown 根本不会触发，所以这个方案必须和 paste 拦截配合使用。

1.3 方案三：拦截 paste 粘贴事件

粘贴是非法字符最常见的“偷渡入口”。一个看起来人畜无害的输入框，用户从文档、网页、聊天记录里粘一段内容过来，什么符号都可能带进来。

拦截方式是在 el-input 上监听 paste 事件，读取clipboardData里的文本，过滤完再把合法的部分通过手动手段塞回输入框。

<template> <el-input v-model="formData.nickname" placeholder="只允许数字、字母、下划线" @paste="handlePaste" /> </template> <script setup> import { reactive, nextTick } from 'vue' const formData = reactive({ nickname: '' }) function handlePaste(event) { event.preventDefault() const text = event.clipboardData.getData('text') const cleaned = text.replace(/[^0-9a-zA-Z_]/g, '') if (!cleaned) return // 把过滤后的内容手动插入输入框当前位置 const input = event.target const start = input.selectionStart const end = input.selectionEnd const currentValue = input.value const newValue = currentValue.slice(0, start) + cleaned + currentValue.slice(end) formData.nickname = newValue // 恢复光标位置 nextTick(() => { input.selectionStart = input.selectionEnd = start + cleaned.length }) } </script>

这段逻辑相对复杂一点，但它做了一件很关键的事：保留了光标位置。网上很多简化版是直接formData.nickname = currentValue + cleaned，直接把过滤后的内容拼在末尾。那种写法在用户把光标放在中间粘贴的时候，新内容会跑到末尾去，用起来非常别扭。

还有一个注意点：为什么先event.preventDefault()？因为在大多数浏览器里，粘贴的默认行为是把原始剪切板文本原封不动插入。如果不阻止默认行为，我们在 after 阶段再试图“修复”，就会遇到一个困难——你已经无法准确知道这段粘贴插入到了什么位置，尤其当输入框里原本有内容时，修复起来非常痛苦。

1.4 方案对比与选择

我自己的推荐是：主力用 keydown 拦截 + paste 拦截，再用 v-model 的 replace 兜底。三层各管一段：keydown 管手敲，paste 管粘贴，replace 管那些防不胜防的边缘情况（比如浏览器自动补全、移动端手写输入、甚至部分输入法直接上屏的场景）。三层合在一起，才能真正做到“输入进不去、粘贴进不去、辅助功能也进不去”。

2. 中文输入法下必须处理的 composition 事件

2.1 为什么普通 keydown 拦截不住中文输入

如果你的业务要求“不能输入字母以外的字符”，那往往不需要做输入法兼容。但一旦业务改成“能输入中文但不能输入特殊字符”（比如昵称框允许中文），或者反过来“只允许数字英文下划线，但用户在中文输入法下按拼音键会被误杀”，你就必须理解 composition 事件。

中文、日文、韩文这类表意文字输入法有一个“组合输入”的过程。用户敲一堆拼音/假名，界面上会出现候选词，按空格或候选键之后才真正把汉字“定稿”上屏。在这个过程中，浏览器会触发一组compositionstart→compositionupdate（可能多次）→compositionend事件。

关键问题在于：在 composition 进行中时，输入框里的临时拼音文本也会触发 input / keydown 事件。比如用户用拼音输入“账号”的“账”，他先按 z、h、a、n、g，这 5 个字母的 keydown 都会命中我们的非法字符拦截逻辑，如果我在第 1.2 节里直接preventDefault()，用户会发现“中文根本打不出来”，或者打出几个孤零零的拼音字母。

所以网上常见的“@keydown 里把所有 A-Z 都放行”的做法，其实放进来的是拼音字母，不是实际想要的字符。想要真正放行中文，需要知道“当前是否处于输入法组合状态”。

2.2 用 isComposing 标志做状态感知

在 Vue 里，最干净的方式是给 el-input 绑定 compositionstart 和 compositionend，在 data 里维护一个isComposing标志：

<template> <el-input v-model="formData.realname" placeholder="可输入中文、数字、字母" :maxlength="20" @keydown="handleKeydown" @compositionstart="isComposing = true" @compositionend="handleCompositionEnd" /> </template> <script setup> import { reactive, ref } from 'vue' const isComposing = ref(false) const formData = reactive({ realname: '' }) function handleKeydown(event) { // 组合状态下不禁用按键，让输入法正常工作 if (isComposing.value) return const regex = /^[0-9a-zA-Z\u4e00-\u9fa5]$/ if (event.key.length === 1 && !regex.test(event.key)) { event.preventDefault() } } function handleCompositionEnd(event) { isComposing.value = false // 组合结束后再清理一遍，防止特殊字符混进来 const cleaned = event.target.value.replace(/[^0-9a-zA-Z\u4e00-\u9fa5]/g, '') formData.realname = cleaned } </script>

这个例子的业务规则改成“允许中文、数字、字母，但不允许下划线”，因为下划线在某些文本输入场景会产生奇怪的可读性问题（如果需求确实要下划线，把_加进正则即可）。

compositionstart触发的时间点非常早，基本在用户按下第一个拼音字母之前就触发，所以isComposing设为 true 之后，后续所有 keydown 都不会误伤拼音。compositionend触发于候选词上屏的那一刻，此时我们再对输入框整体做一次 replace 清场，防止用户通过某种方式在组合输入里夹带了非法字符。

这种“组合期内放行、组合结束后净化”的模式，是对输入法兼容比较稳妥的处理方式。类似的思路也适用于移动端 iOS/Android 的虚拟键盘。

提示：不要用 Vue 的@input去判断event.isComposing，这个属性在部分浏览器里不稳定。Vue 官方其实提供了一个@input的修饰符.trim，但它只处理首尾空格，和 composition 没有直接关系。组件的 input 事件在 composition 期间会触发多次，所以你很难在 @input 里区分“这次是组合中还是组合完”，反而容易搞出重复清理的 bug。

2.3 一个容易被忽略的坑：compositionend 晚于 input 派发

我曾遇到过一次诡异现象：某个输入框在中文输入法下，明明代码里在 compositionend 做了 replace，但屏幕上依然保留了非法字符。排查了很久，才发现是事件顺序的问题。部分浏览器在 compositionend 之后还会补发一次 input 事件，咱们如果在 handleCompositionEnd 里只改了 banner 字段，逻辑上没问题；但如果你在 handleSummary 里同时formData.realname = cleaned，紧接着那个补发的 input 事件又带着原始值覆盖了一遍，最终显示的还是脏值。

解决方式有两种：

1. 在 compositionend 里await nextTick()之后再赋值，确保晚于补发 input。
2. 改为在 @input 里统一判断isComposing，为 false 时才执行清理，compositionend 只负责把标志位改成 false。

第二种方式更简单，也是我后来一直用的。大概长这样：

<template> <el-input v-model="formData.realname" @input="handleInput" @compositionstart="isComposing = true" @compositionend="isComposing = false" /> </template> <script setup> import { reactive, ref } from 'vue' const isComposing = ref(false) const formData = reactive({ realname: '' }) function handleInput(value) { if (isComposing.value) return formData.realname = value.replace(/[^0-9a-zA-Z\u4e00-\u9fa5]/g, '') } </script>

注意这个写法有一个 Vue 特有的细节：@input里的回调拿到的第一个参数就是当前输入框的 value（Element 组件做了透传），而不是原生事件对象。对这个场景来说反而更简单，不用再event.target.value去取。

3. 各种业务场景下的规则配置与实现

3.1 常见规则清单

不同的业务，对输入内容的期待完全不同。我整理了五类最常见的规则，以及对应的正则，全部基于replace(/[^...]/g, '')的排除思想。

这里有个比较隐蔽的坑：括号里的\u4e00-\u9fa5这个中文字符范围看起来全，但一些生僻汉字、扩展区汉字并不在这个范围里，会有极少量汉字被误杀。如果你的业务真的需要完整收录所有 Unicode 汉字，比较稳妥的做法是换成 Unicode 属性转义\p{Script=Han}，但这类写法在 JavaScript 里需要启用u标志，Element 的某些内部处理不一定兼容。绝大多数业务用\u4e00-\u9fa5判断中文已经完全够用，至少我经手的项目里没有因为生僻字出过问题，但你要知道这个边界。

再说0-9.这个写法：如果你要允许输入小数，很多人会在正则里写\.来转义。实际上在字符组[]内部，点号\.和.是一样的，点号在字符组里不具备“任意字符”语义，写.就可以。同理，_也不用转义，0-9a-zA-Z_是标准写法。

3.2 配置化设计：一类输入框，多个规则

实际项目里不可能只遇到一种输入限制。今天 A 页面要数字，明天 B 页面要英文，后天 C 页面又变成“字母+数字+中划线”。如果每种需求都去复制一遍代码，项目里的 utils 会越来越臃肿，相互修改还容易漏。

我比较推荐把一个通用的校验函数抽象出来，接收一个正则或规则映射表，在不同的组件里复用：

// utils/inputRestriction.js const RULES = { number: /[^0-9]/g, numberDecimal: /[^0-9.]/g, account: /[^0-9a-zA-Z_]/g, chineseName: /[^0-9a-zA-Z\u4e00-\u9fa5]/g, emailLoose: /[^0-9a-zA-Z_@.]/g, noSpace: /\s/g } export function filterInput(value, rule = 'account') { const regex = RULES[rule] if (!regex) return value return value.replace(regex, '') }

然后在组件里：

<script setup> import { reactive, ref } from 'vue' import { filterInput } from '@/utils/inputRestriction' const props = defineProps({ rule: { type: String, default: 'account' } }) const isComposing = ref(false) const formData = reactive({ value: '' }) function handleInput(value) { if (isComposing.value) return formData.value = filterInput(value, props.rule) } </script>

这样一个带“规则配置”的输入组件就能覆盖绝大多数场景。将来新增规则，只需要在RULES里加一行，不需要动组件逻辑。

如果你连组件都不想封装，直接写一个自定义指令也会很香。Vue 3 的自定义指令可以在绑定元素时统一处理所有事件：

// 全局自定义指令：v-restrict app.directive('restrict', { mounted(el, binding) { const rule = binding.value || 'account' const rulesMap = { number: /[^0-9]/g, account: /[^0-9a-zA-Z_]/g // ... } el.addEventListener('keydown', (e) => { // 略 }) el.addEventListener('paste', (e) => { e.preventDefault() const text = e.clipboardData.getData('text').replace(rulesMap[rule], '') if (text) { // 手动插入 } }) el.addEventListener('input', (e) => { if (e.target.value) { e.target.value = e.target.value.replace(rulesMap[rule], '') } }) } })

指令的最大优势是不用在 Vue 模板块里写一堆事件绑定，但劣势是它针对的是原生元素，Element Plus 的 el-input 内部结构是div > input包裹，自定义指令挂载在 el-input 根节点上时，拿到的不是真正的 input 元素，需要通过el.querySelector('input')去找到内部输入框。这在依赖 Element 组件库的项目里会显得有那么一点点“脆弱”。

所以如果你是重度 Element 用户，直接在 el-input 上写事件还是最直白的做法；如果你用的是普通<input>，那自定义指令就是非常优雅的方案。

3.3 长度限制与实时计数

输入限制里还有一类常见需求：长度。有些场景是“超过 N 个字符就不让继续输入”，有些是“超出后提示但不截断”。

Element Plus 的 el-input 自带maxlength属性，且maxlength默认按字符长度计算，注意中英文字符长度在这里是一致的（都能被 maxlength 截断），但这只对原生输入行为有效。如果你在 @input 里做了 replace 赋值，那 maxlength 仍然有效——因为赋值给 v-model 之后，Vue 更新 DOM 时还是会走 maxlength 的截断逻辑。不过有几个细节值得注意：

• maxlength的截断是输入框显示上的截断，v-model的值在输入超长瞬间可能已经超了，@input里先拿到的 value 可能是超长版本。如果你的提交校验依赖 v-model 的最终值，建议在 @input 里也顺手slice(0, maxlength)。
• 如果配上show-word-limit，Element 会自动显示字数统计。在 el-input 这个show-word-limit的场景下，字数统计是按 value.length 来算的，所以你要是先 replace 后 slice，显示的字数就是过滤后的字数，不会把非法字符算进去。
• 有一种很隐蔽的情况：用户输入超长中文时，替换掉特殊字符之后，剩余字符数可能没超，所以不会截断，这大家都容易理解；但用户输入的是一串带着特殊符号的超长英文，先 replace 删掉符号再 slice，长度可能刚好符合要求。这个顺序最好和产品对齐，看他们关心的是“原始输入长度”还是“有效内容长度”。

我实际情况下用的比较多的是“先过滤，后截断”：

function handleInput(value) { if (isComposing.value) return const filtered = filterInput(value, props.rule) formData.value = filtered.slice(0, props.maxlength || 100) }

4. 实操过程：组合出一个完整版输入限制组件

前面拆了这么多原理，这一节直接给出一份能复制到项目里用的完整封装代码。我用 Vue3 + Element Plus 的 api 风格写，但是注释会写清楚原生 input 如何替换。

先贴组件模板：

<template> <el-input :model-value="modelValue" :placeholder="placeholder" :maxlength="maxlength" :clearable="clearable" @input="handleInput" @keydown="handleKeydown" @paste="handlePaste" @compositionstart="isComposing = true" @compositionend="isComposing = false" /> </template>

再贴 script：

<script setup> import { ref } from 'vue' const props = defineProps({ modelValue: { type: String, default: '' }, rule: { type: String, default: 'account' }, maxlength: { type: Number, default: 50 }, placeholder: { type: String, default: '' }, clearable: { type: Boolean, default: false } }) const emit = defineEmits(['update:modelValue']) const isComposing = ref(false) const RULES = { number: /[^0-9]/g, numberDecimal: /[^0-9.]/g, account: /[^0-9a-zA-Z_]/g, chineseName: /[^0-9a-zA-Z\u4e00-\u9fa5]/g, emailLoose: /[^0-9a-zA-Z_@.]/g } function filterValue(value) { const regex = RULES[props.rule] if (!regex) return value return value.replace(regex, '') } function handleInput(value) { if (isComposing.value) return const filtered = filterValue(value).slice(0, props.maxlength) emit('update:modelValue', filtered) } function handleKeydown(event) { if (isComposing.value) return if (event.ctrlKey || event.metaKey || event.altKey) return if (event.key.length > 1) return // 这里用正向匹配：判断单个字符是否允许 const allowedMap = { number: /^[0-9]$/, numberDecimal: /^[0-9.]$/, account: /^[0-9a-zA-Z_]$/, chineseName: /^[0-9a-zA-Z\u4e00-\u9fa5]$/, emailLoose: /^[0-9a-zA-Z_@.]$/ } const ruleRegex = allowedMap[props.rule] if (ruleRegex && !ruleRegex.test(event.key)) { event.preventDefault() } } function handlePaste(event) { event.preventDefault() const text = event.clipboardData.getData('text') const cleaned = filterValue(text).slice(0, props.maxlength) if (!cleaned) return const input = event.target const start = input.selectionStart const end = input.selectionEnd const currentValue = input.value const newValue = currentValue.slice(0, start) + cleaned + currentValue.slice(end) emit('update:modelValue', newValue) }

这段代码为什么这么设计？我再解释几个关键点：

• 用:model-value而不是v-model，是为了让组件成为受控组件。过滤逻辑统一在emit('update:modelValue', ...)里走，父组件拿到的永远是被整理过的值。
• keydown 的正向规则和 input 的过滤正则，两者看起来是重复的，其实目的完全不同。keydown 在做“事前拦截”，input 的 replace 在做“事后兜底”。只写一个，都有覆盖不到的场景。这两套规则解决了同一个需求从两个不同维度的生效。
• 如果你只想要“数字且允许小数点”，注意decimal规则下event.key如果是.，正向正则^[0-9.]$会放行，但用户可能在同一个输入框里输入多个小数点，比如1.2.3，这种语义上不合法的内容，正则和 keydown 都拦不住。这就需要额外加一个“是否已经存在小数点”的判断：

function handleKeydownNumberDecimal(event) { if (event.key === '.' && event.target.value.includes('.')) { event.preventDefault() } }

这属于业务规则里更精细的一种，需要在 handleKeydown 里拆分出 per-rule 的拦截函数来做，不能只靠一张全域表解决。

5. 常见问题与排查技巧实录

5.1 输入法下 input 事件重复触发

高频问题第一名。症状是：中文输入法下，用户输入拼音的过程中，候选字还没选，表单校验已经开始疯狂报错，或者过滤函数把“拼音中不符合规则的字母”当成非法字符删掉。

我前面说过，这需要在compositionstart和compositionend之间加 isComposing 开关。但还有一个隐藏点：有些浏览器（微信内置浏览器尤其多）在 compositionstart 之前也会触发一次 input，此时 isComposing 还没置 true，会被 handleInput 误处理。

保险的写法是给 handleInput 里加一个“判断当前是否有组合尚未结束”的降级方案：

function handleInput(event) { if (isComposing.value || event.isComposing) return // ... }

event.isComposing是标准原生事件上的只读属性，如果浏览器不支持，它就是 undefined，所以用||判断是安全的。这样至少能在那些“先 input 后 compositionstart”的诡异浏览器里兜住一部分。

5.2 光标总是跳到末尾

这基本是 replace 清空后直接赋值带来的接近现象。用户把焦点放在输入框中间，输入一个非法字符后想继续在原位置打字，结果发现光标被推到最后面。

原因：v-model 在赋值时会重建整个输入框 value，浏览器默认把光标放到最后。想要避免，做法是在赋值后手动恢复光标位置。但这里有一个时机问题：emit('update:modelValue')之后，父组件的 value 还没传到 input 上，必须nextTick()后再设置 selectionStart / selectionEnd。

我这里给一个恢复光标位置的工具函数：

import { nextTick } from 'vue' async function restoreCursor(input, position) { await nextTick() input.focus() input.setSelectionRange(position, position) }

需要说明的是，如果你用 keydown 事前拦截，因为非法字符压根没进去，就不存在光标跳动问题。光标跳动主要出现在 @input 做 replace 的时候，所以如果你极其在意光标的体验，优先把 keydown 拦截做扎实，这是治本。

5.3 手机端虚拟键盘不触发 keydown

移动端的大坑：很多 Android 输入法都不派发可信任的 keydown 事件，甚至 iOS 上也说不准。你会发现 PC 端运行良好的 keydown 拦截方案，在安卓手机上根本拦不住，特殊字符照样能打出来。

原因简单：虚拟键盘的按键根本不走物理键盘的 keydown 流程，输入法的每次上屏都是直接修改 input value，触发 input 事件。所以在移动端，唯一可靠的拦截点是 @input 里的 replace 过滤。

这也从侧面解释了为什么我第 1.4 节一定要强调“三层方案”缺一不可。PC 上 keydown 能拦 90% 的非法输入，移动端 input 过滤是最后防线。想要做到全端一致，除非起用更底层的东西（比如给 input 绑定 beforeinput 事件，它标准化程度更高一些），否则就用 input 清理。

5.4 beforeinput 事件能否替代一切

浏览器近年来规范化了beforeinput事件，理论上它触发在字符真正插入之前，能拿到即将插入的数据，并且可以 preventDefault。

input.addEventListener('beforeinput', (event) => { if (event.data && /[^0-9a-zA-Z_]/.test(event.data)) { event.preventDefault() } })

实际试过的感受是：Chrome、Firefox、Edge 都支持得不错，但在移动端 WebView 和一些国产浏览器内核里，兼容性不给你打包票。更重要的是，它同样面临输入法 composition 期间 data 为空或拼音内容的问题，所以不能完全替代 composition 方案，只能算是一层额外的“锦上添花”。生产环境我一般不动它，除非目标浏览器范围完全可控、且接收方明确支持现代语法。

5.5 特殊字符被正则误伤的经典案例

“需求是允许邮箱格式，用户输入a_b@xx.com时_又没被放行”——这是围绕“邮箱宽松规则”最常见的困惑。因为你正则里写了0-9a-zA-Z_@.，但少了一些现代邮箱用户名里可能出现的字符，比如+、-、%。如果产品要求“宽松校验”，建议不要手动维护白名单，改为直接在正则里排除空格和中文这类明确不合法的字符：

const emailLoose = /[^\w@.]/g

\w在 JavaScript 里等价于[A-Za-z0-9_]，不用手动打一整串字母数字，可读性和覆盖率都更好。注意\w只在 ASCII 下匹配，不含中文，所以中文会被当作需要被过滤的字符，这正好符合邮箱输入场景。

再补一个容易踩的真坑：\w会被点是Word类型字符，在正则里它的定义是“字母、数字、下划线”，但如果你在replace(/[^\w@.]/g, '')里用，效果就是保留A-Za-z0-9_@.。我多年前第一次用的时候以为\w包含中文字符，结果用户邮箱里的中文全被保留下来，后来才想起来 JavaScript 的\w是 ASCII 限定。

5.6 禁用输入和只读场景不要混用限制

有些产品同学会把“输入限制”和“输入框禁用、只读”混为一谈。其实区别很大：

如果你在业务中把 readonly 当输入限制用，用户会感到“明明是个输入框却什么都打不进去”，而且表单提交时只读字段依然会带值，容易造成数据误提交。输入限制的目标是引导用户输入合法内容，不是禁止输入。

6. 针对不同 Vue 版本的实现适配

6.1 Vue2 + Element UI 项目怎么做

老项目的处理方式几乎一模一样，区别主要在语法上：

• options API 里用data()存 isComposing；
• @input事件里用this.formData.xx = value.replace(...)；
• keydown 和 paste 拦截写法一致。

一个 Vue2 常见额外坑是：Element UI 早期版本的el-input在@input事件参数上，有时不是 value 而是原生事件对象（不同 minor 版本行为不一致）。稳妥做法是用v-model绑定 prop，在 @input 里通过event.target.value来拿值，避免依赖框架的事件参数行为。

6.2 Vue3 + Element Plus 的 v-model 单向循环要注意

我上面给出的完整组件里，没有用v-model="formData.xxx"来实现内部过滤，而是通过:model-value+emit('update:modelValue')做受控组件。为什么要这么绕？

因为如果在组件内部同时接收modelValue并直接修改它，Vue 的开发模式会报警告：Avoid mutating the prop directly。正确的单向数据流方向是“父传子、子通过事件再通知父更新”，然后父组件把新的值再传回来。在这个来回过程中，我们的过滤逻辑正好可以插入在emit之前。

如果你把组件改写成“内部维护一个 copy 的 value”，就会面临“父组件外部修改值但内部不生效”的同步问题，非常恼人。所以强烈建议用受控模式。

6.3 TS 环境的类型标注

如果你项目用 TypeScript，defineProps 的类型和事件类型可以这么标：

<script setup lang="ts"> import { ref } from 'vue' type RuleType = 'number' | 'numberDecimal' | 'account' | 'chineseName' | 'emailLoose' const props = defineProps<{ modelValue: string rule?: RuleType maxlength?: number placeholder?: string clearable?: boolean }>() const emit = defineEmits<{ (e: 'update:modelValue', value: string): void }>() const RULES: Record<RuleType, RegExp> = { number: /[^0-9]/g, numberDecimal: /[^0-9.]/g, account: /[^0-9a-zA-Z_]/g, chineseName: /[^0-9a-zA-Z\u4e00-\u9fa5]/g, emailLoose: /[^0-9a-zA-Z_@.]/g } </script>

TS 带来的最大收益是规则名不会再拼错。如果你把一个规则字符串从业务页面传进组件，传错了运行时不报错，但结果完全不可用。有了Record<RuleType, RegExp>后，传错直接编译报错，方便很多。

7. 我自己长期使用的小组件封装经验与收尾建议

个人经验，无论封装得多漂亮，输入限制这件事永远绕不开“业务预期”的确认。你在动手前必须先跟提需求的人把以下三件事问清楚，否则很可能白做：

1. 要不要支持中文输入？如果需要，必须上 composition 方案，不能只靠单纯的 keydown 白名单。
2. 要不要限制长度？限制的是过滤前长度还是过滤后长度？二者在中文和特殊符号混输时差异很大。
3. 非法字符是“静默丢弃”还是“弹出提示”？静默丢弃省事，但用户可能完全不知道自己的输入被改了；弹出提示需要额外写交互逻辑。

这三件事不定下来，代码写得再精细，产品验收时都可能一句“我不是这个意思”全部推翻。

再分享一个小技巧：写输入过滤时，正则的测试用例一定要准备齐。我习惯把这几类测试数据放到一个数组里，每次改完正则跑一遍：

const testCases = ['abc123', 'ABC_123', '你好世界', '!@#$%^&*()', ' 空格 ', '1.2.3', 'a_b@test.com']

看输出结果是否符合预期，比光靠肉眼在输入框里试要快得多。一旦涉及边界情况（空格、连续特殊字符、空字符串、纯数字串），这组测试用例的价值就体现出来了。

代码上的核心思路最后再总结三句话：

• keydown 管手敲，paste 管粘贴，input 管兜底，三个阶段缺一不可。
• 中文输入法必须识别 isComposing 状态，否则不是误杀就是漏网。
• 组件封装要走受控模式，把过滤逻辑收敛到一个函数里，业务上通过 rule 参数控制行为。

这个方案在我目前手头的项目里已经稳定跑过一阵子，覆盖过纯数字、小数、账号、中文姓名、邮箱宽松等多种规则，PC 端和移动端都比较稳。如果你在实现过程中遇到正则写法或光标恢复的问题，可以按照上面第 5 节的排查顺序走一遍，大概率能直接定位到问题点。