挪车二维码系统是一类把「留电话」换成「留码」的小工具：车主输入手机号与车牌，生成一张贴在车窗上的二维码，被挡车的人扫码即可拨号或发短信。整套逻辑纯前端运行，车主信息不上传服务器，是这类工具能否被接受的分界线。

挪车二维码系统是一类什么工具？

是一类「用一个码换一串号码」的小工具。

车主在小程序或网页里填两样东西：手机号、车牌号。 点生成，得到一张可直接下载的二维码图片，打印后贴在车窗上。挡车的人扫码，页面上显示车牌与一个按钮，点下去就是拨号。

它的功能极少，但每一步都有明确理由。没有多余的注册、没有会员体系、没有后台管理——因为它的使用场景只有一次：被挡车的人需要立刻把人叫来。任何多余的一步，都会让这次联系失败。

与通用的 二维码生成系统源码 相比，这类工具的差别不在生成算法，而在生成的目的是「传递一个动作」而不是「传递一段数据」。这个差别决定了后面所有的设计取舍。

为什么这类工具必须做成纯前端？

因为要处理的是车主本人不愿意公开的信息。

把手机号直接写在挡风玻璃上，等于向所有路过的人公开。挪车码想解决的就是这件事——只有真的需要联系的人才会去扫。

但如果生成过程把号码上传到服务器，问题就回来了：号库存进了别人的数据库，泄露风险从车窗转移到了后台。 所以这类工具普遍选择纯前端实现：输入的号码只存在于当前设备的内存与本地存储里，用完即走。

这个选择还有一个实际好处：不需要服务器，也就不需要运维、不需要备案一堆接口、没有持续成本。 对开发者来说，这是典型的「用架构选择换掉运营负担」。

二维码里到底存了什么？

存的是「怎么联系」而不是「联系方式本身」。

扫码后看到的是一个页面，页面上有车牌与联系方式按钮。点按钮触发的是本机的拨号动作，号码并不会以明文形式展示在被扫页面之外。

这个设计带来两个直接效果。一是纸条被拍照转发时，号码不会随之扩散，因为照片里只有码；二是车主可以随时重新生成，旧码即便流出也可以弃用。

需要说清楚的是，这层保护是流程上的，不是密码学上的。它不是加密，而是把「谁能看到号码」这件事收窄到「当场扫码的人」。对于挪车这个场景，这个强度是够的。

短信模板为什么值得单独做？

因为挡车的人往往不知道该怎么说。

现实里最常见的挪车短信是短的、急的，甚至带着火气。**预设一段「您的车挡住我了，麻烦挪一下，谢谢」**既省去组织语言的麻烦，也让语气缓和下来。

模板能改，比固定一句更实用。不同场景说法不一样：占用固定车位、堵住出入口、只是临时挡住，措辞都要调整。允许车主自己写一段默认文案，等于把这个工具从「能用」推到「好用」。

另一个细节是一键拨号与短信并存。有人愿意打电话，有人只想发条消息。两种都留着，被联系到的概率才高。

选型时优先核对哪几项？

四项。

其一，数据是否本地处理。 有无上传行为，这是这类工具的第一准则。其二，生成与下载。 码图能否高清保存，能否适配不同尺寸的车窗贴纸。其三，联系动作。 拨号与短信能否一键触发，模板是否可改。其四，设备适配。 手机端与平板是否都能正常显示。

如果手上不止一个这类小工具，把它们收进一个入口的做法，可参考 多功能聚合工具箱 的组织方式——轻工具的复购率低，靠组合起来的使用频率来留住人。

要摆正一个预期：这类工具的价值不在于技术难度，而在于「它替车主挡掉了一次信息暴露」。 一个下午就能实现的功能，真正难的是想清楚该不该上传——而这个判断，比代码本身重要得多。