企业官网建设流程全解析

车牌号码输入这个需求，我在三四个项目里都碰到过，从最早的停车缴费小程序，到后来的车险报案、二手车估价、充电桩绑定，几乎每隔一阵就要重写一遍。它看起来只是「一个输入框的事」，但真做起来，普通 input 会把你折磨得够呛。这篇就聊聊在微信小程序里实现车牌号码输入的完整思路——包括车牌键盘怎么排布、校验逻辑怎么写、新能源八位车牌怎么自动扩展、iOS 真机上那些诡异的错位问题怎么处理，都会给出可以直接复制的代码。不管你是刚接触小程序的前端新手，还是已经做过几个项目的老手，这套组件化的实现方式应该都能直接用得上。

1. 车牌输入为什么不能直接用 input：需求拆解与方案选型

1.1 先看一个真实场景：为什么车牌输入这么难伺候

小程序里做表单，绝大多数字段一个<input>就完事了，姓名、手机号、地址都还好。唯独车牌，只要产品经理在需求文档上写下「车牌号码」四个字，后面必然跟着一串括号注释：需要校验、需要键盘、需要支持新能源。这不是产品经理为难开发，而是车牌本身的规则决定的。

先说省份简称。车牌第一个字符只能是「京津冀晋蒙辽吉黑沪苏浙皖闽赣鲁豫鄂湘粤桂琼渝川贵云藏陕甘青宁新」这 31 个汉字之一，用户如果手动打字，很可能打成同音字或者繁简混用，比如把「粤」写成「奥」，把「沪」写成「户」。再说字母，民用号牌的字母表里没有 I 和 O，因为这两个字母和数字 1、0 太像了，交警眼睛都会看花，所以标准里直接把它们剔除了。用户不知道这个规则，输入了「粤BIO123」，你的后端接口一校验直接报错，用户还以为是 App 崩了。

还有新能源车牌带来的位数变化。传统燃油车牌是 7 位，新能源车牌是 8 位。这意味着你的输入框不能写死 7 个格子，得根据用户输入的内容动态判断。如果用户先输了「粤B」，你显示 7 格；输到第 3 位是 D 或者 F，你就得立刻把格子扩展到 8 个。这个交互细节如果处理不好，用户会先输 7 位被判定「不完整」，然后再尴尬地发现还得再加一位。

最后是系统键盘的问题。调用系统自带的文本键盘，弹出的是全键盘，用户得在几十个按键里找那个省份汉字，还要切到符号页找字母，输入一个车牌至少要点二十下屏幕。更麻烦的是 iOS 上系统键盘会顶起页面、遮挡输入框，你还得额外处理adjust-position、滚动定位那一堆事。所以结论很明确：不要用系统键盘，自己画一个。

1.2 三种常见实现方案的横向对比

我把市面上能见到的方案梳理了一下，主要就三种。

第一种是原生 input + 正则校验。做法最简单，一个<input type="text">加上maxlength="8"，用户输完了用正则校验一次，不通过就给个红字提示。优点是十分钟就能写完，缺点是体验极差——用户要自己切键盘、自己找汉字、自己数位数。这种方案我只在一些内部工具类小程序里见过，面向 C 端的产品基本不会这么做。

第二种是自定义车牌键盘组件。输入框只负责展示，不接收系统输入（设置disabled或者干脆用view展示），页面底部弹出一个自己画的键盘面板，上面分两个 Tab：省份页和字母数字页。用户点一下省份，再点字母数字，整个过程全在拇指可及的范围内，八下点击就能输完。这是目前主流的做法，也是我这篇要重点讲的方案。

第三种是摄像头识别车牌自动填充。调起wx.chooseMedia或者用camera组件拍一张照，上传到后端做 OCR 识别，把结果回填到输入框里。这个方案体验最好，但成本也最高：需要服务端有识别能力，有网络延迟，识别准确率受光线和角度影响，而且用户第一次使用时往往不愿意授权摄像头。我的建议是把它当作辅助入口而不是主入口，键盘为主，拍照识别作为键盘右上角的一个小图标存在。

1.3 我的技术选型与理由

综合下来，我选的是自定义键盘 + 客户端逐位校验 + 组件化封装这条路线，具体拆成三层：底层是一个纯键盘组件plate-keyboard，只负责渲染按键和把点击事件抛出去；中间是plate-input组件，管数据、管校验、管格子的动态扩展；最上层是业务页面，只关心拿到的车牌字符串对不对。

为什么要拆成两层？因为键盘这个东西是可以复用的。你做车险报案的时候会有「车牌号码」和「车架号」两个字段，车架号是 17 位纯字母数字，同样需要自定义键盘。如果键盘组件独立出来，改一个mode属性就能复用，不用重写一遍布局。组件化的另一个好处是校验逻辑集中在plate-input里，业务页面不用关心正则，只监听change事件拿结果就行。

还有一个理由是关于可控性。全部逻辑握在自己手里，意味着你可以对用户的每一步输入做约束——第一位只能选省份，第二位只能选字母，第三位之后才能选数字，从源头上就不可能输入非法字符。这比输完之后再弹一个「格式错误」的红字提示要友好得多，因为在车牌这种场景下，用户根本不知道错误出在哪里。

提示：如果你的项目是用 uni-app 开发的，这套思路完全通用，只需要把wx:for换成v-for、把bindtap换成@click，样式单位从 rpx 保持不变即可。审批的坑后面我会单独说。

2. 车牌号码规则吃透：校验逻辑的地基

2.1 字符位与长度：7 位与 8 位的区别到底在哪

要写校验，先把标准搞明白。我按民用最常见的几类梳理一遍，军车、警车、使领馆这些特种号牌普通 C 端产品基本用不上，可以暂不处理。

普通小型汽车号牌，也就是街上最多的蓝色车牌，结构是「省份简称 + 发牌机关代号字母 + 5 位序号」，总共 7 位。序号部分是数字和字母混排的，标准规定序号中字母不超过 2 个，且不能出现 I 和 O。实际校验时可以放宽一点，只要保证 5 位都是合法的数字或字母就行，不必严格限制字母个数，因为接口那边一般也不会卡这么死。

小型新能源汽车号牌，绿牌，结构是「省份简称 + 发牌机关代号字母 + D/F + 5 位数字」，总共 8 位。这里的第三位 D 代表纯电动，F 代表非纯电动（包含插电混动、增程式、燃料电池）。注意标准里后 5 位是纯数字，不是字母数字混排，这一点很关键，很多网上的正则都写错了。

大型新能源汽车号牌，也是绿牌，但结构和小型的不一样，是「省份简称 + 发牌机关代号字母 + 5 位数字 + D/F」，总共 8 位，字母在最后一位。这种车你在路上见得少，一般是公交、大巴、货车，但校验逻辑里必须考虑进去，否则用户输对了反而被你的代码判成错误。

大型汽车号牌，黄牌，结构和普通小型车一样是 7 位，只是序号部分规则略有差异，前端校验可以复用同一套逻辑。

所以长度判断可以简化成一句话：7 位是常规，8 位是新能源。8 位的判断依据是看 D/F 出现在第 3 位还是第 8 位。

2.2 省份简称与发牌机关代号字母表

省份简称一共 31 个，我在代码里直接写成了常量数组，这样比正则里的中文区间更直观也更好维护：

const PROVINCES = [ '京','津','冀','晋','蒙','辽','吉','黑','沪','苏','浙', '皖','闽','赣','鲁','豫','鄂','湘','粤','桂','琼','渝', '川','贵','云','藏','陕','甘','青','宁','新' ];

发牌机关代号用的是 24 个大写字母，也就是从 A 到 Z 里去掉 I 和 O：

const LETTERS = 'ABCDEFGHJKLMNPQRSTUVWXYZ'.split(''); const NUMBERS = '0123456789'.split(''); const ALNUM = NUMBERS.concat(LETTERS); // 34 个字符，正好铺满键盘

这里有个小细节值得说一下：34 个字符铺在 7 列网格里，就是 4 行 28 个再加 6 个，第 5 行正好放 6 个字符加一个删除键，刚好 35 格，布局非常规整。省份是 31 个，7 列铺 4 行是 28 个，第 5 行放剩下 3 个省份加删除键、收起键，也刚好凑满一行。也就是说键盘网格固定 7 列 5 行，两种模式都不会出现半格，视觉上非常舒服。这不是巧合，是我在真机上试了三四个版本才调到这个数的。

2.3 校验函数怎么写才不误杀

校验这件事，我的原则是宁可宽一点，也不要误杀合法车牌。前端校验的作用是拦截明显错误、给用户即时反馈，真正严格的合法性判断交给后端和交管接口。基于这个原则，我写的校验函数长这样：

function validatePlate(raw) { const plate = (raw || '').toUpperCase().replace(/\s/g, ''); const len = plate.length; if (len !== 7 && len !== 8) { return { valid: false, msg: '车牌号应为 7 位或 8 位' }; } if (!PROVINCES.includes(plate[0])) { return { valid: false, msg: '第一位应为省份简称' }; } if (!/^[A-HJ-NP-Z]$/.test(plate[1])) { return { valid: false, msg: '第二位应为发牌机关字母' }; } const rest = plate.slice(2); // 从第三位开始的剩余部分 if (len === 7) { if (!/^[A-HJ-NP-Z0-9]{5}$/.test(rest)) { return { valid: false, msg: '后 5 位应为数字或字母' }; } return { valid: true, type: 'normal', plate }; } // 8 位：小型新能源的第 3 位是 D/F，大型新能源的第 8 位是 D/F if (/^[DF][0-9]{5}$/.test(rest)) { return { valid: true, type: 'newEnergySmall', plate }; } if (/^[0-9]{5}[DF]$/.test(rest)) { return { valid: true, type: 'newEnergyLarge', plate }; } return { valid: false, msg: '新能源号牌字母 D/F 位置不正确' }; }

这段代码里有几个值得展开的地方。第一，plate[1]用的是[A-HJ-NP-Z]这个正则区间，它把 I 和 O 天然排除掉了，比先判断是不是字母再判断是不是 I/O 要简洁。你拆开看就明白：A 到 H 是一段，跳过 I，J 到 N 是一段，跳过 O，P 到 Z 是一段，三段拼起来就是完整的合法字母表。

第二，8 位的两个分支顺序不能颠倒。先判断^[DF][0-9]{5}$（小型新能源），再判断^[0-9]{5}[DF]$（大型新能源），因为前者要求后 5 位是纯数字，后者要求前 5 位是纯数字，两者不会同时匹配，顺序其实无所谓，但写清楚能让人一眼看出区别。

第三，返回值里带了type字段，这个字段在后面有用。比如车险业务里，新能源和燃油车的保费计算方式不一样，前端拿到 type 就能直接做差异化展示，不用再判断一次。

注意：不要在前端做「序号中字母不超过 2 个」这类严格限制。我最初加了这条规则，结果用户输入「粤BD1234F」这种早期试点号牌时被拦住了，投诉了好几次。前端只拦结构性错误，业务性错误交给后端。

3. 组件化设计：把车牌键盘拆成能复用的积木

3.1 目录结构与组件划分

整个方案的目录结构是这样组织的，键盘和输入框分开放：

components/ plate-keyboard/ 纯键盘组件，只负责渲染和抛事件 index.js index.json index.wxml index.wxss plate-input/ 车牌输入框组件，管数据和校验 index.js index.json index.wxml index.wxss utils/ plate.js 省份常量、字母表、校验函数 pages/ index/ 业务页面

plate-keyboard的职责边界非常清晰：它不关心输入了几个字符，也不关心校验结果，它只接收一个mode参数决定显示省份页还是字母数字页，用户点了哪个键就用triggerEvent把键值抛出去。这样设计的好处是，键盘可以脱离车牌场景单独使用。比如你要做身份证输入，只需要改一下字符集，键盘本体一行代码都不用动。

plate-input是业务组件，它维护车牌数组、控制 7 格还是 8 格、调用校验函数、通过change事件把结果传给页面。页面里只需要写一行<plate-input value="{{plate}}" bind:change="onPlateChange" />，剩下的全在组件里完成。

utils/plate.js里放常量表和校验函数，这样做是为了让多个组件共享同一份规则。如果哪天业务要支持「使」字开头的使领馆号牌，只需要改这一个文件，所有用到车牌的地方自动生效。

3.2 数据模型与状态流转

组件内部的核心数据结构是三个：

data: { plateChars: ['', '', '', '', '', '', ''], // 固定 7 格起步 slotCount: 7, // 当前显示几格 activeIndex: 0, // 当前待输入的下标，用于高亮 keyboardVisible: false, keyboardMode: 'province', // province | alnum errorMsg: '' }

plateChars是关键。我不用一个字符串存车牌，而是用定长数组，因为数组能直接映射到界面上的格子，plateChars[i]非空就渲染字符，为空就渲染占位符。用字符串的话还得处理length和补位，反而麻烦。

slotCount控制显示几格。初始是 7，当用户输入到第 3 位时，如果这个字符是 D 或 F，立刻把slotCount改成 8，同时给plateChars追加一个空字符串。如果用户删除了第 3 位，或者删除到只剩 2 位，就把slotCount收回 7，同时把plateChars截断。这个「动态扩展」的逻辑是整段代码里最容易出 bug 的地方，我后面会专门讲。

activeIndex是当前光标位置，等于plateChars中从前往后第一个空位的下标。每次输入或删除都重新计算一次。界面上的高亮边框就绑在这个下标上，用户一眼就能看出该输哪一位。

keyboardMode的切换规则也很简单：当activeIndex === 0时用省份模式，activeIndex >= 1时用字母数字模式。但要注意，如果用户点了删除键回到第 0 位，键盘不能整块重绘，只能切换模式，否则会闪一下。这个体验细节在小程序里特别明显，因为setData触发的是局部渲染，键盘面板的节点会被重建。

3.3 组件对外接口设计

plate-input对外暴露的properties很简单：

对外抛出的事件有两个：

• change：每次输入或删除都触发，detail里包含{ value, valid, type, msg }。value是拼好的字符串，valid是校验结果，type是车牌类型。页面拿到这个事件就可以即时更新提交按钮的可用状态。
• confirm：用户点键盘右下角「完成」时触发，只有在valid为true时才抛出，避免页面收到半截车牌就去调接口。

历史记录我用的是本地存储，键名plate_history，最多存 5 条，去重后按最近使用排序。这个功能是我在一个停车缴费小程序里加上的，因为很多用户是给自己家的两辆车缴费，来回输入很烦。加上历史记录之后，第二次输入只要点一下就行，转化率肉眼可见地提升。数据存的是完整的车牌字符串，读取时判断一下合法性再展示。

4. 核心代码逐段落地

4.1 WXML：车牌格子与键盘面板结构

先看plate-input的结构。格子的渲染用的是plateChars数组，配合activeIndex做高亮：

<view class="plate-input-wrap"> <view class="plate-slots" bindtap="openKeyboard"> <view wx:for="{{plateChars}}" wx:key="index" class="slot {{activeIndex === index ? 'slot-active' : ''}} {{item ? 'slot-filled' : ''}}" > <text wx:if="{{item}}">{{item}}</text> <text wx:else class="slot-placeholder">{{index === 0 ? '省' : '·'}}</text> </view> </view> <view class="plate-error" wx:if="{{errorMsg}}">{{errorMsg}}</view> <block wx:if="{{showHistory && history.length > 0}}"> <view class="plate-history"> <text wx:for="{{history}}" wx:key="*this" class="history-item" ><view class="kb-mask" wx:if="{{visible}}" catchtap="onClose" catchtouchmove="noop"></view> <view class="kb-panel {{visible ? 'kb-panel-show' : ''}}" catchtouchmove="noop"> <view class="kb-header"> <text class="kb-tip">{{mode === 'province' ? '请选择省份简称' : '请选择字母或数字'}}</text> <text class="kb-close" catchtap="onClose">收起</text> </view> <view class="kb-grid" wx:if="{{mode === 'province'}}"> <view wx:for="{{provinces}}" wx:key="*this" class="kb-key" hover-class="kb-key-hover" >.kb-panel { position: fixed; left: 0; right: 0; bottom: 0; z-index: 1000; background: #f7f7f7; border-radius: 24rpx 24rpx 0 0; padding-bottom: calc(12rpx + env(safe-area-inset-bottom)); transform: translateY(100%); transition: transform 0.24s ease-out; box-sizing: border-box; } .kb-panel-show { transform: translateY(0); }

env(safe-area-inset-bottom)在小程序里是可用的，基础库 2.x 之后都支持。如果你的项目要兼容很老的机型，可以用wx.getWindowInfo()拿到safeArea自己算，但说实话现在没必要了，直接用env就行。

格子的宽度计算上，7 列布局我用的是 flex 加百分比，而不是写死 rpx：

.kb-grid { display: flex; flex-wrap: wrap; padding: 12rpx 16rpx; } .kb-key { width: calc(100% / 7 - 12rpx); height: 84rpx; margin: 6rpx; display: flex; align-items: center; justify-content: center; font-size: 32rpx; color: #1a1a1a; background: #ffffff; border-radius: 12rpx; box-sizing: border-box; } .kb-key-hover { background: #e6f0ff; transform: scale(0.96); } .kb-key-fn { background: #e8e8e8; font-size: 28rpx; color: #666666; }

为什么不写死96rpx而是用calc(100% / 7 - 12rpx)？因为不同机型上屏幕宽度对应的 rpx 换算是一样的，但如果你哪天要改成 8 列布局，写死的宽度就得一个个改。用百分比计算，改一个数字就行。这个小习惯我保持了好几年，省心。

输入框格子的样式也顺带说一下。每个格子固定宽度，中间用留白分隔，第一位加一个略大的处理，因为汉字比字母数字视觉上更重：

.plate-slots { display: flex; align-items: center; justify-content: space-between; padding: 24rpx 32rpx; background: #ffffff; border-radius: 16rpx; } .slot { flex: 1; height: 88rpx; margin: 0 6rpx; display: flex; align-items: center; justify-content: center; font-size: 36rpx; font-weight: 600; color: #1a1a1a; background: #f2f4f7; border-radius: 10rpx; border: 2rpx solid transparent; box-sizing: border-box; } .slot-active { border-color: #1677ff; background: #eef4ff; } .slot-placeholder { color: #c8ccd4; font-weight: 400; font-size: 30rpx; }

4.3 JS：按键写入、删除、键盘模式自动切换

核心逻辑集中在plate-input的onKeyTap和onDelete两个方法上。先看输入：

onKeyTap(e) { const key = e.detail.key; const { plateChars, slotCount, activeIndex } = this.data; if (activeIndex >= slotCount) return; // 已满，忽略 const next = plateChars.slice(); next[activeIndex] = key; // 第 3 位（下标 2）输入 D/F 时，自动扩展到 8 位 let newSlotCount = slotCount; if (activeIndex === 2 && (key === 'D' || key === 'F') && slotCount === 7) { next.push(''); newSlotCount = 8; } const str = next.join(''); const result = validatePlate(str); const isFull = next.slice(0, newSlotCount).every(c => c !== ''); this.setData({ plateChars: next, slotCount: newSlotCount, activeIndex: Math.min(activeIndex + 1, newSlotCount - 1), keyboardMode: activeIndex + 1 === 0 ? 'province' : 'alnum', errorMsg: isFull && !result.valid ? result.msg : '' }); this.triggerEvent('change', { value: str, valid: isFull && result.valid, type: result.type || '', msg: result.msg || '' }); }

这段代码里有几个关键设计。第一，activeIndex用Math.min做了上限保护，防止数组越界。第二，自动扩展只在activeIndex === 2且当前是 7 格时触发，这是小型新能源号牌的特征位置，不会误伤大型新能源。第三，errorMsg只在输入满了之后才显示，输入过程中不报错，避免用户输到第 3 位就看到一片红。这个细节很影响体感，我早期的版本是一边输一边校验一边报错，用户被红字晃得头晕，后来改成输满才提示，投诉就没了。

再看删除：

onDelete() { let { plateChars, slotCount, activeIndex } = this.data; // 如果当前光标后面还有字符，说明是回退编辑，先清掉最后一位 const lastFilled = plateChars.slice(0, slotCount).reduce((acc, cur, idx) => { return cur !== '' ? idx : acc; }, -1); if (lastFilled < 0) { this.closeKeyboard(); return; } const next = plateChars.slice(); next[lastFilled] = ''; let newSlotCount = slotCount; // 第 3 位被清空后，8 格收回 7 格 if (lastFilled < 2 && slotCount === 8) { next.pop(); newSlotCount = 7; } const str = next.join(''); const result = validatePlate(str); this.setData({ plateChars: next, slotCount: newSlotCount, activeIndex: Math.min(lastFilled, newSlotCount - 1), keyboardMode: lastFilled === 0 ? 'province' : 'alnum', errorMsg: '' }); this.triggerEvent('change', { value: str, valid: false, type: result.type || '', msg: '' }); }

删除逻辑我用的是「找最后一个非空位」而不是简单地activeIndex - 1。为什么？因为用户可能点了历史记录回填，或者外部传入了初始值，这时候activeIndex和实际字符位置可能不一致。用reduce扫一遍找出真实位置，逻辑更稳。这个写法比用lastIndexOf靠谱，因为数组里可能有多段连续空格。

4.4 页面接入：父子通信与表单提交

页面这一层就非常轻了，基本就是接事件、控状态：

Page({ data: { plate: '', plateValid: false, submitting: false }, onPlateChange(e) { const { value, valid } = e.detail; this.setData({ plate: value, plateValid: valid }); }, onPlateConfirm(e) { if (this.data.submitting) return; this.setData({ submitting: true }); wx.request({ url: 'https://your-domain.com/api/vehicle/bind', method: 'POST', data: { plate: e.detail.value }, success: (res) => { // 处理结果 }, complete: () => { this.setData({ submitting: false }); } }); } });

submitting这个标志位是必须的。小程序的点击事件在真机上有时会连着触发两次，网络慢的时候用户等不及也会连点，没有这个锁很容易重复提交。这个坑我在线上环境吃过一次，用户同一个车牌绑了三条记录，排查了半天才定位到是重复提交。

5. 效果图与真机实测记录

5.1 开发者工具与真机上的界面效果

因为这里没法直接贴图，我用字符画的方式把两个状态的界面结构画出来，你在做设计稿的时候可以照着这个比例摆。

输入框默认状态，7 个格子，第一个格子高亮：

+--------------------------------------------------+ | +----+ +----+ +----+ +----+ +----+ +----+ +----+ | | | 省 | | · | | · | | · | | · | | · | | · | | | +----+ +----+ +----+ +----+ +----+ +----+ +----+ | +--------------------------------------------------+ 最近使用： 粤B12345 沪A88888

用户输入到第 3 位是 D 的时候，界面立刻变成 8 格：

+---------------------------------------------------------------+ | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | | | 粤 | | B | | D | | · | | · | | · | | · | | · | | | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | +---------------------------------------------------------------+

键盘面板的省份模式，7 列 5 行，最后一行放剩下的省份和删除键：

+--------------------------------------------------------+ | 请选择省份简称 收起 | +--------------------------------------------------------+ | 京 津 冀 晋 蒙 辽 吉 | | 黑 沪 苏 浙 皖 闽 赣 | | 鲁 豫 鄂 湘 粤 桂 琼 | | 渝 川 贵 云 藏 陕 甘 | | 青 宁 新 删除 | +--------------------------------------------------------+

切换到字母数字模式后，34 个字符排 5 行，最后一行是 6 个字符加删除：

+--------------------------------------------------------+ | 请选择字母或数字 收起 | +--------------------------------------------------------+ | 0 1 2 3 4 5 6 | | 7 8 9 A B C D | | E F G H J K L | | M N P Q R S T | | U V W X Y Z 删除 | +--------------------------------------------------------+

这个排布我在开发者工具里预览完之后，又在 iPhone 13、iPhone SE、一台红米和一台华为上各跑了一遍。iPhone SE 这种小屏机型上，按键高度 84rpx 换算下来大概是 42pt，比 iOS 系统键盘的按键（约 42pt）基本一致，拇指点起来不挤。如果是在大屏安卓机上，按键会显得更宽松一些，视觉上没有违和感。

5.2 iOS 与 Android 的差异清单

真机测试的时候有几个差异必须记录清楚，不然上线之后容易出问题。

第一是动画性能。键盘面板的transform: translateY过渡，iOS 上非常跟手，Android 中低端机上偶尔会有轻微掉帧。如果你特别在意，可以用wx.createAnimation的step版本，或者干脆去掉过渡直接显示。我个人的取舍是保留过渡，因为在旗舰机上都挺流畅，中低端机的轻微掉帧用户基本感知不到。

第二是安全区计算。env(safe-area-inset-bottom)在 iOS 上取值正常，但在部分安卓机型上返回 0。所以键盘底部除了安全区，还要额外留 12rpx 的内边距兜底。这个数值是我试出来的：留太少，横条会贴着按键；留太多，键盘整体变高，屏幕小的机型会挤掉输入框的可见性。

第三是长按行为。小程序里长按一个view在某些安卓机型上会弹出系统菜单或者触发选中文本。我在所有按键上都加了user-select: none和-webkit-touch-callout: none，避免长按出岔子。iOS 上还要注意-webkit-user-select: none，Safari 内核对这个属性比较敏感。

第四是字体渲染。省份简称是中文，iOS 上默认会用苹方，安卓上各家 ROM 的默认字体不一样，比如有些用思源黑体，有些用自家的定制字体。同一个「粤」字在两台机器上宽度可能差 1-2px，7 列布局里看起来会稍微有点不齐。解决办法是给键盘按键显式指定font-family，优先用系统内嵌的无衬线字体，实在不行就统一字号和行高，把视觉差异压到最小。

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

6.1 问题速查表

下面这些是我在实际项目里遇到并解决的问题，整理成表格方便你对着排查：

6.2 几个我实际踩过的坑

第一个坑是动态扩展格子的时机。我最早的方案是等用户输满 7 位之后再判断要不要扩展，结果用户输完「粤BD1234」7 位，界面显示「已完成」，但校验直接报「新能源号牌位置错误」。用户莫名其妙，明明看着输满了。后来我把扩展提前到第 3 位，只要输入 D/F 就立刻变成 8 格，用户一眼就知道还要再输一位。这个改动看起来小，但对转化率的影响很大，因为用户不会疑惑「为什么输满了还不对」。

第二个坑是删除时的布局抖动。8 格收回到 7 格的那一刻，7 个格子的宽度会重新计算，视觉上会有一次跳动。解决方法是给每个格子设flex: 1加上过渡动画，让宽度变化显得平滑。另外要注意，如果用户是在第 2 位以前删除的，直接弹回 7 格可能会让已经输入的字符位置发生视觉位移，所以我把activeIndex和slotCount放在同一个setData里更新，让它们在同一帧渲染完成，避免两次渲染造成跳动。

第三个坑是本地历史记录的类型。我一开始把历史记录存成了字符串，后来想加一个「这辆车最近绑定的时间」，改成对象数组之后忘了清空旧数据，结果wx.getStorageSync读到的是老格式的字符串数组，item.plate取出来是 undefined，页面上显示一片空白。解决办法是加一个版本号，键名从plate_history改成plate_history_v2，或者在读取时做一次类型判断和丢弃。这个教训是通用的：凡是存到本地的数据，都要考虑格式升级。

第四个坑是回车键和确认键的位置。有的用户输完之后不会去点键盘上的「完成」，而是习惯性地找页面上的提交按钮。但你键盘弹起来会盖住页面的下半部分，提交按钮很可能被压在键盘下面。我的处理是在键盘右上角放一个「收起」按钮，同时把页面的提交按钮固定在键盘上方，键盘弹起时它跟着上移。这样无论用户是点完成还是点提交，都在拇指可及范围内。

提示：如果你用的是自绘键盘 + 页面按钮的布局，记得给页面主体容器留出足够的padding-bottom，高度至少等于键盘高度加安全区。否则内容会被键盘永久遮挡，用户往下滑都看不到。

第五个坑是基础库版本。env()环境变量、wx.getWindowInfo()这些 API 在不同基础库版本上的表现不一样。我在app.json里显式声明了"requiredBackgroundModes"之外，还在项目的project.config.json里设置了最低基础库版本 2.20.0。这样做能保证env()一定生效，代价是会挡住一小部分老版本用户。如果你的产品对覆盖率要求极高，可以降到 2.10.0，然后自己在 JS 里用wx.getSystemInfoSync()算一遍安全区兜底。

第六个坑是输入框的点击热区。格子本身的尺寸不大，如果只有格子可点，用户经常点不中。我的做法是把整个plate-slots容器都绑上openKeyboard，用户点格子之间的空白也能唤起键盘。这个改动看起来微不足道，但真机测试时用户的误触率明显下降，尤其在颠簸的车里输入的时候。

7. 这套方案还能怎么扩展

7.1 接入摄像头识别做辅助入口

前面提到的 OCR 方案，我建议这样接入：在键盘的右上角放一个「拍照识别」的图标，用户点了之后调起wx.chooseMedia，拿到图片后上传到后端做识别，识别结果回填到plate-input的value属性里。

这里有个细节要注意：回填的时候不要把整个组件重新创建一次，而是走properties的observer。在plate-input的observers里监听value变化，变化时重新拆分数组、跑一遍校验、更新activeIndex。这样用户体验是连贯的，不会出现组件闪一下的情况。

另外，识别结果不一定准，比如把「粤」识别成「奥」，把「0」识别成「O」。所以回填之后还是要让用户看到格子里的内容，允许他手动改。我一般的做法是回填之后不自动提交，而是让用户确认一次再走提交逻辑。

7.2 无感校验与体验细节的进一步打磨

用了这套组件之后，还可以做一些更细的体验优化。比如输入停顿 800 毫秒自动校验并调后端预检接口，如果这个车牌已经在系统里绑定过，直接弹出提示让用户去解绑，而不是等他填完整个表单再报错。这个思路在会员卡、车辆管理类的小程序里特别有用。

再比如输入历史按使用频率排序，而不是单纯按时间。用户可以固定自己的常用车，不用每次都翻历史列表。这个功能我用一个简单的计数字段实现，每次使用某条历史就给它加一，读取时按计数降序排。数据量小的时候完全够用，不需要上数据库。

还有车牌归属地展示。用户输完省份和字母之后，直接显示「广东·深圳」，这个信息在服务端是现成的映射表，前端也可以内置一份精简版。用户看到归属地确认无误再提交，能减少很多因为省份简称打错导致的纠错成本。我在一个异地年检的业务里加了这个小功能，客服关于「车牌填错了怎么办」的工单量大概少了三成。

最后说一个个人体会：车牌输入这种组件，代码量不大，但细节的密度特别高。每一次改动都要在真机上跑一遍，模拟器上看着没问题的东西，到了 iOS 上可能就是另一种表现。我现在的习惯是，任何一个涉及键盘、安全区、滚动穿透的改动，都必须在 iPhone 和一台安卓机上各测一次，然后再提交。省下的返工时间，远比那几分钟测试成本高得多。