十年程序员的家务事：为老婆做商城，帮小叔做收银台，顺便优化人生

耗时多年开发了一套面向个体商户的线上线下销售系统，支持小程序商城、门店收银、点餐外卖等功能。系统基于uniapp云开发，无需后端服务器维护，避免了第三方平台抽成和限制。开发过程中经历了多次需求迭代：最初为小叔开发收银系统，后为妻子的服装店开发小程序商城，再为小叔的烧烤店扩展了点餐功能。系统包含库存管理、销售统计、多端适配等功能，并解决了热敏打印、库存校验、配送范围计算等技术难点。作者通过组件化开发

Mosowe

909人浏览 · 2025-07-30 12:00:30

Mosowe · 2025-07-30 12:00:30 发布

最近做完了一个系统，对个我个人来说，工程量还是蛮大的，经历了很长时间的开发，优化，测试，最终完成。

这个系统主要是给个体户用的，可以是服饰，电器，也可以是餐饮，可以使用小程序线上商城销售快递邮寄，也可以是线下门店收银、点餐或外卖，只需要相关的资质，就可以使用。没有第三方抽成，没有第三方要手续费，也没有第三方的各种条条框框的限制。

先看结果

在这里插入图片描述

前期谋划

源自几年前想着做一个管理系统，基于 uniapp 云开发的，当时就只是想磨炼一下云开发技术，想着以后做系统啥的不用再找人做后端，也不想自己去搞服务器，然后搭建环境，还要用 nodejs 或者 python 写接口，以前这么搞过，时间金钱都对于我来说比较耗费巨大，服务器维护这块我也是愣头青。

因为 uniapp，让我轻松了很多，不需要学习其他如安卓 ios 技术就可以实现轻松的跨端，服务器我也不需要去维护，windows 桌面化也有了 electron 帮忙，因为我也不想去申请域名和备案，嫌麻烦。

在此构想下，就摸索着 uniapp 云开发。

没有用官方推荐的 uni-id 系统，而是自己摸索着搭建一个，自己整理初期的需求，需要封装的功能，需要整理的配置数据等。

小打小闹搞了几个后，最后确定了现在的 web 端框架，然后就在这个基础上缓慢的迭代。

遇到一些后端功能处理问题的时候，就会向后端 java 同事咨询，看看他们是怎么处理的，然后借鉴他们的思路，再在云函数里面去处理。

做好了系统权限，token 校验，基本的商品分类与商品列表等。采用的均是云函数模式开发。

此时的初心是做一个线下线上可以销售的系统，包含 web 管理端可以收银，微信小程序商城端。当下就部分完成了 web 端，进展很缓慢。。。

为了保证自己能够在后期迭代中能够清除自己已经有了哪些功能，我使用了百度脑图作为迭代需求的记录本。做一个功能前会琢磨一些光阴来梳理功能，包括数据库设计，可能会需要的东西等等记录下来。如果不先理清楚个大概，直接开发是会混乱的。还有就是养成良好的注释习惯、文档整理习惯。

来了个小需求

后来有一天，小叔跟我说他想搞个收银的，不想用别人现成的，原话大概是：别人就给一个 pda，啥也看不到，就知道收钱，卖了啥赚了多少，什么都看不到，还要收我千分之三的手续费，我想自己搞一个，能收银，看销售情况就行。

然后我就用现在这个系统，迭代出了收银台，门店管理，库存管理等，为了方便收银库存操作，增加了 APP，想的就是他多个摊位放 PC 电脑收银不太合适，这个 app 也可以用在手机上，也可以用在 pda。pda 就是扫码识别特别快。

为了让商户能够直观的看到销售情况，做了销售统计，商户可以看一年内销售情况，毛利润多少等等，但是这时的统计是不支持时间筛选的。

然后找小叔要了一个 pda，接下来的几个月，每天晚上 2-3 小时的开发时间，周末要回老家看看老婆孩子，所以周末几乎没有时间敲代码。有了娃之后，几乎业余时间没怎么敲过代码了。

出售商品需要小票打印，然后就购买了一个 58mm 的 USB 小票打印机。采用的是 electron 的无感打印。后面会发现，购买这么一个固定+USB 式小票打印机是多么后悔的决定。

为了快速录入商品，购买了扫码枪。

就这样，一个基础的简易版管理系统+收银台就这么出来了，这个时候的收银台还很丑，虽然借鉴了一些网上图片，但是还是很丑。

做好了，嗯，几个月，小叔说的时候在买雪糕，多个点位卖，做完后已经过年了，哈哈哈哈哈哈哈哈哈哈哈哈哈哈。

这个时候就是一个比较完整的 web 管理系统+收银台+app 运营了。

然后就把它打入了冷宫，时不时想起了再琢磨两下。

再来需求

就这样又过了几个月。

期间老婆想下班卖卖辣条，入手了百来包辣条，还搞了推车，下班想着出门卖个一两小时，几天下来没啥客流，最后因为这写了几篇公众号文章，成千上万的访问量，最多的上了 10 万，吓得我赶紧删掉了我历史的生活旅游文章，彻底变成了老婆的营销号。

琢磨了多个念头，最后老婆把精力又投入到她一直想要做的新中式服装上。

接下来就是购买新中式，试穿，户外拍照，没有相机用手机，用了 5 年不坏的华为手机拍出来的效果确实欠缺很多，主要就是靠老婆后期修一修，然后发公众号。

这个时候隐隐觉得我又要有任务来了，还不小，也不少。

老婆说有人问她有没有小程序可以选款，然后对我说：老公你给我做一个吧。

老婆开口了。

然后我开始琢磨小程序商城：

脑图梳理，琢磨功能，各种交互场景，如何保证资金安全等等，

界面 UI 参考，在花瓣网采集相关的 UI，也在其他小程序上找灵感，

在 iconfont 上建立图标库，跨端通用，这个在最初 web 阶段已经有了部分

周末还得跟着老婆给她拍照，公园，商城，野外小溪沟等等，她说要把我摄影技术练出来。后来还入手了几千块的索尼相机，拍出来后对比之前手机拍的，确实美了很多。衣服的质感啥的都很清晰，比起手机好太多了。

为了赶时间，回到家吃完饭就立马进入第二份工作中，周末也抽时间做，娃也不能冷落了还得陪，老婆拍照还得跟。。。

好在十年的前端，做起来还是很快的，毕竟习惯于组件化开发，之前也积攒了自己的组件库、工具库，用起来也快，还有 AI 的辅助。很多可能会出现的坑能够提前的避开，比如小数点相加问题，底部适配等。

因为小程序端部分功能不需要权限，所以就采用了 unicloud-db 组件 + 云函数模式开发，效率更进一步。

小程序也是引入了门店系统，对应的门店库存等，用户在下单的时候也可以选择门店下单，相关的订单会进入对应门店的网销订单中心。

做小程序首页的时候，我想到可能会有不同的首页布局需求，然后我加入了首页布局配置功能，能够随时的修改布局，达到多种界面效果。

因为门店线下出售要打印小票，第一次购买没有选好，上一个阶段购买的。现在发现还需要标签打印，为了省钱，在 58mm 小票打印机上，测试 50mm 标签打印，标签纸是那种带背胶的，可以撕下来贴，都是热敏打印纸。50mm 的标签纸在 58mm 的打印机上运行，总是跑着跑着就歪了，测试起来相当麻烦，不断的纠正偏移。

为什么是 50mm 标签，因为老婆定制的标签宽度是 50mm，她事先也不知道需要打印标签，也不知道我之前的打印机是 58mm。

“应该选一个可变宽度的热敏打印机”，后面还会改变这个想法。

小程序有了，功能测试完毕，基础的下单付款订单系统，能够上线运行了。

提审，秒过，

发布，要认证，等着，一周左右，认证完毕，

发布，要备案，等着，一周左右，打回，说什么身份证不是原件拍摄或者扫描件啥的

哦豁，老婆的身份证丢失了 N 久，没有办理，

办身份证，拖了一周，办了，7-15 天等待期，

过了 17 天还没来，老婆打电话问，对方告知：你办证的时候没有填收件地址。根本没寄出来，又让等着，还需回家翻之前办证的条子，扫码填写地址…

期间把统计重构，可以选择时间段进行查询销售情况，但是建议不要太长，会超时。能看到每个门店的销售情况，哪个商品卖的最好，哪个商品利润率最高，哪个商品的那种款式卖的最火，本年度月销售折线等等，app 和 web 端都能查看。

又来需求

等待期间对系统优化着。

一天小叔又来电话了：

“你那个系统可以用了不，我现在搞了个门店想用你那个系统”

“可以啊，还是卖雪糕吗？”

“不是，卖烧烤了”

我…

“那你是不是还得要个点餐小程序哦”

“有的话更好”

我…

前期，把老婆小程序商城部分功能搬过来，删减，修改，做成一个可选门店的点餐小程序，支持选择堂食和外带，本地缓存购物车，下单，支付，基本的订单列表与详情。

对每一个商品都支持备注。

对整个订单支持备注

库存，之前下单时是前端根据下单前列表读取返回的库存校验，没有做最终的提交库存校验，这种情况下可能会出现库存溢出情况（有想到这个 bug 但是前面懒得去动）。最后还是对几个端的下单云函数处理了下，点击下单时云函数再次校验库存，因为是小商户个人系统程序，没有考虑高并发啥的，一下子也不会有成千上万的下单量。

这个时候对小票打印机又有想法了，58mm 有点窄啊，然后又下单了一个 80mm 的打印机，哎，80mm 打印机主要就服务点餐小票，这样就字大好看。

后来点餐小程序增加外卖，web 端需要增加配置，是否开通啊，是否限制距离啊，距离这个我得说一下，因为我小程序是没有获取用户位置权限的，所以在做这个的时候，犯了一下愁：

要不让商户自己看地址决定要不要配送？

万一忘记看直接做了呢？

我想想商户肯定是会抱怨这个问题的。

那还是做一下配送范围限制吧，web 端加上配置，小程序端怎么处理呢？获取用户位置信息也不一定是配送地址。把商城的用户地址系统拿过来，然后在下单付款页加个接口，云函数来计算，~~告白疼~~的个人key的调用多了会被电话骚扰，为了避免可能得限制，此处我选择的是天地图服务端接口，因为免费：云函数通过天地图地理编码接口拿到两个地址经纬度（门店和收货地址），然后本地计算距离（找 deepseek 要的），这样就粗略的有了一个范围计算了，超出范围是不给支付下单的。做这个的时候想的就是楼下那个烧烤店，味道不错，没有美团外卖也没有自己的外卖/点餐小程序，每次都要微信沟通，来回看图片下单，然后他是周末不配送，工作日才会配送，我当时还考虑要不要做个时间段的配置，嗷算了吧，自己周末关闭外卖配置吧。

而且一般这种配送也就限制在商家周边几个小区，用户还可以在家下单，然后散个步倒门店就餐或者带走。

然后又增加 app 端功能：配送订单列表。配送员可以在配送完毕时在 app 上点击【配送完成】按钮，还可以提前拨打用户电话确认位置。

这个外卖功能最终解释权就归商家了，没有第三方平台限制和抽佣。一般用户和商户都算是邻居，好说事。

持续优化

为了美化我的收银台界面，我是网上翻看许多相关的图片，有时候去线下购买商品，我也找店员看看收银界面，对比下各种收银台 UI，最终 UI 成型如下：

在这里插入图片描述

因为采用的是 uniapp 云开发，购买的套餐的 CDN 流量有限，比如我开发用的基础版 5 元/月，只有 2G/月的流量，开发起来还可以，只要不涉及大图啥的目前还不回有啥问题，出过问题的就是做老婆微信商城的时候，老婆上传了很多高清图，一下子就不够用了。为了省流，对一些不必要的接口进行整合，比如点餐小程序，最开始我选择的是点击同一个商品我都要查询一下库存，后来改成点一下查一下，然后保存查的那一下库存，可以继续点，再后来我直接在获取列表的时候查询了列表商品的库存一并返回，用户多次点击加购就不会再请求了，只会在最终提交的时候云函数再校验一下，如有不足的，会提示用户具体商品和库存值，并刷新列表，因为这个才不得已去修改下单云函数校验。还有就是要求上传的图片必须要进行压缩等等。

在涉及金额的地方，主要有下单和退款，不应该信任前端传值大家都知道，我也不会用前端传值，主打的就是云函数查数据，云函数计算，云函数校验等等，保证资金的安全，有一点对不上，我就不给你过。

状态修改，也不能完全信任前端，每一个状态的修改，我都必须限制他的上一个状态值，当然也是云函数查数据库，对不上，状态也不能修改。从待支付修改到已支付，我还会查你的微信交易记录是否存在，金额是否对得上等等。

系统开发完毕后，基本 OK 了，就开始做 UI 和交互优化，比如加上语音播报：“请 001 号顾客取餐”。为了美化登录界面，也是翻了很多图片，找了一些元素，然后找豆包根据元素给我生成了一张登录背景图。

搞着搞着，哎要不整个 pad 端吧，试试看 web 端直接运行 pad，结果失败，排查后发现，web 端有太多的 dom 操作，比如那个富文本编辑器，这个是完全不能忽视的工具。最后就把收银台那一块的提取出来，做成了 pad 端，为什么不把 app 适配下 pad，应为界面不同，pad 界面与 web 界面相同，与 app 相差甚远。

再者就是把开发时的一些枚举数据整合成字典存入数据库，以后有啥修改的就不需要各端改配置文件了。