有一次做停车缴费类的小程序被车牌号录入这个环节卡了整整三天。用户一点输入框系统键盘弹出来的是全键盘省份简称藏在一堆生僻汉字里翻半天找不到好不容易输完字母又发现车牌里的“I”和“O”根本不该出现但手机键盘上明晃晃摆着。后来我干脆把系统键盘整个丢掉手写了一个小程序自定义键盘组件专门做车牌号录入。这个组件后来被团队沉淀成通用物料接入了停车、充电、车辆服务等多个场景。这篇文章就把这个组件的需求拆解、键盘设计、核心实现和踩坑过程完整复盘一遍给正在做小程序录入类业务、尤其是准备自研键盘的朋友做个参考。先聊一个基础判断车牌号录入这件事看着只是一个“input 系统键盘”的组合但真正深入做以后你会发现它是最不适合用原生键盘的场景之一。原因也很简单车牌号有一套自己的字符集规则、位数规则和视觉格式系统键盘完全背道而驰。与其跟系统键盘做无谓斗争不如在组件层面自己画一套键盘让交互完全可控。本文会从需求拆解、键盘布局、交互实现、接口设计和真机踩坑五个部分把整车牌录入组件的实现路径讲透。1. 车牌录入场景下的需求拆解与设计定位1.1 为什么说原生键盘在这里基本不可用你可能会想车牌号不就是汉字、字母、数字混着输吗系统键盘也能输入啊。但实际业务一旦跑起来问题非常多。第一省份简称是固定的三十多个汉字但系统键盘的候选词里不会给你做“车牌专用排序”。用户必须切到中文输入法再手打拼音去找简称操作路径极长。很多中年用户在小程序里缴费时根本不知道简称在哪个候选词里甚至有人会去输入同音字导致车牌号错误。第二车牌号的字符集是“半开放”的。第1位只能是省份简称第2位只能是英文字母发牌机关代号从第3位开始才是字母和数字混排。系统键盘完全不知道这些位约束它只会把你按下的所有字符一股脑塞进去。做后端查询时非法车牌直接查不到用户又会觉得是小程序的问题。第三系统键盘的显示区域、按键大小、收起时机都不受你控制。在小程序里你没法动态修改系统键盘的布局也没法在用户输满位数后自动收起键盘。表面上看只是输入一串字符实际上牵涉到格式校验、位数控制、键盘切换、自动提交这些用原生键盘全都做不到。第四还有一个很现实的理由系统键盘在不同手机上的视觉风格差异很大按键高度、数字键布局、手写输入模式都不同。如果你希望车牌录入的交互体验在整个小程序里保持一致自绘键盘几乎是唯一出路。所以我的结论很直接车牌号录入就应该做成一个自绘的自定义键盘组件完全绕开系统输入法。点击输入区域时不唤起系统键盘而是唤起组件内部的定制键盘。输入区域本身也只是用 view 渲染的格子阵列并非真正的 input。1.2 组件的设计定位只做输入不做深度校验在做组件之前我先明确了这个组件的边界。它叫“车牌号录入组件”核心职责是把车牌号按位、按规则录入到一个可视化的格子里并把完整的车牌字符串返回给业务方。它不应该做的事是深度车牌校验。比如某地区某批次特殊号牌的具体字母范围、执法类车辆的号牌规则、临时号牌的格式这些因业务而异放进通用组件里反而会造成耦合。组件内部只维护一套通用规则省份简称、发牌机关代号、字母数字混排、排除 I/O、位数控制。最后的合法性深校验放在业务层的提交函数里做。这样设计的好处非常明显。停车缴费业务只需要传统7位车牌充电桩业务需要新能源8位车牌后续可能还要支持某些特殊号牌我只需要给组件传不同的 maxlength 和 isNewEnergy 字段不用改组件内部逻辑。团队里后来接的几个页面基本就是几行配置的事。1.3 与原生 input form 方案的取舍我也想过要不要在原生 input 的基础上做增强比如监听 input 事件做字符过滤再用一个遮罩挡住系统键盘。这种方案网上有零星实现但实际体验经不起真机考验。原生 input 唤起系统键盘后你很难彻底拦截它的候选词。即使你在 input 的 value 上做过滤用户输入一个非法字符的瞬间系统键盘的联想区还是会闪一下。另外系统键盘的“完成”按钮行为在不同机型上不一致有的触发 blur有的不触发你无法统一处理。自绘键盘的缺点也很明显没有系统联想没有剪贴板粘贴输入效率确实比系统键盘低一点。但车牌号的字符集本身就只有几十个可选字符全部平铺在键盘上反而比翻页找汉字更快。我实测下来用户在自定义键盘上完成一个完整车牌输入平均时间比用系统键盘短很多。2. 牌照字符集与键盘面板布局实现2.1 字符集定义与 I/O 排除规则车牌字符集大致可以分成三块省份简称集合、英文字母集合、数字集合。省份简称是固定的常量数据数量在三十个左右。我在组件里没有把这些简称写死在代码里而是做成一个可配置的数组由业务方按当前标准行政区划编码顺序注入。这样做有两个原因一是避免组件里出现不必要的硬编码二是某些业务需要自定义展示顺序把简称做成配置项可以灵活调整。英文字母和数字的集合要特别注意一个规则字母 I 和字母 O 必须排除。原因是它们跟数字 1 和数字 0 在车牌字体下极易混淆车管系统也遵循这个规则。这个排除操作一定要在字符集定义阶段完成否则后续点按逻辑里会出现大量冗余判断。const LETTERS ABCDEFGHJKLMNPQRSTUVWXYZ.split() // 去掉 I 和 O const DIGITS 0123456789.split() const PLATE_SIGNS [] // 省份简称由业务方配置这段代码看起来简单但它是整块键盘的基础。字母和数字都存在数组里之后渲染键盘按键时直接遍历数组生成即可不需要在 WXML 里手写几十个按钮。2.2 省份简字面板与字母数字面板的排布方式车牌录入时第一个格子永远只接受省份简称后面所有格子才有字母和数字的输入需求。所以键盘内部需要两种面板省份简称面板和字母数字面板。省份简称面板数量多一屏放不下我采用了分页布局。每页固定显示两行六列共十二个简称字符底部放“上一页”“下一页”“删除”“收起”四个功能键。翻页逻辑内部用 pageIndex 记录切换时简单遍历数组截取渲染即可。字母数字面板是整个键盘的核心区域。我最初的设计是仿照手机九宫格把字母和数字分开展示但很快就发现这样效率很低。用户输入车牌号时第 3 位到第 7 位可能是数字也可能是字母如果字母和数字分开在两个页面用户要频繁切换面板反而更慢。最终我采用了“字母主区 数字底行”的组合面板。字母按顺序排成四行每行六个键数字 0 到 9 单独排在最底部一行。这样在一个屏幕内用户能看到全部可选字母和全部数字不需要任何切换就能完成大多数输入。2.3 新能源车牌与位数差异的处理车牌录入的另一个常见变量是燃油车和新能源车。燃油车号牌字符串长度为 7 位新能源车号牌字符串长度为 8 位。多出的一位来自序号部分。在组件设计里我加了一个 isNewEnergy 开关。它的作用有两个第一控制输入格子总数燃油车渲染 8 个格子但第 8 个永远不可用新能源车渲染 8 个格子全部启用第二调整字母数字面板的快捷提示区。新能源车牌的第三个字符位也就是序号的第一位通常会出现 D 或 F 这样的专用字母。虽然这不意味着其他字母完全不允许但从输入效率上考虑很多用户看到新能源车牌时会优先找 D 和 F。我在字母数字面板顶部做了一个小的快捷栏把新能源专用字母单独放大用户可以直接点。这个处理看似小但对体验提升非常明显。在充电桩业务中很多司机对车牌格式并不敏感只会说“我是新能源绿牌”但你让他回忆第三位是不是 D他根本不知道。快捷栏直接展示出来用户按直觉点选就行。2.4 键盘交互状态机设计车牌录入的交互看起来就是点按键、更新格子但内部其实是一个小型状态机。我自己在实现时把状态分为四种初始状态、输入状态、完成状态、关闭状态。初始状态对应键盘隐藏、格子为空。用户点击输入区域后组件进入输入状态此时根据激活格子位置决定显示哪个面板第 1 格显示省份简称面板其他格子显示字母数字面板。每点击一个按键组件校验该字符在当前位是否合法合法则写入当前格并后移激活位不合法则直接忽略。完成状态有两种触发方式一是用户输满所有格子后点击“完成”按钮二是输入过程中发现所有位都填满自动触发 confirm 事件。关闭状态则是用户点击“收起”按钮或点击键盘遮罩区域此时触发 close 事件键盘隐藏输入焦点回收。这个状态机并不复杂但它保证了整个交互过程是可控的。比如用户输入到第 5 格时突然点了一下最前面的第 1 格组件会把当前激活位切回第 1 格之后的输入都写入第 1 格。没有状态机管理这种光标跳转逻辑很容易写出 bug。3. 核心交互与光标控制的详细实现3.1 输入格子的绘制与光标动画输入区域我用一组 view 格子来实现。每行固定一个格子数组数量由 maxlength 决定。格子的核心样式是等宽等高、左右间距 8rpx、字符居中每个格子底部有一条细边框整体视觉是一个横向的输入框。光标是自绘的不依赖系统光标。实现方式也很简单当前激活的格子额外加一个 active 样式类在这个 class 里用伪元素画一条竖线然后加一条 CSS 闪烁动画。.active-cell::after { content: ; width: 2rpx; height: 36rpx; background: #2B6BFF; animation: blink 1s infinite; } keyframes blink { 0%, 100% { opacity: 1; } 50% { opacity: 0; } }光标动画的细节在于竖线的垂直居中。格子内部除了字符还有伪元素如果字符存在时竖线会跟字符重叠。我的处理是当格子有值时隐藏光标当前激活格有值但用户要修改它时光标仍然显示在字符右侧用 position: relative 往右偏移实现。3.2 激活索引与按位合法性拦截组件内部维护了一个 activatedIndex表示当前正在输入的格子序号。每次用户点击输入区域或者键盘每完成一次写入这个索引都会更新。合法性拦截是组件里最核心的逻辑我把它封装成一个纯函数。它的输入是当前格子索引、候选字符、是否新能源输出是布尔值。function isCharAllowed(index, char, isNewEnergy) { if (index 0) { return PLATE_SIGNS.includes(char) } if (index 1) { return LETTERS.includes(char) } if (isNewEnergy index 2) { return LETTERS.includes(char) || DIGITS.includes(char) } return LETTERS.includes(char) || DIGITS.includes(char) }这段逻辑有一个很微妙的地方第 2 位必须是字母但很多用户会习惯性地点数字。如果不拦截用户输入的号码会直接错位最终提交时校验失败。拦截后用户点数字键没有任何反馈可能觉得键盘失灵。所以我额外加了一个轻提示逻辑当用户在当前位点了不允许的字符类型时格子边框会闪一下红色提示用户当前位只能输入字母。这个提示功能虽然只多了一点代码但极大减少了用户困惑。3.3 已有车牌回填与字符串拆分业务场景里经常遇到“修改车牌”的需求。用户车牌已经存在点开录入组件时需要把已有车牌号直接显示在格子里并把光标定位到最后一个未输入的格子。回填实现时要注意一个坑不能直接用字符串的 length 来循环赋值。车牌字符串中既有中文汉字又有字母数字虽然这里的字符都是单字节或双字节但业务逻辑中最好统一用数组结构处理。const charList Array.from(value) // 按字符拆分避免编码问题回填的完整流程是将组件的 maxlength 设为对应值遍历 charList 填充格子数组剩余格子保持为空再把 activatedIndex 指向第一个空格子。如果车牌已经填满activatedIndex 指向最后一位此时用户点击键盘可以顶格修改最后一位。另外我在组件内部存储值的时候统一不保留空格确认后直接输出一个连续字符串。展示上如果需要风控脱敏业务层再单独处理。3.4 键盘弹出与页面滚动遮挡问题键盘弹出最怕的是挡住输入格子。原生 input 有 adjust-position 自动上推自绘组件没有这种能力所以必须手动处理。我的方案分为两步。第一步组件内的键盘用 position: fixed 定位固定在最底部高度用一个变量管理。第二步监听 activatedIndex 的变化当激活格位于页面下方时页面主动滚动把格子露出来。有些页面用的是 scroll-view 滚动容器这里有个细节scroll-view 内部元素定位成 fixed 会出问题键盘必须挂在页面根节点下面。我通常把键盘组件放在包裹页面全部内容的 view 之后这样无论页面怎么滚动键盘都稳定停留在屏幕底部。view classpage-content !-- 页面其他内容 -- /view plate-keyboard visible{{showKeyboard}} ... /这种挂载方式也是组件被团队复用后踩出来的经验。一开始我把键盘放在 scroll-view 内部真机上经常出现键盘跟着内容一起滚动的情况后来统一改成页面级挂载才稳定。4. 组件对外接口设计及业务接入实战4.1 核心配置项与事件设计组件最终对外暴露的接口要尽量简单。我把它设计成三个配置项和三个事件。配置项类型说明visibleBoolean是否显示键盘valueString组件回显的车牌号maxlengthNumber输入格数量默认8isNewEnergyBoolean是否为新能源车牌事件触发时机change车牌值发生变化confirm点击完成按钮或自动填满close点击收起按钮visible 字段由业务页面控制。这样键盘的显示时机可以完全对接业务逻辑比如用户点击某个入口时才弹出提交成功后主动关闭。confirm 事件会把当前车牌字符串作为参数返回。业务方在回调里做深校验和接口请求。我这里特别建议不要把所有校验逻辑放在组件内部因为不同业务对车牌格式的要求并不完全一致尤其是各省份对字母序号的扩展规则存在差异。组件保证通用合法业务保证业务合法这个分工最清晰。4.2 页面接入与数据接收过程接入一个页面我大致分四步。第一步在页面 json 文件里注册组件。第二步在 wxml 中放置组件传入配置项并绑定事件。第三步在 js 中监听 confirm 事件拿到车牌字符串后做业务校验。第四步业务校验通过后提交接口同时关闭键盘。plate-keyboard visible{{showKeyboard}} value{{plateNo}} is-new-energy{{isNewEnergy}} bind:changeonPlateChange bind:confirmonPlateConfirm bind:closeonKeyboardClose /看起来很简单但实际接入时最容易遗漏的是 visible 初始值。如果页面是新增车牌showKeyboard 默认 false 没问题如果是编辑车牌进入页面需要把 visible 设为 true否则用户看不到键盘还以为组件坏了。4.3 在不同业务场景下的适配变化组件落地后我遇到的第一批业务就有三种不同的车牌需求。停车缴费业务大多只涉及燃油车因此 maxlength 设为 7isNewEnergy 关闭即可。充电桩业务新能源车占比高需要把 isNewEnergy 打开maxlength 自动变成 8。还有一个车辆服务类业务需要用户在组件里选择“临时车牌”或者“无车牌”再录入这个需求组件本身不处理我在页面里加了两个单选入口勾选后直接把组件隐藏。另外在 toB 的物流调度页面里车牌录入往往伴随一个二次确认动作。我在组件外包了一层底部弹层用户录入完车牌后不直接提交而是点击“确认车牌”后再走接口。这种 adapter 套路比较通用组件只需要对外抛出 change 事件页面自己保存中间值即可。4.4 多端小程序平台适配的注意点车牌录入组件不能只盯着一端做很多团队会把它迁移到其他小程序平台上。这里我最深的体会是尽量使用最基础的标签和样式能力不要用任何平台的私有组件。我用的标签只有 view、text、button键盘按键的样式全部用 flex 布局没有依赖 checkbox、form 之类的高层组件。这么做的好处是迁到其他平台时基本只改事件绑定写法即可。还有一个容易被忽略的点底部安全区。全面屏手机底部有一条 home indicator 区域键盘如果贴底布局最低那行按键会被顶开。最终我用 env(safe-area-inset-bottom) 兼容安全区键盘底部留出了安全距离。5. 实操过程中踩过的坑与建议5.1 隐式规则比代码逻辑更容易翻车车牌号的规则我一开始只是知道个大概以为把字母和数字铺上去就行。结果联调时发现第 2 位的发牌机关代号只能是字母不能是数字而我当时允许了数字导致一批测试车牌无法通过后端校验。后来我查阅了一些公开的车牌编码规则资料又把规则细化成前面讲的 isCharAllowed 函数。这里建议做同类功能的读者先跟业务方把规则确认清楚特别是当地对字母序号位是否有限制。有些地区在序号首位不允许字母这个不是通用规则组件层面就不要写死放到业务校验里。我犯过的另一个错误是新能源车牌的第 3 位只放了 D 和 F。实际上不同地区、不同时间发放的新能源号牌第三个字符并不只有这两个字母。把快捷栏限定为 D/F 会导致一部分真实车牌无法录入后来我把快捷栏改为“新能源常见字母优先展示”底层仍然允许全部合法字母。5.2 键盘反复跳动问题排查键盘组件接完第一个版本后同事反馈说在真机上点击输入格键盘会先收起再弹出整个界面闪一下。一开始我怀疑是键盘显示逻辑有问题反复 review 后发现键盘本身没有做销毁重建问题出在点击输入格时触发了页面级 blur。经过排查原因是输入格被设计成 button 组件。button 的默认行为里包含一些焦点逻辑点击后会把当前焦点状态清空导致组件的 visible 状态被联动重置。后面我把所有格子全部改成 view并在 view 上绑定触摸事件彻底绕开 button 的默认行为跳闪问题就消失了。类似的坑还有键盘上不要用 catchtap 和 bindtap 混用同一个按键同时绑定两种事件会触发两次输入。5.3 长按删除与防抖处理删除键看起来简单其实是最容易体验翻车的地方。最初版本只支持单击删除每次点击删除当前格字符空格则回退上一格。用户反馈说清除车牌太慢尤其是要清空 8 位号码时得点 8 次。我后来加了长按连续删除逻辑是触摸删除键超过 400ms 后进入每 120ms 删除一次的循环手指松开立即停止并清理定时器。function handleBackspaceTouchStart() { backspaceTimer setTimeout(() { backspaceTimer setInterval(() { deleteOneChar() }, 120) }, 400) } function handleBackspaceTouchEnd() { clearTimeout(backspaceTimer); clearInterval(backspaceTimer); }这里有个很容易踩的坑删除循环的定时器如果在页面销毁时没有清理会报 setInterval 的警告甚至导致内存回调。组件的 detached 生命周期里一定要加清理逻辑。5.4 用户输入与真实号牌规则的校验分层还有一个关于芯片级细节的建议组件内部的通用校验千万不要试图覆盖所有业务可能。比如某个特殊号牌类型它的整体格式、总位数可能完全不同通用组件一旦针对它做适配其他业务就会被牵连。我在组件里只做极简的位数和字符集校验复杂校验放在业务提交前。我在体验版里放了一版内置完整校验逻辑的组件结果后续给另一个业务用时出现了“上一业务限定的字母规则在新业务不适用”的情况。改回分层校验后问题再没出现过。5.5 数据敏感性与日志规范车牌号本质上属于个人敏感信息虽然很多业务场景里只是作为查询凭证但开发过程中还是要多留个心眼。我在组件里刻意不在 console.log 中输出完整车牌调试时也尽量用脱敏字符串打印。另外提交接口时车牌中的汉字需要做 URL 编码否则部分服务端框架会直接报参数错误。这个坑在联调时出现过一次原因是前端完全没有做 encodeURIComponent汉字直接明文拼在 query 里。建议在统一请求层处理编码而不是每个业务页面单独加。最后再分享一个小技巧。车牌录入组件这类“格式固定、场景通用”的交互特别适合沉淀为团队组件库的公共物料。我做完第一版后后续在三个新业务里复用每次只改配置项、校验函数和一点样式变量没有再多写一遍键盘。如果你也在做类似的小程序表单场景不妨按这个思路把“输入规则 键盘面板 光标交互”拆成独立组件长远来看能省下不少重复开发的成本。
有一次做停车缴费类的小程序被车牌号录入这个环节卡了整整三天。用户一点输入框系统键盘弹出来的是全键盘省份简称藏在一堆生僻汉字里翻半天找不到好不容易输完字母又发现车牌里的“I”和“O”根本不该出现但手机键盘上明晃晃摆着。后来我干脆把系统键盘整个丢掉手写了一个小程序自定义键盘组件专门做车牌号录入。这个组件后来被团队沉淀成通用物料接入了停车、充电、车辆服务等多个场景。这篇文章就把这个组件的需求拆解、键盘设计、核心实现和踩坑过程完整复盘一遍给正在做小程序录入类业务、尤其是准备自研键盘的朋友做个参考。先聊一个基础判断车牌号录入这件事看着只是一个“input 系统键盘”的组合但真正深入做以后你会发现它是最不适合用原生键盘的场景之一。原因也很简单车牌号有一套自己的字符集规则、位数规则和视觉格式系统键盘完全背道而驰。与其跟系统键盘做无谓斗争不如在组件层面自己画一套键盘让交互完全可控。本文会从需求拆解、键盘布局、交互实现、接口设计和真机踩坑五个部分把整车牌录入组件的实现路径讲透。1. 车牌录入场景下的需求拆解与设计定位1.1 为什么说原生键盘在这里基本不可用你可能会想车牌号不就是汉字、字母、数字混着输吗系统键盘也能输入啊。但实际业务一旦跑起来问题非常多。第一省份简称是固定的三十多个汉字但系统键盘的候选词里不会给你做“车牌专用排序”。用户必须切到中文输入法再手打拼音去找简称操作路径极长。很多中年用户在小程序里缴费时根本不知道简称在哪个候选词里甚至有人会去输入同音字导致车牌号错误。第二车牌号的字符集是“半开放”的。第1位只能是省份简称第2位只能是英文字母发牌机关代号从第3位开始才是字母和数字混排。系统键盘完全不知道这些位约束它只会把你按下的所有字符一股脑塞进去。做后端查询时非法车牌直接查不到用户又会觉得是小程序的问题。第三系统键盘的显示区域、按键大小、收起时机都不受你控制。在小程序里你没法动态修改系统键盘的布局也没法在用户输满位数后自动收起键盘。表面上看只是输入一串字符实际上牵涉到格式校验、位数控制、键盘切换、自动提交这些用原生键盘全都做不到。第四还有一个很现实的理由系统键盘在不同手机上的视觉风格差异很大按键高度、数字键布局、手写输入模式都不同。如果你希望车牌录入的交互体验在整个小程序里保持一致自绘键盘几乎是唯一出路。所以我的结论很直接车牌号录入就应该做成一个自绘的自定义键盘组件完全绕开系统输入法。点击输入区域时不唤起系统键盘而是唤起组件内部的定制键盘。输入区域本身也只是用 view 渲染的格子阵列并非真正的 input。1.2 组件的设计定位只做输入不做深度校验在做组件之前我先明确了这个组件的边界。它叫“车牌号录入组件”核心职责是把车牌号按位、按规则录入到一个可视化的格子里并把完整的车牌字符串返回给业务方。它不应该做的事是深度车牌校验。比如某地区某批次特殊号牌的具体字母范围、执法类车辆的号牌规则、临时号牌的格式这些因业务而异放进通用组件里反而会造成耦合。组件内部只维护一套通用规则省份简称、发牌机关代号、字母数字混排、排除 I/O、位数控制。最后的合法性深校验放在业务层的提交函数里做。这样设计的好处非常明显。停车缴费业务只需要传统7位车牌充电桩业务需要新能源8位车牌后续可能还要支持某些特殊号牌我只需要给组件传不同的 maxlength 和 isNewEnergy 字段不用改组件内部逻辑。团队里后来接的几个页面基本就是几行配置的事。1.3 与原生 input form 方案的取舍我也想过要不要在原生 input 的基础上做增强比如监听 input 事件做字符过滤再用一个遮罩挡住系统键盘。这种方案网上有零星实现但实际体验经不起真机考验。原生 input 唤起系统键盘后你很难彻底拦截它的候选词。即使你在 input 的 value 上做过滤用户输入一个非法字符的瞬间系统键盘的联想区还是会闪一下。另外系统键盘的“完成”按钮行为在不同机型上不一致有的触发 blur有的不触发你无法统一处理。自绘键盘的缺点也很明显没有系统联想没有剪贴板粘贴输入效率确实比系统键盘低一点。但车牌号的字符集本身就只有几十个可选字符全部平铺在键盘上反而比翻页找汉字更快。我实测下来用户在自定义键盘上完成一个完整车牌输入平均时间比用系统键盘短很多。2. 牌照字符集与键盘面板布局实现2.1 字符集定义与 I/O 排除规则车牌字符集大致可以分成三块省份简称集合、英文字母集合、数字集合。省份简称是固定的常量数据数量在三十个左右。我在组件里没有把这些简称写死在代码里而是做成一个可配置的数组由业务方按当前标准行政区划编码顺序注入。这样做有两个原因一是避免组件里出现不必要的硬编码二是某些业务需要自定义展示顺序把简称做成配置项可以灵活调整。英文字母和数字的集合要特别注意一个规则字母 I 和字母 O 必须排除。原因是它们跟数字 1 和数字 0 在车牌字体下极易混淆车管系统也遵循这个规则。这个排除操作一定要在字符集定义阶段完成否则后续点按逻辑里会出现大量冗余判断。const LETTERS ABCDEFGHJKLMNPQRSTUVWXYZ.split() // 去掉 I 和 O const DIGITS 0123456789.split() const PLATE_SIGNS [] // 省份简称由业务方配置这段代码看起来简单但它是整块键盘的基础。字母和数字都存在数组里之后渲染键盘按键时直接遍历数组生成即可不需要在 WXML 里手写几十个按钮。2.2 省份简字面板与字母数字面板的排布方式车牌录入时第一个格子永远只接受省份简称后面所有格子才有字母和数字的输入需求。所以键盘内部需要两种面板省份简称面板和字母数字面板。省份简称面板数量多一屏放不下我采用了分页布局。每页固定显示两行六列共十二个简称字符底部放“上一页”“下一页”“删除”“收起”四个功能键。翻页逻辑内部用 pageIndex 记录切换时简单遍历数组截取渲染即可。字母数字面板是整个键盘的核心区域。我最初的设计是仿照手机九宫格把字母和数字分开展示但很快就发现这样效率很低。用户输入车牌号时第 3 位到第 7 位可能是数字也可能是字母如果字母和数字分开在两个页面用户要频繁切换面板反而更慢。最终我采用了“字母主区 数字底行”的组合面板。字母按顺序排成四行每行六个键数字 0 到 9 单独排在最底部一行。这样在一个屏幕内用户能看到全部可选字母和全部数字不需要任何切换就能完成大多数输入。2.3 新能源车牌与位数差异的处理车牌录入的另一个常见变量是燃油车和新能源车。燃油车号牌字符串长度为 7 位新能源车号牌字符串长度为 8 位。多出的一位来自序号部分。在组件设计里我加了一个 isNewEnergy 开关。它的作用有两个第一控制输入格子总数燃油车渲染 8 个格子但第 8 个永远不可用新能源车渲染 8 个格子全部启用第二调整字母数字面板的快捷提示区。新能源车牌的第三个字符位也就是序号的第一位通常会出现 D 或 F 这样的专用字母。虽然这不意味着其他字母完全不允许但从输入效率上考虑很多用户看到新能源车牌时会优先找 D 和 F。我在字母数字面板顶部做了一个小的快捷栏把新能源专用字母单独放大用户可以直接点。这个处理看似小但对体验提升非常明显。在充电桩业务中很多司机对车牌格式并不敏感只会说“我是新能源绿牌”但你让他回忆第三位是不是 D他根本不知道。快捷栏直接展示出来用户按直觉点选就行。2.4 键盘交互状态机设计车牌录入的交互看起来就是点按键、更新格子但内部其实是一个小型状态机。我自己在实现时把状态分为四种初始状态、输入状态、完成状态、关闭状态。初始状态对应键盘隐藏、格子为空。用户点击输入区域后组件进入输入状态此时根据激活格子位置决定显示哪个面板第 1 格显示省份简称面板其他格子显示字母数字面板。每点击一个按键组件校验该字符在当前位是否合法合法则写入当前格并后移激活位不合法则直接忽略。完成状态有两种触发方式一是用户输满所有格子后点击“完成”按钮二是输入过程中发现所有位都填满自动触发 confirm 事件。关闭状态则是用户点击“收起”按钮或点击键盘遮罩区域此时触发 close 事件键盘隐藏输入焦点回收。这个状态机并不复杂但它保证了整个交互过程是可控的。比如用户输入到第 5 格时突然点了一下最前面的第 1 格组件会把当前激活位切回第 1 格之后的输入都写入第 1 格。没有状态机管理这种光标跳转逻辑很容易写出 bug。3. 核心交互与光标控制的详细实现3.1 输入格子的绘制与光标动画输入区域我用一组 view 格子来实现。每行固定一个格子数组数量由 maxlength 决定。格子的核心样式是等宽等高、左右间距 8rpx、字符居中每个格子底部有一条细边框整体视觉是一个横向的输入框。光标是自绘的不依赖系统光标。实现方式也很简单当前激活的格子额外加一个 active 样式类在这个 class 里用伪元素画一条竖线然后加一条 CSS 闪烁动画。.active-cell::after { content: ; width: 2rpx; height: 36rpx; background: #2B6BFF; animation: blink 1s infinite; } keyframes blink { 0%, 100% { opacity: 1; } 50% { opacity: 0; } }光标动画的细节在于竖线的垂直居中。格子内部除了字符还有伪元素如果字符存在时竖线会跟字符重叠。我的处理是当格子有值时隐藏光标当前激活格有值但用户要修改它时光标仍然显示在字符右侧用 position: relative 往右偏移实现。3.2 激活索引与按位合法性拦截组件内部维护了一个 activatedIndex表示当前正在输入的格子序号。每次用户点击输入区域或者键盘每完成一次写入这个索引都会更新。合法性拦截是组件里最核心的逻辑我把它封装成一个纯函数。它的输入是当前格子索引、候选字符、是否新能源输出是布尔值。function isCharAllowed(index, char, isNewEnergy) { if (index 0) { return PLATE_SIGNS.includes(char) } if (index 1) { return LETTERS.includes(char) } if (isNewEnergy index 2) { return LETTERS.includes(char) || DIGITS.includes(char) } return LETTERS.includes(char) || DIGITS.includes(char) }这段逻辑有一个很微妙的地方第 2 位必须是字母但很多用户会习惯性地点数字。如果不拦截用户输入的号码会直接错位最终提交时校验失败。拦截后用户点数字键没有任何反馈可能觉得键盘失灵。所以我额外加了一个轻提示逻辑当用户在当前位点了不允许的字符类型时格子边框会闪一下红色提示用户当前位只能输入字母。这个提示功能虽然只多了一点代码但极大减少了用户困惑。3.3 已有车牌回填与字符串拆分业务场景里经常遇到“修改车牌”的需求。用户车牌已经存在点开录入组件时需要把已有车牌号直接显示在格子里并把光标定位到最后一个未输入的格子。回填实现时要注意一个坑不能直接用字符串的 length 来循环赋值。车牌字符串中既有中文汉字又有字母数字虽然这里的字符都是单字节或双字节但业务逻辑中最好统一用数组结构处理。const charList Array.from(value) // 按字符拆分避免编码问题回填的完整流程是将组件的 maxlength 设为对应值遍历 charList 填充格子数组剩余格子保持为空再把 activatedIndex 指向第一个空格子。如果车牌已经填满activatedIndex 指向最后一位此时用户点击键盘可以顶格修改最后一位。另外我在组件内部存储值的时候统一不保留空格确认后直接输出一个连续字符串。展示上如果需要风控脱敏业务层再单独处理。3.4 键盘弹出与页面滚动遮挡问题键盘弹出最怕的是挡住输入格子。原生 input 有 adjust-position 自动上推自绘组件没有这种能力所以必须手动处理。我的方案分为两步。第一步组件内的键盘用 position: fixed 定位固定在最底部高度用一个变量管理。第二步监听 activatedIndex 的变化当激活格位于页面下方时页面主动滚动把格子露出来。有些页面用的是 scroll-view 滚动容器这里有个细节scroll-view 内部元素定位成 fixed 会出问题键盘必须挂在页面根节点下面。我通常把键盘组件放在包裹页面全部内容的 view 之后这样无论页面怎么滚动键盘都稳定停留在屏幕底部。view classpage-content !-- 页面其他内容 -- /view plate-keyboard visible{{showKeyboard}} ... /这种挂载方式也是组件被团队复用后踩出来的经验。一开始我把键盘放在 scroll-view 内部真机上经常出现键盘跟着内容一起滚动的情况后来统一改成页面级挂载才稳定。4. 组件对外接口设计及业务接入实战4.1 核心配置项与事件设计组件最终对外暴露的接口要尽量简单。我把它设计成三个配置项和三个事件。配置项类型说明visibleBoolean是否显示键盘valueString组件回显的车牌号maxlengthNumber输入格数量默认8isNewEnergyBoolean是否为新能源车牌事件触发时机change车牌值发生变化confirm点击完成按钮或自动填满close点击收起按钮visible 字段由业务页面控制。这样键盘的显示时机可以完全对接业务逻辑比如用户点击某个入口时才弹出提交成功后主动关闭。confirm 事件会把当前车牌字符串作为参数返回。业务方在回调里做深校验和接口请求。我这里特别建议不要把所有校验逻辑放在组件内部因为不同业务对车牌格式的要求并不完全一致尤其是各省份对字母序号的扩展规则存在差异。组件保证通用合法业务保证业务合法这个分工最清晰。4.2 页面接入与数据接收过程接入一个页面我大致分四步。第一步在页面 json 文件里注册组件。第二步在 wxml 中放置组件传入配置项并绑定事件。第三步在 js 中监听 confirm 事件拿到车牌字符串后做业务校验。第四步业务校验通过后提交接口同时关闭键盘。plate-keyboard visible{{showKeyboard}} value{{plateNo}} is-new-energy{{isNewEnergy}} bind:changeonPlateChange bind:confirmonPlateConfirm bind:closeonKeyboardClose /看起来很简单但实际接入时最容易遗漏的是 visible 初始值。如果页面是新增车牌showKeyboard 默认 false 没问题如果是编辑车牌进入页面需要把 visible 设为 true否则用户看不到键盘还以为组件坏了。4.3 在不同业务场景下的适配变化组件落地后我遇到的第一批业务就有三种不同的车牌需求。停车缴费业务大多只涉及燃油车因此 maxlength 设为 7isNewEnergy 关闭即可。充电桩业务新能源车占比高需要把 isNewEnergy 打开maxlength 自动变成 8。还有一个车辆服务类业务需要用户在组件里选择“临时车牌”或者“无车牌”再录入这个需求组件本身不处理我在页面里加了两个单选入口勾选后直接把组件隐藏。另外在 toB 的物流调度页面里车牌录入往往伴随一个二次确认动作。我在组件外包了一层底部弹层用户录入完车牌后不直接提交而是点击“确认车牌”后再走接口。这种 adapter 套路比较通用组件只需要对外抛出 change 事件页面自己保存中间值即可。4.4 多端小程序平台适配的注意点车牌录入组件不能只盯着一端做很多团队会把它迁移到其他小程序平台上。这里我最深的体会是尽量使用最基础的标签和样式能力不要用任何平台的私有组件。我用的标签只有 view、text、button键盘按键的样式全部用 flex 布局没有依赖 checkbox、form 之类的高层组件。这么做的好处是迁到其他平台时基本只改事件绑定写法即可。还有一个容易被忽略的点底部安全区。全面屏手机底部有一条 home indicator 区域键盘如果贴底布局最低那行按键会被顶开。最终我用 env(safe-area-inset-bottom) 兼容安全区键盘底部留出了安全距离。5. 实操过程中踩过的坑与建议5.1 隐式规则比代码逻辑更容易翻车车牌号的规则我一开始只是知道个大概以为把字母和数字铺上去就行。结果联调时发现第 2 位的发牌机关代号只能是字母不能是数字而我当时允许了数字导致一批测试车牌无法通过后端校验。后来我查阅了一些公开的车牌编码规则资料又把规则细化成前面讲的 isCharAllowed 函数。这里建议做同类功能的读者先跟业务方把规则确认清楚特别是当地对字母序号位是否有限制。有些地区在序号首位不允许字母这个不是通用规则组件层面就不要写死放到业务校验里。我犯过的另一个错误是新能源车牌的第 3 位只放了 D 和 F。实际上不同地区、不同时间发放的新能源号牌第三个字符并不只有这两个字母。把快捷栏限定为 D/F 会导致一部分真实车牌无法录入后来我把快捷栏改为“新能源常见字母优先展示”底层仍然允许全部合法字母。5.2 键盘反复跳动问题排查键盘组件接完第一个版本后同事反馈说在真机上点击输入格键盘会先收起再弹出整个界面闪一下。一开始我怀疑是键盘显示逻辑有问题反复 review 后发现键盘本身没有做销毁重建问题出在点击输入格时触发了页面级 blur。经过排查原因是输入格被设计成 button 组件。button 的默认行为里包含一些焦点逻辑点击后会把当前焦点状态清空导致组件的 visible 状态被联动重置。后面我把所有格子全部改成 view并在 view 上绑定触摸事件彻底绕开 button 的默认行为跳闪问题就消失了。类似的坑还有键盘上不要用 catchtap 和 bindtap 混用同一个按键同时绑定两种事件会触发两次输入。5.3 长按删除与防抖处理删除键看起来简单其实是最容易体验翻车的地方。最初版本只支持单击删除每次点击删除当前格字符空格则回退上一格。用户反馈说清除车牌太慢尤其是要清空 8 位号码时得点 8 次。我后来加了长按连续删除逻辑是触摸删除键超过 400ms 后进入每 120ms 删除一次的循环手指松开立即停止并清理定时器。function handleBackspaceTouchStart() { backspaceTimer setTimeout(() { backspaceTimer setInterval(() { deleteOneChar() }, 120) }, 400) } function handleBackspaceTouchEnd() { clearTimeout(backspaceTimer); clearInterval(backspaceTimer); }这里有个很容易踩的坑删除循环的定时器如果在页面销毁时没有清理会报 setInterval 的警告甚至导致内存回调。组件的 detached 生命周期里一定要加清理逻辑。5.4 用户输入与真实号牌规则的校验分层还有一个关于芯片级细节的建议组件内部的通用校验千万不要试图覆盖所有业务可能。比如某个特殊号牌类型它的整体格式、总位数可能完全不同通用组件一旦针对它做适配其他业务就会被牵连。我在组件里只做极简的位数和字符集校验复杂校验放在业务提交前。我在体验版里放了一版内置完整校验逻辑的组件结果后续给另一个业务用时出现了“上一业务限定的字母规则在新业务不适用”的情况。改回分层校验后问题再没出现过。5.5 数据敏感性与日志规范车牌号本质上属于个人敏感信息虽然很多业务场景里只是作为查询凭证但开发过程中还是要多留个心眼。我在组件里刻意不在 console.log 中输出完整车牌调试时也尽量用脱敏字符串打印。另外提交接口时车牌中的汉字需要做 URL 编码否则部分服务端框架会直接报参数错误。这个坑在联调时出现过一次原因是前端完全没有做 encodeURIComponent汉字直接明文拼在 query 里。建议在统一请求层处理编码而不是每个业务页面单独加。最后再分享一个小技巧。车牌录入组件这类“格式固定、场景通用”的交互特别适合沉淀为团队组件库的公共物料。我做完第一版后后续在三个新业务里复用每次只改配置项、校验函数和一点样式变量没有再多写一遍键盘。如果你也在做类似的小程序表单场景不妨按这个思路把“输入规则 键盘面板 光标交互”拆成独立组件长远来看能省下不少重复开发的成本。
