做车牌号录入这种东西最烦的不是后端接口而是前端那个输入框。系统默认键盘根本不适合车牌这种“短、固定、字符集合特殊”的输入场景尤其在小程序里input 组件弹出的原生键盘又大又乱用户要在全键盘里翻页找省份简称找完还要切数字中间误触输入一个“I”或“O”还得手工删掉。我在一个车辆服务类项目里第一版就被这条交互坑到用户差评后来干脆自己写了一个小程序自定义键盘组件专门做车牌号录入总算把体验救了回来。这篇就把这个组件的完整设计思路和核心实现拆开讲一遍。我会重点说清楚三件事为什么默认键盘搞不定车牌输入组件内部的状态和数据流该怎么设计以及真机上调试会遇到哪些坑。内容偏实操代码主要用原生小程序语法uniapp 或 Taro 这类跨端框架也能平移过去只要理解了底层的交互逻辑换个模板语法只是体力活。1. 为什么车牌号录入非要自己造键盘1.1 系统键盘撑不住车牌号的真实原因车牌号表面看是一串短文本但它有非常明确的格式约束。以最常见的蓝牌为例一共 7 位第一位是省份简称汉字第二位是发证机关字母后面是 5 位字母数字混合序号。新能源绿牌是 8 位多了一位。这个格式意味着第一位只能从固定的 31 个省份汉字里选不能在任意汉字里乱输。字母区有禁用字符I 和 O 跟数字 1、0 太像容易混正规车牌号里根本不该出现。字符长度被严格限制在 7 位或 8 位多输一位也不行少输一位也不对。但系统原生键盘完全不知道这些规则。它给你一个全键盘用户可以随便按输错了你只能靠「删除」键慢慢往回删。最难受的是选省份汉字那一步用户要切到拼音输入法打“京”或者翻好几页去找字这个过程中还经常被输入法联想带跑选错别的同音字。一套操作下来一辆车录入少说十几秒停车场高峰期排队扫码出场的时候这个时间不可接受。另外原生键盘在小程序里还会带来一个很麻烦的联动问题input 聚焦就弹键盘键盘一弹页面adjust-position会把输入框顶到安全区附近但如果你的输入区域在页面中间用户一边看键盘一边看输入位置视野反复横跳体验极其割裂。还有一些输入法自带联想、纠错功能会在你输入车牌字母时强行“帮你”自动补全出来一堆乱七八糟的候选词这些在表单里全部要额外关掉或拦截非常繁琐。1.2 自定义键盘之后体验具体好在哪自定义键盘本质上是把“输入法”降级成一个固定面板。面板上有什么键用户就只能按什么键从源头掐掉错误输入。我做完这个组件之后体感最明显的变化是用户录入车牌不再需要思考了。省份面板打开直接点“京”面板自动切到字母数字后面就一路点到底输完点“完成”。整个过程没有输入法切换、没有联想、没有误触熟练以后两三秒就能录完一辆车。对运营方来说少一次用户输入错误就少一辆车堵在出口这个 ROI 非常直接。从技术上看自定义键盘还有两个隐形好处。一个是组件可以做成全屏弹层键盘和输入格子始终在可视区域内不依赖小程序原生键盘的 adjust 逻辑布局稳定可控另一个是键盘面板可以任意定制字号、键位颜色、新能源车牌的快捷按键、特殊车辆类型这些都能做比什么都靠原生输入法的不可控实现强太多。如果你的业务只是偶尔让用户在表单里填一个车牌没有高频使用场景那我建议继续用系统默认键盘别折腾。自定义键盘适合的是“录入动作频繁、容错要求高”的场景比如停车场缴费、车辆预约、违章查询。为低频表单去维护一套键盘组件反而吃力不讨好。2. 组件设计属性、事件与两类键盘的状态切换2.1 对外接口组件怎么和页面互传数据微信小程序自定义组件要遵循“数据流入、事件流出”的套路。我设计的车牌键盘组件对外只暴露少量属性和事件尽量让使用方不用关心内部细节。核心属性就三个show控制键盘是否可见value接收外部传入的车牌号一般用于回显和重置maxLength控制位数。事件就两个change在每次字符变化时触发把最新的车牌值带给父页面done在用户点“完成”时触发表示录入结束。父页面里的调用代码是这样plate-keyboard show{{showKeyboard}} value{{tempPlate}} maxLength{{7}} bind:changeonPlateChange bind:doneonPlateDone /对应的父页面 JavaScriptPage({ data: { showKeyboard: false, tempPlate: }, onPlateChange(e) { this.setData({ tempPlate: e.detail.value }); }, onPlateDone(e) { const plate e.detail.value; this.setData({ showKeyboard: false, tempPlate: plate }); // 这里可以做格式校验后提交 } });这里有一个很重要的设计取舍value由父页面维护组件内部一般不直接改外部传来的值而是通过triggerEvent把变化抛出去由父页面执行setData再通过属性传给组件回显。这种方式叫“单向数据流”好处是父页面始终知道车牌值的最新状态后续做格式校验、提交上报、同时录入多辆车都只操作父页面的 data不会出现组件和页面各持一份值、最后对不上的问题。2.2 内部状态机两份面板之间的流转逻辑车牌键盘区别于普通数字键盘的核心是它必须维护两个面板省份汉字面板和字母数字面板。这相当于一个两状态的小型状态机切换的触发条件就是当前激活的是哪一位。我把这个状态命名为panelType只有两个值province和alphanumeric。切换规则非常固定当前激活位置是第 0 位键盘一定是省份面板。当前激活位置大于第 0 位键盘一定是字母数字面板。用户点了第 0 位格子面板切回省份。用户点了非第 0 位格子面板切到字母数字。用户第 1 位没填就去点第 3 位不允许焦点不会跳过去。这个状态机的识别逻辑放在几个内部方法里核心就是根据当前填写进度和点击位置动态算出一个新的panelType再setData到视图层渲染。2.3 车牌字符集常量数组怎么定义才不容易出错字符集是组件里最容易写出 bug 的地方因为字符多、又分散。我习惯把两类字符集中定义在组件文件顶部const PROVINCE_CHARS [ 京, 津, 冀, 晋, 蒙, 辽, 吉, 黑, 沪, 苏, 浙, 皖, 闽, 赣, 鲁, 豫, 鄂, 湘, 粤, 桂, 琼, 渝, 川, 贵, 云, 藏, 陕, 甘, 青, 宁, 新 ]; const ALNUM_CHARS [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, A, B, C, D, E, F, G, H, J, K, L, M, N, P, Q, R, S, T, U, V, W, X, Y, Z ];注意ALNUM_CHARS里我故意没有放 I 和 O。这不是遗忘是刻意为之。车牌号里这两个字母跟数字 1、0 太容易混淆用户就算误触也只能选到合法字符这才是自定义键盘的价值。某些特殊车牌类型需要支持“使、领、学、警”这样的字我把PROVINCE_CHARS做成一个数组常量真有这种需求时在数组末尾按需追加即可不需要大改组件逻辑。面板的按键排布不能只放一个扁平的数组渲染层需要按行显示。我写了一个通用的分块函数把一个数组切分成 N 个一组function chunk(arr, size) { const rows []; for (let i 0; i arr.length; i size) { rows.push(arr.slice(i, i size)); } return rows; } Component({ data: { provinceRows: chunk(PROVINCE_CHARS, 8), // 4 行最后一行剩 7 个 alnumRows: chunk(ALNUM_CHARS, 9), // 4 行最后一行剩 7 个 currentValue: , currentIndex: 0, panelType: province, cells: [] } });省份汉字一行放 8 个4 行排完字母数字一行放 9 个4 行排完。这样键盘面板的总高度控制在 300rpx 左右不会把小屏 iPhone 的下半屏全部占掉。这里有个容易被忽略的点组件的 data 里要有一份和maxLength等长的cells数组用来驱动输入格子的渲染。输入框不是用原生 input 做的而是用 view 格子拼出来的所以必须把当前车牌值按位填充到一个固定长度的数组里空位用空字符串表示。这样格子数量恒定样式不会随着输入进度抖动。3. 渲染与交互从点击格子到按键落字的完整链路3.1 车牌输入格子的 WXML 结构输入格子我用了 view 而不是 input因为 view 天然不会唤起原生键盘也就没有“自定义键盘和原生键盘打架”的问题。每个格子是一个固定宽高的容器内容就是当前位上的字符如果这一位正好是当前激活位就额外渲染一个闪烁的光标。核心 WXML 大概长这样view classplate-kb wx:if{{show}} view classplate-cells view wx:for{{cells}} wx:keyindex classcell {{index currentIndex ? cell-active : }} >.cell-cursor { width: 4rpx; height: 44rpx; background: #3478f6; display: inline-block; vertical-align: middle; animation: blink 1s infinite; } keyframes blink { 0%, 50% { opacity: 1; } 50.1%, 100% { opacity: 0; } }这个方案在视觉上跟系统光标几乎没差别但完全受我们控制想让它常亮、闪烁、变色都很容易。3.2 省份键盘与字母数字键盘的键位排布省份面板和字母数字面板的渲染结构一样只是数据源和样式宽度有差异。省份面板的键我给它一个略窄一些的宽度一行塞 8 个字母数字面板一行塞 9 个。代码上直接用wx:for遍历chunk出来的二维数组每一行内部再用一层wx:for渲染按键view classkb-panel wx:if{{panelType province}} view classkb-row wx:for{{provinceRows}} wx:keyindex view classkb-key kb-key-province wx:for{{item}} wx:for-itemch wx:key*this hover-classkb-key-hover >onKeyTap(e) { const key e.currentTarget.dataset.key; if (key delete) { this.handleDelete(); return; } if (key clear) { this.handleClear(); return; } if (key done) { this.handleDone(); return; } const { currentValue, currentIndex, maxLength } this.data; if (currentIndex maxLength) { return; } const arr currentValue.split(); arr[currentIndex] key; const nextIndex currentIndex 1; const nextValue arr.join(); this.setData({ currentValue: nextValue, currentIndex: nextIndex, panelType: nextIndex 0 ? province : alphanumeric }); this.syncCells(); this.triggerEvent(change, { value: nextValue }); }添加字符的逻辑核心是“取当前激活位置从键盘上拿到字符直接塞进当前位置”。因为键盘面板本身没有禁用状态到了最大长度之后currentIndex maxLength判断会直接吞掉后续输入但用户还是会看到“完成”和“删除”按钮不会觉得键盘失灵。handleDelete里我处理过一种情况光标停在中间删除的却是它前一个字符。例如当前车牌是“京A123”光标在第 3 位的“1”上按删除应该把“A”删掉光标回到第 2 位。如果直接把当前位的值删除就会把“1”删掉和用户直觉相反。所以我用的是“删光标前一位”的策略handleDelete() { const { currentValue, currentIndex } this.data; const arr currentValue.split(); if (!arr.length) { return; } let idx currentIndex; // 光标如果没有落在已有字符上就回退到最后一个字符 if (idx arr.length) { idx arr.length - 1; } if (idx 0) { arr.shift(); } else { arr.splice(idx - 1, 1); idx idx - 1; } const nextValue arr.join(); this.setData({ currentValue: nextValue, currentIndex: idx, panelType: idx 0 ? province : alphanumeric }); this.syncCells(); this.triggerEvent(change, { value: nextValue }); }清空和完成就简单多了handleClear() { this.setData({ currentValue: , currentIndex: 0, panelType: province }); this.syncCells(); this.triggerEvent(change, { value: }); } handleDone() { this.triggerEvent(done, { value: this.data.currentValue }); }整个数据流的闭环是键盘按键 - 更新 currentValue - 同步 cells - 触发 change 事件 - 父页面更新自己的 data - 通过 value 属性回填组件。组件本身不存“提交状态”也不做网络请求职责非常单一这也是它能复用到多个业务场景里的原因。4. 输入定位与多车场景真正好用的小细节4.1 点击格子任意回改定位逻辑的“最后一公里”一个车牌键盘如果只能按顺序输入用户输错一位要全部删掉重来那体验反而比系统键盘更差。所以组件必须支持“点击任意已输入格子回改”。我实现的onCellTap逻辑只有几行onCellTap(e) { const index Number(e.currentTarget.dataset.index); if (index this.data.currentValue.length) { return; } this.setData({ currentIndex: index, panelType: index 0 ? province : alphanumeric }); }限制只有一条index不能大于当前已输入的字符数。也就是说用户只能点击“已经填了字符的格子”或者“恰好等于已填字符数的那一个空格”。比如已经输入了“京A”光标可以点到 0、1、2 位但不能直接点到第 3、4 位。这个限制是故意的它维持了键盘面板和当前位的绑定关系点第 0 位就切省份键盘点其他位置就切字母数字键盘如果随便点后面的空格也切面板用户反而会困惑“为什么现在我还没输入就直接到这一位了”。回改时还有一个细节如果光标点在第 0 位面板会切回省份键盘但用户原先已输入的第 1 位之后的内容并不会丢失。修改完第 0 位后currentIndex会自动推到 1面板切回字母数字。整个修改过程是流畅的不需要用户重新输入整条车牌。4.2 同时录入多辆车的复用方案停车场项目里经常会遇到“一次录多辆车”的需求。如果每个输入框都挂一个独立的键盘组件实例你会发现页面非常卡因为每个键盘都在渲染几十个按键节点还要各自维护数据状态。我在实际项目中是“一个页面只保留一个键盘组件”配合一个activeIndex来区分当前正在编辑的是列表里的哪一辆车。父页面维护一个车牌数组data: { plateList: [], // 所有车的车牌 activePlateIndex: -1, // 当前正在编辑的是第几辆 showKeyboard: false }点击列表里某一条时onEditPlate(e) { const index e.currentTarget.dataset.index; this.setData({ activePlateIndex: index, showKeyboard: true, tempPlate: this.data.plateList[index] || }); }组件触发 change 时父页面根据activePlateIndex更新对应位置的车牌onPlateChange(e) { const value e.detail.value; const key plateList[${this.data.activePlateIndex}]; this.setData({ [key]: value, tempPlate: value }); }这个方案的好处是键盘永远只有一个实例渲染压力小组件状态也简单。代价是父页面多维护一个activePlateIndex但这点代价换来的是性能和可维护性非常值。如果你在列表里循环渲染多个键盘页面会在创建和销毁实例上浪费大量时间我不建议这么做。4.3 键盘弹出、页面遮挡与安全区适配自定义键盘本质是一个固定的底部弹层所以它天然会遇到两个问题弹出时背景页面可能被穿透滚动以及 iPhone 底部小黑条的安全区。穿透滚动的问题很好解决在键盘最外层容器上加catchtouchmove阻止触摸事件冒泡或者在底部加一层透明的遮罩。我用的是 catch 方案好处是不需要额外写遮罩节点view classplate-kb wx:if{{show}} catchtouchmovenoop !-- 键盘内容 -- /view组件里写一个空方法noop() {}就行。这样用户在键盘区域滑动时背景列表不会跟着滚。安全区适配是另一个高频踩坑点。键盘贴底的时候如果没处理env(safe-area-inset-bottom)iPhone X 系列的底部按钮会被 Home Indicator 压住一部分点击区域变小看上去也很别扭。我给键盘容器统一加.plate-kb { padding-bottom: env(safe-area-inset-bottom); }样式写好后一定要拿真机看一遍因为开发者工具的模拟器不会真实渲染小黑条你在这里看永远是美观的上真机就露馅。我通常会在组件里把底部功能键的高度做得稍微大一点比如 88rpx保证安全区内边距占掉一部分之后用户实际可点的区域依然足够大。还有一个页面布局建议车牌输入组件最好做成一个独立的弹层页面结构输入格子在键盘上方固定展示中间区域是滚动内容这样彻底避开“键盘遮住输入格子”的问题。不要把输入格子放在页面底部然后期待键盘弹起时它正好在键盘上方因为每台手机的视口高度、安全区高度都不同靠“刚好”是不可靠的。5. 实测与踩坑落地到页面才是开始5.1 模拟器正常、真机失灵的老毛病组件写完之后第一版我在开发者工具上点得很开心逻辑、样式全部正常。结果一到真机第一批问题全冒出来了键盘底部按钮在 iPhone 上距离底部太近点击时经常触发 iOS 的手势区域。快速连续点击多个键时偶发出现“当前位跳了两格”或者“字符写入错位”的情况。部分安卓机型上点击键盘按键会带出一小段灰色高亮像是网页里的 tap 高亮残留。第一条通过安全区 padding 解决上面已经说过。第二条其实是setData异步渲染和用户快速点击造成的时序问题。用户一秒内点了三个键每次 tap 都基于旧的currentValue计算第三个数还没等第二次的数据渲染完就写进来了结果就是数据覆盖。我的处理方式是在onKeyTap入口加了一个简单的锁onKeyTap(e) { if (this.data.isHandling) return; this.setData({ isHandling: true }); // 原有逻辑 ... setTimeout(() { this.setData({ isHandling: false }); }, 50); }50 毫秒的锁足够挡住物理上的快速误触又不会让用户感觉键盘迟钝。这是一个比较笨但有效的办法实测下来再没出现连点错位的情况。如果你追求更精细的方案可以在按键事件里把所有操作改成基于当前 data 的快照计算但因为 setData 本身是异步的快照方案写起来复杂很多对车牌键盘这种低频输入场景来说加锁已经够用。第三条是安卓 WebView 的默认触摸反馈给按键加上.kb-key { -webkit-tap-highlight-color: transparent; }再配合hover-class做自定义反馈问题就没了。5.2 组件内外部的 value 同步一个隐蔽的循环更新坑组件里我用了observers监听外部传入的value。最开始版本我只在observers里做了currentValue的同步结果出现了一个隐蔽 bug父页面在 change 事件里把新值 setData 回去组件 observers 收到新 value 后又执行了一次syncCells这个逻辑本身没问题但我在 observers 里顺手把currentIndex也重置了导致用户输入到第 5 位时每次按键后光标都会被拽回到第 0 位看起来像键盘失灵。解决后的 observer 逻辑是这样observers: { value(value) { if (value ! this.data.currentValue) { this.setData({ currentValue: value }); this.syncCells(); } }, maxLength() { this.syncCells(); } }同步外部 value 时只更新currentValue不碰currentIndex和panelType这两个状态只由组件内部的交互逻辑控制。只有一种特殊情况需要重置内部状态外部主动把 value 清空比如用户提交成功后父页面把车牌置空这时候要把currentIndex和panelType都归位否则键盘还停留在字母数字面板下一辆车录入时会觉得不对劲observers: { value(value) { if (value ) { this.setData({ currentValue: , currentIndex: 0, panelType: province }); } else if (value ! this.data.currentValue) { this.setData({ currentValue: value }); } this.syncCells(); } }这个坑的根因是“内部状态和外部状态职责没分清”。现在组件内部有两个独立的状态维度一个是内容状态currentValue一个是交互状态currentIndex/panelType。外部 value 只能驱动内容状态交互状态必须保留给组件自己的操作决定。想清楚这一点很多类似的组件同步问题都能避开。5.3 提交前的格式校验组件只能防呆不能防全部自定义键盘把字符集合限制死已经拦截了 99% 的非法输入但组件并不保证用户输了一条格式完整的车牌。比如用户只输了 6 位就点完成或者第二位输成了数字这些逻辑错误键盘管不着还得在提交时做一次校验。我用的校验规则是const isPlateValid (plate, maxLength) { if (!plate || plate.length ! maxLength) return false; if (!/^[\u4e00-\u9fa5]$/.test(plate[0])) return false; if (!/[A-Z]/.test(plate[1])) return false; if (/[IO]/.test(plate.slice(2))) return false; return /^[A-Z0-9]$/.test(plate.slice(2)); };第一条判断长度第二条判断首位是汉字第三条判断第二位是字母最后一条处理后面部分的字母数字混合校验同时排除 I 和 O。这个正则严格说仍然不是官方校验车牌规则在不同车辆类型上还有一些细微差别但作为前端拦截已经完全够用。真正的合法性判断仍然要看后端前端校验只是为了早点提醒用户别让错误数据跑到提交接口那一层。如果你们业务还分了新能源绿牌和黄牌校验规则还要再细化比如新能源车第 2 位通常固定是 D 或 F或者允许 8 位。这些扩展点可以在组件参数上做但代码结构完全不用动只需要把 maxLength 和校验正则换成对应规则即可。5.4 一些可以继续往下卷的体验细节核心功能跑通后我发现还有几个体验细节值得加它们不会改变组件的整体结构但会明显提升用户感受。第一个是键盘按键的字号。省份汉字在 30rpx 下看得很清楚但字母数字混排的面板上有些数字比如 0 和字母 O 已经去掉了一个剩下的还是容易看混。如果后续要做定制可以在数字键和字母键上加一点微弱的背景色差异让用户扫一眼就知道数字在哪、字母在哪不需要逐个去找。第二个是输入满位时的“完成”强化。当currentValue.length maxLength时底部“完成”键我用更强的背景色突出让用户意识到可以收工了。这是个小到不能再小的细节但停车场的用户普遍年纪偏大视觉提示比文字提示更重要。第三个是震动反馈。真机上每次按键触发一次轻微震动能模拟实体按键的手感我用wx.vibrateShort试过Android 上反馈明显iOS 上会比较轻用户普遍反馈“录车牌像在按实体键盘”。前提是调低震动强度不要用wx.vibrateLong那个震感太重频繁按键反而让人烦躁。这些细节没有一个是复杂度层面的难点但它们决定了一个键盘组件是“看起来能用”还是“真正好用”。封装自定义键盘这件事做到 80 分靠逻辑正确剩下 20 分全在交互手感上。我自己的经验是宁可多花一个版本迭代去打磨这些手感也不要在逻辑没跑稳的时候急着堆花哨功能。现在这个组件已经在项目里稳定跑了两个迭代。后来回头看当初最让我头疼的“input 弹起原生键盘”的问题用纯 view 方案从根上绕开了真正花时间的反而是光标定位、字符集控制这些看起来不起眼的细节。如果你正打算做或者已经在做车牌录入希望这篇能帮你少踩几个我已经踩过的坑。
做车牌号录入这种东西最烦的不是后端接口而是前端那个输入框。系统默认键盘根本不适合车牌这种“短、固定、字符集合特殊”的输入场景尤其在小程序里input 组件弹出的原生键盘又大又乱用户要在全键盘里翻页找省份简称找完还要切数字中间误触输入一个“I”或“O”还得手工删掉。我在一个车辆服务类项目里第一版就被这条交互坑到用户差评后来干脆自己写了一个小程序自定义键盘组件专门做车牌号录入总算把体验救了回来。这篇就把这个组件的完整设计思路和核心实现拆开讲一遍。我会重点说清楚三件事为什么默认键盘搞不定车牌输入组件内部的状态和数据流该怎么设计以及真机上调试会遇到哪些坑。内容偏实操代码主要用原生小程序语法uniapp 或 Taro 这类跨端框架也能平移过去只要理解了底层的交互逻辑换个模板语法只是体力活。1. 为什么车牌号录入非要自己造键盘1.1 系统键盘撑不住车牌号的真实原因车牌号表面看是一串短文本但它有非常明确的格式约束。以最常见的蓝牌为例一共 7 位第一位是省份简称汉字第二位是发证机关字母后面是 5 位字母数字混合序号。新能源绿牌是 8 位多了一位。这个格式意味着第一位只能从固定的 31 个省份汉字里选不能在任意汉字里乱输。字母区有禁用字符I 和 O 跟数字 1、0 太像容易混正规车牌号里根本不该出现。字符长度被严格限制在 7 位或 8 位多输一位也不行少输一位也不对。但系统原生键盘完全不知道这些规则。它给你一个全键盘用户可以随便按输错了你只能靠「删除」键慢慢往回删。最难受的是选省份汉字那一步用户要切到拼音输入法打“京”或者翻好几页去找字这个过程中还经常被输入法联想带跑选错别的同音字。一套操作下来一辆车录入少说十几秒停车场高峰期排队扫码出场的时候这个时间不可接受。另外原生键盘在小程序里还会带来一个很麻烦的联动问题input 聚焦就弹键盘键盘一弹页面adjust-position会把输入框顶到安全区附近但如果你的输入区域在页面中间用户一边看键盘一边看输入位置视野反复横跳体验极其割裂。还有一些输入法自带联想、纠错功能会在你输入车牌字母时强行“帮你”自动补全出来一堆乱七八糟的候选词这些在表单里全部要额外关掉或拦截非常繁琐。1.2 自定义键盘之后体验具体好在哪自定义键盘本质上是把“输入法”降级成一个固定面板。面板上有什么键用户就只能按什么键从源头掐掉错误输入。我做完这个组件之后体感最明显的变化是用户录入车牌不再需要思考了。省份面板打开直接点“京”面板自动切到字母数字后面就一路点到底输完点“完成”。整个过程没有输入法切换、没有联想、没有误触熟练以后两三秒就能录完一辆车。对运营方来说少一次用户输入错误就少一辆车堵在出口这个 ROI 非常直接。从技术上看自定义键盘还有两个隐形好处。一个是组件可以做成全屏弹层键盘和输入格子始终在可视区域内不依赖小程序原生键盘的 adjust 逻辑布局稳定可控另一个是键盘面板可以任意定制字号、键位颜色、新能源车牌的快捷按键、特殊车辆类型这些都能做比什么都靠原生输入法的不可控实现强太多。如果你的业务只是偶尔让用户在表单里填一个车牌没有高频使用场景那我建议继续用系统默认键盘别折腾。自定义键盘适合的是“录入动作频繁、容错要求高”的场景比如停车场缴费、车辆预约、违章查询。为低频表单去维护一套键盘组件反而吃力不讨好。2. 组件设计属性、事件与两类键盘的状态切换2.1 对外接口组件怎么和页面互传数据微信小程序自定义组件要遵循“数据流入、事件流出”的套路。我设计的车牌键盘组件对外只暴露少量属性和事件尽量让使用方不用关心内部细节。核心属性就三个show控制键盘是否可见value接收外部传入的车牌号一般用于回显和重置maxLength控制位数。事件就两个change在每次字符变化时触发把最新的车牌值带给父页面done在用户点“完成”时触发表示录入结束。父页面里的调用代码是这样plate-keyboard show{{showKeyboard}} value{{tempPlate}} maxLength{{7}} bind:changeonPlateChange bind:doneonPlateDone /对应的父页面 JavaScriptPage({ data: { showKeyboard: false, tempPlate: }, onPlateChange(e) { this.setData({ tempPlate: e.detail.value }); }, onPlateDone(e) { const plate e.detail.value; this.setData({ showKeyboard: false, tempPlate: plate }); // 这里可以做格式校验后提交 } });这里有一个很重要的设计取舍value由父页面维护组件内部一般不直接改外部传来的值而是通过triggerEvent把变化抛出去由父页面执行setData再通过属性传给组件回显。这种方式叫“单向数据流”好处是父页面始终知道车牌值的最新状态后续做格式校验、提交上报、同时录入多辆车都只操作父页面的 data不会出现组件和页面各持一份值、最后对不上的问题。2.2 内部状态机两份面板之间的流转逻辑车牌键盘区别于普通数字键盘的核心是它必须维护两个面板省份汉字面板和字母数字面板。这相当于一个两状态的小型状态机切换的触发条件就是当前激活的是哪一位。我把这个状态命名为panelType只有两个值province和alphanumeric。切换规则非常固定当前激活位置是第 0 位键盘一定是省份面板。当前激活位置大于第 0 位键盘一定是字母数字面板。用户点了第 0 位格子面板切回省份。用户点了非第 0 位格子面板切到字母数字。用户第 1 位没填就去点第 3 位不允许焦点不会跳过去。这个状态机的识别逻辑放在几个内部方法里核心就是根据当前填写进度和点击位置动态算出一个新的panelType再setData到视图层渲染。2.3 车牌字符集常量数组怎么定义才不容易出错字符集是组件里最容易写出 bug 的地方因为字符多、又分散。我习惯把两类字符集中定义在组件文件顶部const PROVINCE_CHARS [ 京, 津, 冀, 晋, 蒙, 辽, 吉, 黑, 沪, 苏, 浙, 皖, 闽, 赣, 鲁, 豫, 鄂, 湘, 粤, 桂, 琼, 渝, 川, 贵, 云, 藏, 陕, 甘, 青, 宁, 新 ]; const ALNUM_CHARS [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, A, B, C, D, E, F, G, H, J, K, L, M, N, P, Q, R, S, T, U, V, W, X, Y, Z ];注意ALNUM_CHARS里我故意没有放 I 和 O。这不是遗忘是刻意为之。车牌号里这两个字母跟数字 1、0 太容易混淆用户就算误触也只能选到合法字符这才是自定义键盘的价值。某些特殊车牌类型需要支持“使、领、学、警”这样的字我把PROVINCE_CHARS做成一个数组常量真有这种需求时在数组末尾按需追加即可不需要大改组件逻辑。面板的按键排布不能只放一个扁平的数组渲染层需要按行显示。我写了一个通用的分块函数把一个数组切分成 N 个一组function chunk(arr, size) { const rows []; for (let i 0; i arr.length; i size) { rows.push(arr.slice(i, i size)); } return rows; } Component({ data: { provinceRows: chunk(PROVINCE_CHARS, 8), // 4 行最后一行剩 7 个 alnumRows: chunk(ALNUM_CHARS, 9), // 4 行最后一行剩 7 个 currentValue: , currentIndex: 0, panelType: province, cells: [] } });省份汉字一行放 8 个4 行排完字母数字一行放 9 个4 行排完。这样键盘面板的总高度控制在 300rpx 左右不会把小屏 iPhone 的下半屏全部占掉。这里有个容易被忽略的点组件的 data 里要有一份和maxLength等长的cells数组用来驱动输入格子的渲染。输入框不是用原生 input 做的而是用 view 格子拼出来的所以必须把当前车牌值按位填充到一个固定长度的数组里空位用空字符串表示。这样格子数量恒定样式不会随着输入进度抖动。3. 渲染与交互从点击格子到按键落字的完整链路3.1 车牌输入格子的 WXML 结构输入格子我用了 view 而不是 input因为 view 天然不会唤起原生键盘也就没有“自定义键盘和原生键盘打架”的问题。每个格子是一个固定宽高的容器内容就是当前位上的字符如果这一位正好是当前激活位就额外渲染一个闪烁的光标。核心 WXML 大概长这样view classplate-kb wx:if{{show}} view classplate-cells view wx:for{{cells}} wx:keyindex classcell {{index currentIndex ? cell-active : }} >.cell-cursor { width: 4rpx; height: 44rpx; background: #3478f6; display: inline-block; vertical-align: middle; animation: blink 1s infinite; } keyframes blink { 0%, 50% { opacity: 1; } 50.1%, 100% { opacity: 0; } }这个方案在视觉上跟系统光标几乎没差别但完全受我们控制想让它常亮、闪烁、变色都很容易。3.2 省份键盘与字母数字键盘的键位排布省份面板和字母数字面板的渲染结构一样只是数据源和样式宽度有差异。省份面板的键我给它一个略窄一些的宽度一行塞 8 个字母数字面板一行塞 9 个。代码上直接用wx:for遍历chunk出来的二维数组每一行内部再用一层wx:for渲染按键view classkb-panel wx:if{{panelType province}} view classkb-row wx:for{{provinceRows}} wx:keyindex view classkb-key kb-key-province wx:for{{item}} wx:for-itemch wx:key*this hover-classkb-key-hover >onKeyTap(e) { const key e.currentTarget.dataset.key; if (key delete) { this.handleDelete(); return; } if (key clear) { this.handleClear(); return; } if (key done) { this.handleDone(); return; } const { currentValue, currentIndex, maxLength } this.data; if (currentIndex maxLength) { return; } const arr currentValue.split(); arr[currentIndex] key; const nextIndex currentIndex 1; const nextValue arr.join(); this.setData({ currentValue: nextValue, currentIndex: nextIndex, panelType: nextIndex 0 ? province : alphanumeric }); this.syncCells(); this.triggerEvent(change, { value: nextValue }); }添加字符的逻辑核心是“取当前激活位置从键盘上拿到字符直接塞进当前位置”。因为键盘面板本身没有禁用状态到了最大长度之后currentIndex maxLength判断会直接吞掉后续输入但用户还是会看到“完成”和“删除”按钮不会觉得键盘失灵。handleDelete里我处理过一种情况光标停在中间删除的却是它前一个字符。例如当前车牌是“京A123”光标在第 3 位的“1”上按删除应该把“A”删掉光标回到第 2 位。如果直接把当前位的值删除就会把“1”删掉和用户直觉相反。所以我用的是“删光标前一位”的策略handleDelete() { const { currentValue, currentIndex } this.data; const arr currentValue.split(); if (!arr.length) { return; } let idx currentIndex; // 光标如果没有落在已有字符上就回退到最后一个字符 if (idx arr.length) { idx arr.length - 1; } if (idx 0) { arr.shift(); } else { arr.splice(idx - 1, 1); idx idx - 1; } const nextValue arr.join(); this.setData({ currentValue: nextValue, currentIndex: idx, panelType: idx 0 ? province : alphanumeric }); this.syncCells(); this.triggerEvent(change, { value: nextValue }); }清空和完成就简单多了handleClear() { this.setData({ currentValue: , currentIndex: 0, panelType: province }); this.syncCells(); this.triggerEvent(change, { value: }); } handleDone() { this.triggerEvent(done, { value: this.data.currentValue }); }整个数据流的闭环是键盘按键 - 更新 currentValue - 同步 cells - 触发 change 事件 - 父页面更新自己的 data - 通过 value 属性回填组件。组件本身不存“提交状态”也不做网络请求职责非常单一这也是它能复用到多个业务场景里的原因。4. 输入定位与多车场景真正好用的小细节4.1 点击格子任意回改定位逻辑的“最后一公里”一个车牌键盘如果只能按顺序输入用户输错一位要全部删掉重来那体验反而比系统键盘更差。所以组件必须支持“点击任意已输入格子回改”。我实现的onCellTap逻辑只有几行onCellTap(e) { const index Number(e.currentTarget.dataset.index); if (index this.data.currentValue.length) { return; } this.setData({ currentIndex: index, panelType: index 0 ? province : alphanumeric }); }限制只有一条index不能大于当前已输入的字符数。也就是说用户只能点击“已经填了字符的格子”或者“恰好等于已填字符数的那一个空格”。比如已经输入了“京A”光标可以点到 0、1、2 位但不能直接点到第 3、4 位。这个限制是故意的它维持了键盘面板和当前位的绑定关系点第 0 位就切省份键盘点其他位置就切字母数字键盘如果随便点后面的空格也切面板用户反而会困惑“为什么现在我还没输入就直接到这一位了”。回改时还有一个细节如果光标点在第 0 位面板会切回省份键盘但用户原先已输入的第 1 位之后的内容并不会丢失。修改完第 0 位后currentIndex会自动推到 1面板切回字母数字。整个修改过程是流畅的不需要用户重新输入整条车牌。4.2 同时录入多辆车的复用方案停车场项目里经常会遇到“一次录多辆车”的需求。如果每个输入框都挂一个独立的键盘组件实例你会发现页面非常卡因为每个键盘都在渲染几十个按键节点还要各自维护数据状态。我在实际项目中是“一个页面只保留一个键盘组件”配合一个activeIndex来区分当前正在编辑的是列表里的哪一辆车。父页面维护一个车牌数组data: { plateList: [], // 所有车的车牌 activePlateIndex: -1, // 当前正在编辑的是第几辆 showKeyboard: false }点击列表里某一条时onEditPlate(e) { const index e.currentTarget.dataset.index; this.setData({ activePlateIndex: index, showKeyboard: true, tempPlate: this.data.plateList[index] || }); }组件触发 change 时父页面根据activePlateIndex更新对应位置的车牌onPlateChange(e) { const value e.detail.value; const key plateList[${this.data.activePlateIndex}]; this.setData({ [key]: value, tempPlate: value }); }这个方案的好处是键盘永远只有一个实例渲染压力小组件状态也简单。代价是父页面多维护一个activePlateIndex但这点代价换来的是性能和可维护性非常值。如果你在列表里循环渲染多个键盘页面会在创建和销毁实例上浪费大量时间我不建议这么做。4.3 键盘弹出、页面遮挡与安全区适配自定义键盘本质是一个固定的底部弹层所以它天然会遇到两个问题弹出时背景页面可能被穿透滚动以及 iPhone 底部小黑条的安全区。穿透滚动的问题很好解决在键盘最外层容器上加catchtouchmove阻止触摸事件冒泡或者在底部加一层透明的遮罩。我用的是 catch 方案好处是不需要额外写遮罩节点view classplate-kb wx:if{{show}} catchtouchmovenoop !-- 键盘内容 -- /view组件里写一个空方法noop() {}就行。这样用户在键盘区域滑动时背景列表不会跟着滚。安全区适配是另一个高频踩坑点。键盘贴底的时候如果没处理env(safe-area-inset-bottom)iPhone X 系列的底部按钮会被 Home Indicator 压住一部分点击区域变小看上去也很别扭。我给键盘容器统一加.plate-kb { padding-bottom: env(safe-area-inset-bottom); }样式写好后一定要拿真机看一遍因为开发者工具的模拟器不会真实渲染小黑条你在这里看永远是美观的上真机就露馅。我通常会在组件里把底部功能键的高度做得稍微大一点比如 88rpx保证安全区内边距占掉一部分之后用户实际可点的区域依然足够大。还有一个页面布局建议车牌输入组件最好做成一个独立的弹层页面结构输入格子在键盘上方固定展示中间区域是滚动内容这样彻底避开“键盘遮住输入格子”的问题。不要把输入格子放在页面底部然后期待键盘弹起时它正好在键盘上方因为每台手机的视口高度、安全区高度都不同靠“刚好”是不可靠的。5. 实测与踩坑落地到页面才是开始5.1 模拟器正常、真机失灵的老毛病组件写完之后第一版我在开发者工具上点得很开心逻辑、样式全部正常。结果一到真机第一批问题全冒出来了键盘底部按钮在 iPhone 上距离底部太近点击时经常触发 iOS 的手势区域。快速连续点击多个键时偶发出现“当前位跳了两格”或者“字符写入错位”的情况。部分安卓机型上点击键盘按键会带出一小段灰色高亮像是网页里的 tap 高亮残留。第一条通过安全区 padding 解决上面已经说过。第二条其实是setData异步渲染和用户快速点击造成的时序问题。用户一秒内点了三个键每次 tap 都基于旧的currentValue计算第三个数还没等第二次的数据渲染完就写进来了结果就是数据覆盖。我的处理方式是在onKeyTap入口加了一个简单的锁onKeyTap(e) { if (this.data.isHandling) return; this.setData({ isHandling: true }); // 原有逻辑 ... setTimeout(() { this.setData({ isHandling: false }); }, 50); }50 毫秒的锁足够挡住物理上的快速误触又不会让用户感觉键盘迟钝。这是一个比较笨但有效的办法实测下来再没出现连点错位的情况。如果你追求更精细的方案可以在按键事件里把所有操作改成基于当前 data 的快照计算但因为 setData 本身是异步的快照方案写起来复杂很多对车牌键盘这种低频输入场景来说加锁已经够用。第三条是安卓 WebView 的默认触摸反馈给按键加上.kb-key { -webkit-tap-highlight-color: transparent; }再配合hover-class做自定义反馈问题就没了。5.2 组件内外部的 value 同步一个隐蔽的循环更新坑组件里我用了observers监听外部传入的value。最开始版本我只在observers里做了currentValue的同步结果出现了一个隐蔽 bug父页面在 change 事件里把新值 setData 回去组件 observers 收到新 value 后又执行了一次syncCells这个逻辑本身没问题但我在 observers 里顺手把currentIndex也重置了导致用户输入到第 5 位时每次按键后光标都会被拽回到第 0 位看起来像键盘失灵。解决后的 observer 逻辑是这样observers: { value(value) { if (value ! this.data.currentValue) { this.setData({ currentValue: value }); this.syncCells(); } }, maxLength() { this.syncCells(); } }同步外部 value 时只更新currentValue不碰currentIndex和panelType这两个状态只由组件内部的交互逻辑控制。只有一种特殊情况需要重置内部状态外部主动把 value 清空比如用户提交成功后父页面把车牌置空这时候要把currentIndex和panelType都归位否则键盘还停留在字母数字面板下一辆车录入时会觉得不对劲observers: { value(value) { if (value ) { this.setData({ currentValue: , currentIndex: 0, panelType: province }); } else if (value ! this.data.currentValue) { this.setData({ currentValue: value }); } this.syncCells(); } }这个坑的根因是“内部状态和外部状态职责没分清”。现在组件内部有两个独立的状态维度一个是内容状态currentValue一个是交互状态currentIndex/panelType。外部 value 只能驱动内容状态交互状态必须保留给组件自己的操作决定。想清楚这一点很多类似的组件同步问题都能避开。5.3 提交前的格式校验组件只能防呆不能防全部自定义键盘把字符集合限制死已经拦截了 99% 的非法输入但组件并不保证用户输了一条格式完整的车牌。比如用户只输了 6 位就点完成或者第二位输成了数字这些逻辑错误键盘管不着还得在提交时做一次校验。我用的校验规则是const isPlateValid (plate, maxLength) { if (!plate || plate.length ! maxLength) return false; if (!/^[\u4e00-\u9fa5]$/.test(plate[0])) return false; if (!/[A-Z]/.test(plate[1])) return false; if (/[IO]/.test(plate.slice(2))) return false; return /^[A-Z0-9]$/.test(plate.slice(2)); };第一条判断长度第二条判断首位是汉字第三条判断第二位是字母最后一条处理后面部分的字母数字混合校验同时排除 I 和 O。这个正则严格说仍然不是官方校验车牌规则在不同车辆类型上还有一些细微差别但作为前端拦截已经完全够用。真正的合法性判断仍然要看后端前端校验只是为了早点提醒用户别让错误数据跑到提交接口那一层。如果你们业务还分了新能源绿牌和黄牌校验规则还要再细化比如新能源车第 2 位通常固定是 D 或 F或者允许 8 位。这些扩展点可以在组件参数上做但代码结构完全不用动只需要把 maxLength 和校验正则换成对应规则即可。5.4 一些可以继续往下卷的体验细节核心功能跑通后我发现还有几个体验细节值得加它们不会改变组件的整体结构但会明显提升用户感受。第一个是键盘按键的字号。省份汉字在 30rpx 下看得很清楚但字母数字混排的面板上有些数字比如 0 和字母 O 已经去掉了一个剩下的还是容易看混。如果后续要做定制可以在数字键和字母键上加一点微弱的背景色差异让用户扫一眼就知道数字在哪、字母在哪不需要逐个去找。第二个是输入满位时的“完成”强化。当currentValue.length maxLength时底部“完成”键我用更强的背景色突出让用户意识到可以收工了。这是个小到不能再小的细节但停车场的用户普遍年纪偏大视觉提示比文字提示更重要。第三个是震动反馈。真机上每次按键触发一次轻微震动能模拟实体按键的手感我用wx.vibrateShort试过Android 上反馈明显iOS 上会比较轻用户普遍反馈“录车牌像在按实体键盘”。前提是调低震动强度不要用wx.vibrateLong那个震感太重频繁按键反而让人烦躁。这些细节没有一个是复杂度层面的难点但它们决定了一个键盘组件是“看起来能用”还是“真正好用”。封装自定义键盘这件事做到 80 分靠逻辑正确剩下 20 分全在交互手感上。我自己的经验是宁可多花一个版本迭代去打磨这些手感也不要在逻辑没跑稳的时候急着堆花哨功能。现在这个组件已经在项目里稳定跑了两个迭代。后来回头看当初最让我头疼的“input 弹起原生键盘”的问题用纯 view 方案从根上绕开了真正花时间的反而是光标定位、字符集控制这些看起来不起眼的细节。如果你正打算做或者已经在做车牌录入希望这篇能帮你少踩几个我已经踩过的坑。
