做后台管理系统的时候肯定绕不过一类组件金额输入框。el-input本身是纯文本输入如果不做任何限制用户能往里面塞各种奇怪内容——字母、符号、空格、甚至带上emoji提交到后端以后要么报错要么让校验弹窗变得异常狰狞。标题里的“限制只能输入价格格式”看起来是个小需求真做起来又有不少细节正则怎么写才不误杀中间状态中文输入法会不会把拼音首字母塞进输入框粘贴一段“12.3.4元”怎么处理失焦之后需不需要自动补两位小数。这篇文章我把整个思路和踩过的坑从头到尾捋一遍直接给出一套能落地的方案。我习惯把这类需求拆成三层防线来处理输入过程实时过滤、失焦时格式化兜底、表单提交时再校验一次。三件事各司其职单靠某一个环节都会出问题。比如只做表单校验用户输入阶段依然能看见一堆乱码体验很差只做输入过滤不校验某些边界情况比如直接粘贴一个异常值可能漏过去。所以全部都要但各自管好自己的事。1. 需求拆解与方案选型1.1 为什么不能只靠表单校验很多刚接触这个需求的人第一反应是写一个校验规则提交时告诉用户“请输入正确金额”。这个思路本身没错但它解决的是“提交后发现问题”而不是“输入时不出问题”。设想一个场景用户在金额框里敲了个“1.2.3”他其实自己也没意识到多输了一个小数点直到点击提交被告知格式错误。接着他得回头逐字检查到底哪里错了这个来回折腾的过程非常影响体验。所以在输入的一瞬间就把非法字符过滤掉让用户根本没有机会输入错误格式这才是这个需求真正的核心价值。另外一点是价格输入框通常意味着后端要接收到一个干净的数据。如果提交之前再让后端处理脏数据很容易出现精度问题或类型问题。与其在接口层做各种防御不如在最源头就把格式限定死。1.2 typenumber 为什么是条歪路有人会说El-input的type设成number不就行了这个方案看起来省事实际用起来坑很深。先说e的问题。在大部分浏览器里typenumber的输入框是允许输入字母e的因为那是科学计数法的一部分。用户压根不懂什么是科学计数法只是觉得“怎么还能输字母”。加减号也是同理number类型原生允许正负号但价格通常不该出现负号。滚动滚轮还会自动改值这个在桌面端很容易误触表格页面手一滑金额就变了而且很难排查。更麻烦的是不同浏览器对这个输入框的表现不一致。某些移动端浏览器的number键盘并不是纯数字键盘有的会显示带小数点的符号键盘有的展示全数字键盘设计上很不统一。而且它无法直接限制小数位数你输入“1.234”el-input的v-model能拿到这个值除非额外处理否则它就会原样传给后端。typenumber的定位是“提交前允许用户输入数字类型”不是“格式化为价格”两者的目标完全不一样。所以我的选择是type继续用text靠手动控制过滤逻辑这样行为完全可控不再依赖浏览器差异。1.3 三层防线的整体设计第一层在input事件里实时过滤。每次用户敲键盘、粘贴、拖拽内容时把不符合价格格式的字符全部去掉。这一层负责保证输入框里永远不会出现脏数据。第二层在blur失焦时做格式化。价格一般来说应该保留两位小数但用户输入过程中不应该强迫他必须按两位去敲那样很反人类。失焦以后把0.5格式化成0.50把1.230格式化成1.23把空值处理成空字符串或者回退成0让数据以一个规范的状态进入下一环节。第三层表单校验。这一层不是为了抓脏字符而是为了保证语义正确比如输入不能为空、不能超过业务允许的最大金额、小数位最多两位等。前面两层已经保证了格式第三层保证的是业务规则。2. 核心实现正则过滤与控制逻辑2.1 正则搭配要选对逐字判断和整体判断不一样先看一个很多人直接拿来用的正则/^\d(\.\d{0,2})?$/这个正则看起来很完美整数部分至少一位小数部分可以有但最多两位。然而直接拿它在input事件里做校验一输入就出问题。你初始化的时候输入框是空的用户刚打开页面还没敲数字此时空字符串在被校验时会失败。用户输入“1.”的时候其实是合法的中间状态但上面这个正则也会失败因为\d要求整数部分至少一位“1.”最后那个点是合法的但正则不允许字符串末尾悬着一个点。如果直接用这个正则做“非法即拦截”用户连“1.5”都输不进去。正确的思路是过滤非法字符时应该用“允许出现的字符”集合来过滤而不是用完整格式规则来否决一切。我的做法是用这个正则去替换掉非法字符let filteredValue value.replace(/[^\d.]/g, );这行代码会把所有不是数字和小数点的字符全部删掉。但这样还不够干净比如“1.2.3”这种数字和小数点都是合法字符不会被上面的正则清掉所以还需要做下一步约束。2.2 在 input 事件里做逐字过滤完整思路可以这样写拿到用户输入的值先去掉非法字符再处理小数点和长度的限制最后回填到输入框。function formatInput(value) { // 1. 去掉所有非数字和小数点的字符 let result String(value).replace(/[^\d.]/g, ); // 2. 只保留第一个小数点后面的小数点全部删除 const firstIndex result.indexOf(.); if (firstIndex ! -1) { result result.slice(0, firstIndex 1) result.slice(firstIndex 1).replace(/\./g, ); } // 3. 限制小数位最多两位这个限制放在输入过滤里避免用户输入 1.234 if (firstIndex ! -1) { const integerPart result.slice(0, firstIndex); let decimalPart result.slice(firstIndex 1); decimalPart decimalPart.slice(0, 2); result integerPart . decimalPart; } // 4. 限制整数位数比如最多7位对应最大金额9999999.99 const dotIndex result.indexOf(.); const intPart dotIndex -1 ? result : result.slice(0, dotIndex); if (intPart.length 7) { result dotIndex -1 ? intPart.slice(0, 7) : intPart.slice(0, 7) result.slice(dotIndex); } return result; }这里有一个很多人会忽略的细节强制把过滤后的值回填给输入框时光标位置会跳。比如用户输入了一大串数字中间发现输错了想删掉一位输入事件触发后输入框内容被重新赋值光标直接跳到末尾这种体验很糟糕。解决办法是记录光标位置并恢复const pos input.selectionStart; const newValue formatInput(input.value); if (newValue ! input.value) { input.value newValue; // 光标位置做一定的偏移修正 const newPos Math.min(pos, newValue.length); input.setSelectionRange(newPos, newPos); }具体偏移需要看过滤掉了几个字符。如果用户在光标前输入了一个非法字符过滤会删掉它此时光标应该保持在原位置或回退一位如果用户输入的是合法内容光标正常前进。这里不追求绝对完美但至少要保证光标不会乱跳到末尾。2.3 边界情况小数点开头、多个小数点、负号小数点开头的情况比如用户输入“.5”。中间状态是允许的因为用户可能接下来会补一个0变成“0.5”。所以过滤逻辑里不能一看到开头是小数点就删除。正确的做法是失焦格式化时把它补成“0.50”。多个小数点直接由过滤逻辑里的第二步处理。第一个点保留后面的点全部删掉。这个策略的好处是用户不会因为输入被强行中断而困惑而是输入“1.2.3”后自己看到变成了“1.23”马上意识到规则。负号按业务来。价格通常是正数所以负号一律过滤掉。如果某些场景下需要允许负数比如记账时有支出那过滤逻辑得额外保留一个位于开头的负号并且不允许“1-2”这种中间出现的负号。我只讲正数价格的场景负数场景实在要扩展也是同理只是多一个判断。3. 中文输入法、粘贴与移动端适配3.1 输入法组合态问题不解决中文用户直接骂人这个坑几乎每个做过输入过滤的人都会踩一次。用户用中文输入法打字时输入“abc”的拼音字母会触发input事件此时如果你的过滤逻辑直接删字母输入法会立刻“抽风”——拼音刚打了两个字母就被删掉导致候选词完全出不来用户根本没法正常打字。这里需要用composition相关的事件来做保护。compositionend事件表示输入法组合结束compositionstart事件表示组合开始。在组合期间input事件虽然会触发但输入的内容是拼音的中间态不应做任何过滤。let isComposing false; el.addEventListener(compositionstart, () { isComposing true; }); el.addEventListener(compositionend, (e) { isComposing false; // 组合结束后的值也要过滤一遍防止有残留非法字符 handleInput(e); }); el.addEventListener(input, (e) { if (isComposing) { return; } handleInput(e); });这样用户在输入框里通过拼音打了一个“元”字组合期间拼音字母不会被删combositionend后整个“元”字落进输入框再被过滤逻辑删掉。虽然结果是用户打了一个汉字然后消失了但至少输入法本身能正常使用不会出现那种“打字就断”的崩溃体验。3.2 粘贴的内容必须先过一遍过滤器用户很少会手动乖乖敲数字更多时候是从Excel、Word、网页上复制金额数据粘贴过来。复制内容可能是“1,234.56”或“12.34元”甚至是从表格里复制出来的“1,234.56”带千分位逗号。我们的过滤逻辑本身已经把非数字和非小数点的字符去掉了所以粘贴“1,234.56”进来结果是“1234.56”正好是想要的值。逗号被删掉人民币符号被删掉数据处理得很干净。但粘贴有一个特殊情况某些时候过滤后值一模一样比如粘贴“123.45”进去过滤前后没有变化此时不需要重新赋值光标保持原样就行。这一点在上面的代码里已经体现了。还建议大家处理一下paste事件直接在粘贴发生之前拦截并处理掉可以避免一些浏览器对中文输入法组合状态的干扰。不过我的经验是input事件里统一处理已经足够paste事件拦截属于可选的加强措施。3.3 移动端键盘和桌面端的差异处理typetext的输入框在手机端默认弹起的是全键盘打字比较折腾所以移动端需要设置inputmode属性告诉浏览器我们只需要数字和小数点键盘。el-input :model-valueprice inputmodedecimal /inputmodedecimal会在支持的浏览器上弹起带小数点的数字键盘iOS和Android均支持。注意这里不能依赖typenumber原因前面已经说过了e和正负号的问题在移动端同样存在。另一个移动端的问题是很多Android键盘在输入完数字后会出现“换行”键而不是“完成”键。对输入框来说影响不大但如果你用的是表单用户点换行可能触发不了提交需要考虑用enterkeyhintdone来提示键盘展示“完成”按钮。这个属于锦上添花但做了以后移动端体验会明显提升。4. 价格精度与格式化输出4.1 浮点数计算的坑价格是典型的不能直接用浮点数做运算的数据。0.1 0.2不等于0.3这个经典问题在这里也一样用户输入0.06元乘以100份额后端返回6.000000000000001之类的东西页面显示起来就是一连串不敢看的数字。价格相关的计算最稳的办法是全部转成整数分来做。也就是说任何涉及到两位小数的运算先把数字乘以100取整运算完再除以100。比如要计算“12.34 5.66”不要直接加而是算(1234 566) / 100。如果只是想格式化显示用toFixed(2)是够的但做计算想避免浮点误差就要尽量绕开二进制浮点运算。// 不要这样 const total 0.1 0.2; // 0.30000000000000004 // 要这样 const total Math.round((0.1 * 100)) Math.round((0.2 * 100)); // 30单位分4.2 失焦时怎样格式化才不招人烦失焦格式化的目标是让数据规范但也不能矫枉过正搞得太死板。我的策略是输入框失焦时把值做一次完整格式化和补全。空值保持为空不强行改成0除非业务要求空值默认为0。是“2.”的补成“2.00”是“.5”的补成“0.50”是“1.2”的补成“1.20”是“1.234”的已经被过滤成“1.23”了所以这里主要处理补零的事。是“123”的保持“123”还是补成“123.00”看产品需求。我个人更喜欢补成“123.00”因为这样表达更明确。具体代码很简单function formatBlur(value) { if (value || value null || value undefined) { return ; } const num Number(value); if (isNaN(num)) { return ; } return num.toFixed(2); }有一个注意点toFixed()返回的是字符串如果你直接赋值给v-model原来的number值会变成string这个在提交时需要统一处理。我的做法是v-model的字段保持string类型提交时再转成数字或分。4.3 上限和整数位数的设计价格输入必须考虑上限否则用户输入99999999999.99后端大概率会溢出或抛异常。我建议根据业务实际设置一个封顶值。比如业务限定最大金额不能超过一千万元那么整数位最多7位小数位固定2位最大合法值是9999999.99。过滤器里对整数部分做一个slice(0, 7)就能硬性截断。这个硬截断可能让用户觉得“我还在输入怎么就被截了”。比较好的体验是输入阶段只过滤非法字符和过多的位数等失焦时如果超了给出一次性提示。但多数团队不愿意为这种极端场景增加复杂度所以直接截断也能接受。具体看你们的产品定位我一般选择硬截断因为用户输入超长数字时其实他已经犯了错提前截断等于提前纠错。5. 表单校验与整体集成5.1 自定义 validator 的写法Element的表单校验底层是async-validator自定义规则时直接写validator函数即可。const validatePrice (rule, value, callback) { const strValue value null ? : String(value); if (strValue ) { // 是否必填看你们的业务。这里假设必填 callback(new Error(请输入金额)); return; } const regex /^\d(\.\d{1,2})?$/; if (!regex.test(strValue)) { callback(new Error(金额格式不正确请输入例如 12.34 的格式)); return; } const num Number(strValue); if (num MAX_PRICE) { callback(new Error(金额不能超过 ${MAX_PRICE})); return; } callback(); };注意正则里的\d它要求整数部分至少一位。所以“0.5”是可以通过的“.5”不能通过这个语义和失焦格式化之间的衔接要处理好。我的做法是失焦时已经把“.5”格式化成“0.50”了所以提交时拿到的是规范字符串validator不会误判。另一个容易忽略的点是如果v-model绑定的是number类型有时候用户输入“1.”会被框架转成“1”导致显示和校验结果不一致。所以这类输入框我建议v-model直接用String类型绑定保持输入原始文本。5.2 与 el-form 联动的细节Element的表单校验默认在值变化时触发。如果你在input事件里做了过滤过滤后的值赋值给v-model它的watch会自动触发校验这时候用户输入非法字符的瞬间表单错误提示就会弹出来。这个体验我觉得太吵了。我建议这样配置el-form-item propprice :rulespriceRules el-input :model-valueprice update:model-valuehandleInput blurhandleBlur / /el-form-itemhandleInput里做过滤和赋值handleBlur里做格式化和显式校验。通过控制validateTrigger可以让它只在失焦时校验el-form-item propprice :rulespriceRules validate-triggerblur这样用户在输入过程中不会被打断失焦时才会看到错误提示显得更友好。5.3 封装成通用组件做过两三个项目之后我强烈建议把这个逻辑抽成一个独立组件而不是每次copy代码。组件的props可以简单收敛为下面几个modelValue字符串或数字v-model绑定max最大金额precision小数位数默认2disabled、placeholder这些跟el-input保持一致过滤、格式化、失焦、校验全部封装在组件内部外部只关心拿到一个规范的string。后续团队成员谁要用都不会再踩重复的坑。6. 常见问题与排查技巧实录6.1 问题速查表现象原因解决方案输入e、、-照样能进过滤器没有对字母和符号做处理用[^\d.]替换非数字和小数点字符输入1.2.3能输进去没有处理多个小数点只保留第一个小数点后面的删除中文输入法下按数字键没反应input事件在composition期间误删拼音监听compositionstart/end组合期间跳过过滤拼音输入的字母被当成内容组合期间过滤被跳过在compositionend后做一次统一过滤输入0.060.01计算结果异常浮点运算误差转成整数分后运算粘贴“1,234.56”进来多了很多字符过滤写成只挡键盘输入确保过滤逻辑同样作用于粘贴内容number类型的el-input能滚轮改值滚轮默认行为使用typetext避免此问题失焦后0.5变成了undefined没有做类型转换就toFixed先Number(value)再toFixed6.2 三个实战小技巧第一个自动填充的坑。浏览器有时会把之前填过的手机号、姓名自动填充到输入框里这些内容往往包含中文字符会直接绕过你的过滤逻辑出现在页面上。解决方式是在el-input上加上autocompleteoff有的浏览器可能还不够需要加一个nameoff之类的属性具体看浏览器策略。第二个测试时记得模拟粘贴操作。手动敲键盘只能验证一部分逻辑粘贴操作必须单独测。我在实际开发中会用浏览器的控制台手动给输入框塞值比如el.value1,234.56然后dispatchEvent(new Event(input))确保过滤逻辑对程序化赋值同样生效。第三个中间状态“1.”的取舍。很多产品经理会坚持要求“用户输入1.的时候焦点离开后自动变成1.00”但他可能没想过如果用户输入“1.”后马上又输入“2”最终正确值应该是1.2失焦补零的逻辑必须考虑到这一点不能在“1.”的中间态就强制补成“1.”。稳妥的做法是不管中间态只在失焦时格式化。6.3 踩过几次坑之后我的一些经验这个需求我第一次做的时候只写了一个input事件replace结果被中文输入法坑到怀疑人生。后来加上composition保护过了几天又被浮点数精度问题恶心到。现在再遇到类似需求我第一个动作就是确认“输入阶段、格式化阶段、校验阶段”是否都划清楚了。另外发现一个很实用的思路不要过度设计。有些开发者会想写出一个完美无缺的正则把所有可能性都堵死结果用户输入“.”都费劲。价格格式的核心约束其实就是“数字一个小数点最多两位小数”围绕这个约束去做逻辑不会太复杂一定不要为了防万一而把用户的合理操作也拦了。最后再分享一个小技巧可以给输入框的placeholder里明确写出“请输入≥0的金额最多两位小数”之类的提示别小看这句话它能让用户从一开始就带着正确的预期去操作输入错误率会低很多。格式上的问题解决以后还要记得跟后端确认最终的金额传输格式——是字符串还是数字、以元为单位还是以分为单位这些约定最好在接口文档里写清楚避免前后端各自解释各自的路。
做后台管理系统的时候肯定绕不过一类组件金额输入框。el-input本身是纯文本输入如果不做任何限制用户能往里面塞各种奇怪内容——字母、符号、空格、甚至带上emoji提交到后端以后要么报错要么让校验弹窗变得异常狰狞。标题里的“限制只能输入价格格式”看起来是个小需求真做起来又有不少细节正则怎么写才不误杀中间状态中文输入法会不会把拼音首字母塞进输入框粘贴一段“12.3.4元”怎么处理失焦之后需不需要自动补两位小数。这篇文章我把整个思路和踩过的坑从头到尾捋一遍直接给出一套能落地的方案。我习惯把这类需求拆成三层防线来处理输入过程实时过滤、失焦时格式化兜底、表单提交时再校验一次。三件事各司其职单靠某一个环节都会出问题。比如只做表单校验用户输入阶段依然能看见一堆乱码体验很差只做输入过滤不校验某些边界情况比如直接粘贴一个异常值可能漏过去。所以全部都要但各自管好自己的事。1. 需求拆解与方案选型1.1 为什么不能只靠表单校验很多刚接触这个需求的人第一反应是写一个校验规则提交时告诉用户“请输入正确金额”。这个思路本身没错但它解决的是“提交后发现问题”而不是“输入时不出问题”。设想一个场景用户在金额框里敲了个“1.2.3”他其实自己也没意识到多输了一个小数点直到点击提交被告知格式错误。接着他得回头逐字检查到底哪里错了这个来回折腾的过程非常影响体验。所以在输入的一瞬间就把非法字符过滤掉让用户根本没有机会输入错误格式这才是这个需求真正的核心价值。另外一点是价格输入框通常意味着后端要接收到一个干净的数据。如果提交之前再让后端处理脏数据很容易出现精度问题或类型问题。与其在接口层做各种防御不如在最源头就把格式限定死。1.2 typenumber 为什么是条歪路有人会说El-input的type设成number不就行了这个方案看起来省事实际用起来坑很深。先说e的问题。在大部分浏览器里typenumber的输入框是允许输入字母e的因为那是科学计数法的一部分。用户压根不懂什么是科学计数法只是觉得“怎么还能输字母”。加减号也是同理number类型原生允许正负号但价格通常不该出现负号。滚动滚轮还会自动改值这个在桌面端很容易误触表格页面手一滑金额就变了而且很难排查。更麻烦的是不同浏览器对这个输入框的表现不一致。某些移动端浏览器的number键盘并不是纯数字键盘有的会显示带小数点的符号键盘有的展示全数字键盘设计上很不统一。而且它无法直接限制小数位数你输入“1.234”el-input的v-model能拿到这个值除非额外处理否则它就会原样传给后端。typenumber的定位是“提交前允许用户输入数字类型”不是“格式化为价格”两者的目标完全不一样。所以我的选择是type继续用text靠手动控制过滤逻辑这样行为完全可控不再依赖浏览器差异。1.3 三层防线的整体设计第一层在input事件里实时过滤。每次用户敲键盘、粘贴、拖拽内容时把不符合价格格式的字符全部去掉。这一层负责保证输入框里永远不会出现脏数据。第二层在blur失焦时做格式化。价格一般来说应该保留两位小数但用户输入过程中不应该强迫他必须按两位去敲那样很反人类。失焦以后把0.5格式化成0.50把1.230格式化成1.23把空值处理成空字符串或者回退成0让数据以一个规范的状态进入下一环节。第三层表单校验。这一层不是为了抓脏字符而是为了保证语义正确比如输入不能为空、不能超过业务允许的最大金额、小数位最多两位等。前面两层已经保证了格式第三层保证的是业务规则。2. 核心实现正则过滤与控制逻辑2.1 正则搭配要选对逐字判断和整体判断不一样先看一个很多人直接拿来用的正则/^\d(\.\d{0,2})?$/这个正则看起来很完美整数部分至少一位小数部分可以有但最多两位。然而直接拿它在input事件里做校验一输入就出问题。你初始化的时候输入框是空的用户刚打开页面还没敲数字此时空字符串在被校验时会失败。用户输入“1.”的时候其实是合法的中间状态但上面这个正则也会失败因为\d要求整数部分至少一位“1.”最后那个点是合法的但正则不允许字符串末尾悬着一个点。如果直接用这个正则做“非法即拦截”用户连“1.5”都输不进去。正确的思路是过滤非法字符时应该用“允许出现的字符”集合来过滤而不是用完整格式规则来否决一切。我的做法是用这个正则去替换掉非法字符let filteredValue value.replace(/[^\d.]/g, );这行代码会把所有不是数字和小数点的字符全部删掉。但这样还不够干净比如“1.2.3”这种数字和小数点都是合法字符不会被上面的正则清掉所以还需要做下一步约束。2.2 在 input 事件里做逐字过滤完整思路可以这样写拿到用户输入的值先去掉非法字符再处理小数点和长度的限制最后回填到输入框。function formatInput(value) { // 1. 去掉所有非数字和小数点的字符 let result String(value).replace(/[^\d.]/g, ); // 2. 只保留第一个小数点后面的小数点全部删除 const firstIndex result.indexOf(.); if (firstIndex ! -1) { result result.slice(0, firstIndex 1) result.slice(firstIndex 1).replace(/\./g, ); } // 3. 限制小数位最多两位这个限制放在输入过滤里避免用户输入 1.234 if (firstIndex ! -1) { const integerPart result.slice(0, firstIndex); let decimalPart result.slice(firstIndex 1); decimalPart decimalPart.slice(0, 2); result integerPart . decimalPart; } // 4. 限制整数位数比如最多7位对应最大金额9999999.99 const dotIndex result.indexOf(.); const intPart dotIndex -1 ? result : result.slice(0, dotIndex); if (intPart.length 7) { result dotIndex -1 ? intPart.slice(0, 7) : intPart.slice(0, 7) result.slice(dotIndex); } return result; }这里有一个很多人会忽略的细节强制把过滤后的值回填给输入框时光标位置会跳。比如用户输入了一大串数字中间发现输错了想删掉一位输入事件触发后输入框内容被重新赋值光标直接跳到末尾这种体验很糟糕。解决办法是记录光标位置并恢复const pos input.selectionStart; const newValue formatInput(input.value); if (newValue ! input.value) { input.value newValue; // 光标位置做一定的偏移修正 const newPos Math.min(pos, newValue.length); input.setSelectionRange(newPos, newPos); }具体偏移需要看过滤掉了几个字符。如果用户在光标前输入了一个非法字符过滤会删掉它此时光标应该保持在原位置或回退一位如果用户输入的是合法内容光标正常前进。这里不追求绝对完美但至少要保证光标不会乱跳到末尾。2.3 边界情况小数点开头、多个小数点、负号小数点开头的情况比如用户输入“.5”。中间状态是允许的因为用户可能接下来会补一个0变成“0.5”。所以过滤逻辑里不能一看到开头是小数点就删除。正确的做法是失焦格式化时把它补成“0.50”。多个小数点直接由过滤逻辑里的第二步处理。第一个点保留后面的点全部删掉。这个策略的好处是用户不会因为输入被强行中断而困惑而是输入“1.2.3”后自己看到变成了“1.23”马上意识到规则。负号按业务来。价格通常是正数所以负号一律过滤掉。如果某些场景下需要允许负数比如记账时有支出那过滤逻辑得额外保留一个位于开头的负号并且不允许“1-2”这种中间出现的负号。我只讲正数价格的场景负数场景实在要扩展也是同理只是多一个判断。3. 中文输入法、粘贴与移动端适配3.1 输入法组合态问题不解决中文用户直接骂人这个坑几乎每个做过输入过滤的人都会踩一次。用户用中文输入法打字时输入“abc”的拼音字母会触发input事件此时如果你的过滤逻辑直接删字母输入法会立刻“抽风”——拼音刚打了两个字母就被删掉导致候选词完全出不来用户根本没法正常打字。这里需要用composition相关的事件来做保护。compositionend事件表示输入法组合结束compositionstart事件表示组合开始。在组合期间input事件虽然会触发但输入的内容是拼音的中间态不应做任何过滤。let isComposing false; el.addEventListener(compositionstart, () { isComposing true; }); el.addEventListener(compositionend, (e) { isComposing false; // 组合结束后的值也要过滤一遍防止有残留非法字符 handleInput(e); }); el.addEventListener(input, (e) { if (isComposing) { return; } handleInput(e); });这样用户在输入框里通过拼音打了一个“元”字组合期间拼音字母不会被删combositionend后整个“元”字落进输入框再被过滤逻辑删掉。虽然结果是用户打了一个汉字然后消失了但至少输入法本身能正常使用不会出现那种“打字就断”的崩溃体验。3.2 粘贴的内容必须先过一遍过滤器用户很少会手动乖乖敲数字更多时候是从Excel、Word、网页上复制金额数据粘贴过来。复制内容可能是“1,234.56”或“12.34元”甚至是从表格里复制出来的“1,234.56”带千分位逗号。我们的过滤逻辑本身已经把非数字和非小数点的字符去掉了所以粘贴“1,234.56”进来结果是“1234.56”正好是想要的值。逗号被删掉人民币符号被删掉数据处理得很干净。但粘贴有一个特殊情况某些时候过滤后值一模一样比如粘贴“123.45”进去过滤前后没有变化此时不需要重新赋值光标保持原样就行。这一点在上面的代码里已经体现了。还建议大家处理一下paste事件直接在粘贴发生之前拦截并处理掉可以避免一些浏览器对中文输入法组合状态的干扰。不过我的经验是input事件里统一处理已经足够paste事件拦截属于可选的加强措施。3.3 移动端键盘和桌面端的差异处理typetext的输入框在手机端默认弹起的是全键盘打字比较折腾所以移动端需要设置inputmode属性告诉浏览器我们只需要数字和小数点键盘。el-input :model-valueprice inputmodedecimal /inputmodedecimal会在支持的浏览器上弹起带小数点的数字键盘iOS和Android均支持。注意这里不能依赖typenumber原因前面已经说过了e和正负号的问题在移动端同样存在。另一个移动端的问题是很多Android键盘在输入完数字后会出现“换行”键而不是“完成”键。对输入框来说影响不大但如果你用的是表单用户点换行可能触发不了提交需要考虑用enterkeyhintdone来提示键盘展示“完成”按钮。这个属于锦上添花但做了以后移动端体验会明显提升。4. 价格精度与格式化输出4.1 浮点数计算的坑价格是典型的不能直接用浮点数做运算的数据。0.1 0.2不等于0.3这个经典问题在这里也一样用户输入0.06元乘以100份额后端返回6.000000000000001之类的东西页面显示起来就是一连串不敢看的数字。价格相关的计算最稳的办法是全部转成整数分来做。也就是说任何涉及到两位小数的运算先把数字乘以100取整运算完再除以100。比如要计算“12.34 5.66”不要直接加而是算(1234 566) / 100。如果只是想格式化显示用toFixed(2)是够的但做计算想避免浮点误差就要尽量绕开二进制浮点运算。// 不要这样 const total 0.1 0.2; // 0.30000000000000004 // 要这样 const total Math.round((0.1 * 100)) Math.round((0.2 * 100)); // 30单位分4.2 失焦时怎样格式化才不招人烦失焦格式化的目标是让数据规范但也不能矫枉过正搞得太死板。我的策略是输入框失焦时把值做一次完整格式化和补全。空值保持为空不强行改成0除非业务要求空值默认为0。是“2.”的补成“2.00”是“.5”的补成“0.50”是“1.2”的补成“1.20”是“1.234”的已经被过滤成“1.23”了所以这里主要处理补零的事。是“123”的保持“123”还是补成“123.00”看产品需求。我个人更喜欢补成“123.00”因为这样表达更明确。具体代码很简单function formatBlur(value) { if (value || value null || value undefined) { return ; } const num Number(value); if (isNaN(num)) { return ; } return num.toFixed(2); }有一个注意点toFixed()返回的是字符串如果你直接赋值给v-model原来的number值会变成string这个在提交时需要统一处理。我的做法是v-model的字段保持string类型提交时再转成数字或分。4.3 上限和整数位数的设计价格输入必须考虑上限否则用户输入99999999999.99后端大概率会溢出或抛异常。我建议根据业务实际设置一个封顶值。比如业务限定最大金额不能超过一千万元那么整数位最多7位小数位固定2位最大合法值是9999999.99。过滤器里对整数部分做一个slice(0, 7)就能硬性截断。这个硬截断可能让用户觉得“我还在输入怎么就被截了”。比较好的体验是输入阶段只过滤非法字符和过多的位数等失焦时如果超了给出一次性提示。但多数团队不愿意为这种极端场景增加复杂度所以直接截断也能接受。具体看你们的产品定位我一般选择硬截断因为用户输入超长数字时其实他已经犯了错提前截断等于提前纠错。5. 表单校验与整体集成5.1 自定义 validator 的写法Element的表单校验底层是async-validator自定义规则时直接写validator函数即可。const validatePrice (rule, value, callback) { const strValue value null ? : String(value); if (strValue ) { // 是否必填看你们的业务。这里假设必填 callback(new Error(请输入金额)); return; } const regex /^\d(\.\d{1,2})?$/; if (!regex.test(strValue)) { callback(new Error(金额格式不正确请输入例如 12.34 的格式)); return; } const num Number(strValue); if (num MAX_PRICE) { callback(new Error(金额不能超过 ${MAX_PRICE})); return; } callback(); };注意正则里的\d它要求整数部分至少一位。所以“0.5”是可以通过的“.5”不能通过这个语义和失焦格式化之间的衔接要处理好。我的做法是失焦时已经把“.5”格式化成“0.50”了所以提交时拿到的是规范字符串validator不会误判。另一个容易忽略的点是如果v-model绑定的是number类型有时候用户输入“1.”会被框架转成“1”导致显示和校验结果不一致。所以这类输入框我建议v-model直接用String类型绑定保持输入原始文本。5.2 与 el-form 联动的细节Element的表单校验默认在值变化时触发。如果你在input事件里做了过滤过滤后的值赋值给v-model它的watch会自动触发校验这时候用户输入非法字符的瞬间表单错误提示就会弹出来。这个体验我觉得太吵了。我建议这样配置el-form-item propprice :rulespriceRules el-input :model-valueprice update:model-valuehandleInput blurhandleBlur / /el-form-itemhandleInput里做过滤和赋值handleBlur里做格式化和显式校验。通过控制validateTrigger可以让它只在失焦时校验el-form-item propprice :rulespriceRules validate-triggerblur这样用户在输入过程中不会被打断失焦时才会看到错误提示显得更友好。5.3 封装成通用组件做过两三个项目之后我强烈建议把这个逻辑抽成一个独立组件而不是每次copy代码。组件的props可以简单收敛为下面几个modelValue字符串或数字v-model绑定max最大金额precision小数位数默认2disabled、placeholder这些跟el-input保持一致过滤、格式化、失焦、校验全部封装在组件内部外部只关心拿到一个规范的string。后续团队成员谁要用都不会再踩重复的坑。6. 常见问题与排查技巧实录6.1 问题速查表现象原因解决方案输入e、、-照样能进过滤器没有对字母和符号做处理用[^\d.]替换非数字和小数点字符输入1.2.3能输进去没有处理多个小数点只保留第一个小数点后面的删除中文输入法下按数字键没反应input事件在composition期间误删拼音监听compositionstart/end组合期间跳过过滤拼音输入的字母被当成内容组合期间过滤被跳过在compositionend后做一次统一过滤输入0.060.01计算结果异常浮点运算误差转成整数分后运算粘贴“1,234.56”进来多了很多字符过滤写成只挡键盘输入确保过滤逻辑同样作用于粘贴内容number类型的el-input能滚轮改值滚轮默认行为使用typetext避免此问题失焦后0.5变成了undefined没有做类型转换就toFixed先Number(value)再toFixed6.2 三个实战小技巧第一个自动填充的坑。浏览器有时会把之前填过的手机号、姓名自动填充到输入框里这些内容往往包含中文字符会直接绕过你的过滤逻辑出现在页面上。解决方式是在el-input上加上autocompleteoff有的浏览器可能还不够需要加一个nameoff之类的属性具体看浏览器策略。第二个测试时记得模拟粘贴操作。手动敲键盘只能验证一部分逻辑粘贴操作必须单独测。我在实际开发中会用浏览器的控制台手动给输入框塞值比如el.value1,234.56然后dispatchEvent(new Event(input))确保过滤逻辑对程序化赋值同样生效。第三个中间状态“1.”的取舍。很多产品经理会坚持要求“用户输入1.的时候焦点离开后自动变成1.00”但他可能没想过如果用户输入“1.”后马上又输入“2”最终正确值应该是1.2失焦补零的逻辑必须考虑到这一点不能在“1.”的中间态就强制补成“1.”。稳妥的做法是不管中间态只在失焦时格式化。6.3 踩过几次坑之后我的一些经验这个需求我第一次做的时候只写了一个input事件replace结果被中文输入法坑到怀疑人生。后来加上composition保护过了几天又被浮点数精度问题恶心到。现在再遇到类似需求我第一个动作就是确认“输入阶段、格式化阶段、校验阶段”是否都划清楚了。另外发现一个很实用的思路不要过度设计。有些开发者会想写出一个完美无缺的正则把所有可能性都堵死结果用户输入“.”都费劲。价格格式的核心约束其实就是“数字一个小数点最多两位小数”围绕这个约束去做逻辑不会太复杂一定不要为了防万一而把用户的合理操作也拦了。最后再分享一个小技巧可以给输入框的placeholder里明确写出“请输入≥0的金额最多两位小数”之类的提示别小看这句话它能让用户从一开始就带着正确的预期去操作输入错误率会低很多。格式上的问题解决以后还要记得跟后端确认最终的金额传输格式——是字符串还是数字、以元为单位还是以分为单位这些约定最好在接口文档里写清楚避免前后端各自解释各自的路。
