去年夏天我第一次去朋友的理发店帮忙看店，就撞上了最尴尬的一幕：一个老顾客进门问“我卡里还剩多少钱”，收银的小姑娘翻开一本硬壳笔记本，翻了三页报出一个数字，顾客摇头说不对，她又翻到前面重新加了一遍，报出另一个数字。两个人愣在那里，谁也不确定谁对。那台摆在收银台上的电脑当时只在干一件事：连蓝牙音箱放歌。也就是从那天起，“给店里做一套理发店会员管理系统”这件事正式排进了我的日程。项目编号被我记成了 m089，一个再普通不过的课程设计编号，但实际动手之后我发现，把一个小店的会员账管清楚，需要考虑的东西远比想象中多。
这篇文章我不打算只贴数据库表和接口代码，我会把从需求梳理、架构选型、数据库建模、业务闭环实现到上线后调整的完整链路都讲一遍，重点放在那些让系统真正能用、好用的设计决策上。如果你也在做一个类似的信息管理系统项目，或者想给自己的小生意搭一套会员工具，这篇文章应该能帮你少走不少弯路。
1. 立项背景：收银台的混乱让我决定写一套会员系统
1.1 那本笔记本暴露出来的记账问题
传统的理发店会员管理，大多数时候就是账本加姓名电话本。办卡时手写一行“张姐，1000元，送100”，下次消费再手写一行“剪发扣45，余额655”。表面上看记录逻辑没问题，但实际运营中漏洞特别多。
第一个问题是账本只有一份。收银员换班的时候要交接，忙起来容易漏记，一旦某页被水渍泡花了，那几行余额就成了无头悬案。第二个问题是查询困难。顾客问余额，你得先知道他是哪一页的会员，然后从头到尾逐行加一遍。第三个问题更隐蔽：老板根本看不到经营全貌。今天卖出去多少充值、哪个发型师贡献了多少流水、哪个项目卖得最好，这些信息全都埋在一堆手写数字里，月底算账基本靠翻本子加计算器。
这些问题听起来很小，但对一家小店来说，账目不清就意味着信任危机。顾客觉得自己卡里还有钱，店里觉得已经扣完了，矛盾只要发生一次，就可能丢一个回头客。
1.2 老板的三个核心诉求与需求清单
我把朋友的需求聊了两轮，最后收敛成三句话：第一，顾客报手机号就能查到余额；第二，充值、扣费、赠送的账一分都不能错；第三，月底要能看清每个发型师做了多少业绩、每个项目卖了多少。这三句话听着朴素，但每一条都直接决定了系统的核心设计方向。
从这三句话出发，我梳理出了 m089 的功能清单：
- 会员档案管理：姓名、手机号、性别、会员等级、开卡日期、备注
- 充值管理：支持不同充值档位、赠送规则、支付方式
- 消费管理：按服务项目扣费、支持现金或扫码收款
- 积分管理：消费累计积分，积分可抵扣、兑换
- 预约管理：顾客选择时间段、发型师、服务项目
- 员工管理：发型师基础信息、提成比例
- 统计报表：充值金额、消费金额、员工业绩、会员复购情况
这个清单看起来功能不多，但每一块再往下拆都能拆出一堆细节。比如“赠送规则”就分固定赠送和按比例赠送，充值档位不同、赠送力度也不同，这些规则必须在系统里做成可配置，而不是写死在代码里。
1.3 为什么没有直接用现成的商业软件
朋友店里最开始用的方案是买一套现成的收银会员系统，但试用之后放弃了。原因是现成软件面向的是通用商户，功能堆得很多，买单、库存、员工排班、营销活动一应俱全。对一个小理发店来说，这些功能绝大多数用不上，反而让操作变得繁琐。
更重要的是数据归属问题。商业软件的数据存在服务商的服务器里，如果以后不想续费了，数据要导出来非常费劲，有些甚至只给csv但字段对不上。自己做系统虽然前期开发成本高一些，但数据完全在自己手里，功能也可以照着店里的真实流程来调整，想加一个“老顾客按上次发型师预约”的规则随时都能加。
这其实也是很多中小商户做信息化时要面对的一个选择：买现成的还是自己做？我的观点是，如果你的流程跟通用软件高度一致，直接买没毛病；如果流程里有比较个性化的部分，或者对数据敏感，自己开发一套轻量系统反而更省心。m089 的定位就是这种轻量、私有化、按真实流程定制的一套系统。
2. 整体架构设计：B/S模式带来的部署和管理便利
2.1 架构选型对比与最终选择
理发店场景下，客户端数量不多，但有三四个收银点很正常，店长办公室也经常要看数据。如果做成传统的桌面单机软件，每台电脑都要装客户端，数据库还得单独部署，更新一次版本就要跑一遍所有机器，维护成本很高。
对比下来，B/S模式是最合适的选择。浏览器就是客户端，服务器统一部署在后端，店里所有电脑连同一个局域网就能访问。这样有几个好处：第一，无需在每台收银机上安装软件；第二，功能更新只改服务器端代码，刷新浏览器即可生效；第三，手机和平板也能打开管理页面，老板在外面也能瞄一眼经营情况。
从部署角度看，B/S模式还可以把服务器放在内网，不上公网。小规模使用情况下，内网服务器加一台备用机做数据库定时备份，稳定性和安全性都够用，还省去了公网服务器和域名的年费。
2.2 前后端的技术栈组合
技术选型上，我遵循的原则是“成熟优先、团队熟悉度优先”。当时能稳定上手的组合是：后端用 Java 生态里的轻量级 Web 框架，ORM 组件负责数据库操作，前端用主流 MVVM 框架配合现成的 UI 组件库。数据库选用开源的关系型数据库，表结构清晰，中文支持好，备份工具也齐全。
这里有一个容易被新手忽略的点：课程设计和实际项目对技术栈的要求是完全不同的。课程设计看重框架的完整度和文档齐全度，但实际落地还要额外要考虑两点，一是部署环境对机器性能的要求不能太高，二是出问题时社区资料要够多。所以我在选型时特意避开了那些看起来很“新”但还不稳定的框架组合，目的就是不让技术本身成为项目的干扰因素。
2.3 模块划分上我做的几个决策
模块划分我按照业务职责拆成了四层：控制层负责接收请求和参数校验，服务层承载所有业务规则，数据访问层负责操作数据库，前端单独做成一个页面应用。服务层的核心地位从第一天写代码起就很明确。
我坚持把业务逻辑全部放在服务层而不是控制层里，原因很简单：控制层如果塞了业务逻辑，后期加接口的时候就会越写越乱。比如“消费一笔并累计积分”这个动作，控制层只接收会员编号、服务项目编号，服务层负责校验状态、计算金额、扣减余额、记录流水、增加积分。这套逻辑只需要写一次，以后不管是收银台接口调用，还是手机端查询接口调用，走的是同一个入口，行为完全一致。
前端部分，我按功能拆成界面组件和 API 请求模块，界面组件只关心渲染和交互，所有接口请求统一封装。这样做的原因是收银台的操作频率很高，界面卡顿会直接影响顾客体验，把请求逻辑集中管理之后，后续做缓存、做错误重试都有统一的改造点。
3. 数据库设计：如何让钱、积分、会员关系都对得上
3.1 核心表结构与设计逻辑
数据库是整个系统最不能糊弄的部分，因为钱和积分一旦对不上，再好看的前端界面都是白搭。我把表设计成了这么几张核心表：会员账户表、充值流水表、消费流水表、积分流水表、服务项目表、员工表、预约表。
会员账户表保存会员的静态信息和动态余额，这是系统的“主账户”。充值流水表负责每一笔充值记录，包括充值金额、赠送金额、支付方式、操作人。消费流水表负责每一笔消费记录，包括消费项目、金额、消耗积分、获得积分。积分流水表单独存在的意义在于：积分的累计和抵扣不是同一条记录，分开之后每一分积分都可以追溯到来源。
区分“账户表”和“流水表”是这次设计里我觉得最重要的一点。账户表只体现当前状态，流水表记录所有历史动作。比如顾客充了三次值，账户表里只有一个最终余额，但充值流水表里有三行明细。这样做的好处是，任何一笔余额变化都能回溯到对应的流水记录，老板对账的时候不再是“余额对不上”，而是可以打印出每一笔流水让顾客确认。
3.2 金额字段为什么必须用定点数
我在这里踩过一个非常经典的坑，最开始设计表结构时为了省事，金额字段用了浮点数类型。测试阶段感觉没问题，但跑到退费和充值赠送这种需要多次加减的场景时，开始出现 0.01 元的偏差。比如充值 1000 元按 0.1 比例赠送，显示 1100.00，但内部计算结果可能是 1100.000000001。
这个问题的根源在于浮点数在计算机底层的表示方式。货币计算对精度极其敏感，差一分钱都会让顾客和老板失去信任。所以我最终把所有跟金额相关的字段全部改成了定点数类型，统一精确到小数点后两位。这是一个数据库设计的经典铁律：钱永远不要用浮点数存。
同样的原则也适用于积分字段，只不过积分通常是整数，所以直接用整数类型即可。如果未来要做积分抵扣部分金额，抵扣金额同样必须走定点数字段，不能出现浮点计算。
3.3 流水表与账户表之间的同步策略
账户表和流水表之间存在一个很强的约束关系。我选择在同一个数据库事务中完成这两种表的写入，这样能保证任何情况下二者都不会各说各话。
举一个具体场景：顾客充值 500 元，赠送 50 元。在数据库事务内，程序先更新会员账户表的余额，加上 550 元，再往充值流水表插入一条 500 加 50 的记录。如果第二步失败，第一步也会回滚，账户余额仍然保持不变。这种“要么都成功、要么都不成功”的机制，就是数据库事务的核心价值。
这里要提醒一下：不要把多条流水一次性攒到程序内存里，最后再批量写库。内存中攒流水可以在极端情况下丢失数据，而数据库事务天然保证持久性。所以每一笔业务操作都必须在一个事务边界内完成写入，中间不能有任何跳出事务的动作，比如调用外部接口或者发送短信之类，否则很容易造成状态不一致。
4. 充值、消费、积分三大业务闭环的实现
4.1 充值赠送规则的计算
充值模块是门店现金流最直接影响因素，所以赠品规则的处理必须既灵活又不出错。我把赠送规则抽象成一个配置表，规则字段包括充值档位下限、赠送方式（固定金额或者按比例）、赠送值。这样老板想搞“充 500 送 50”或者活动期间改成“充 500 送 80”，只需要改数据库配置，不用动代码。
赠送规则的计算放在服务层，用独立的优惠策略实现。策略模式在这里比较合适，因为规则可能组合：满额赠送加节假日双倍赠送，或者老会员额外赠送百分之多少。每种规则都对应一个独立的条件判断类，新增规则不需要修改已有逻辑，只要新增一个实现类并注册进去。
除了赠送金额，“到账金额”和“实付金额”需要区分清楚。顾客实际付款 500 元，到账 550 元，这两者分别记录在充值流水的实付字段和到账字段中。这样做的好处是月底核算时，老板既能看到现金流入，也能看到负债式的“赠送成本”。
4.2 消费扣款时的余额校验
消费扣款是整个系统操作频率最高的动作，收银台结账时最快要在几秒内完成。这个过程的关键点在于：扣款前必须校验会员状态和余额，扣款时必须在一个原子操作里完成。
校验逻辑分三步。第一步检查会员状态是否为正常状态，如果挂失或冻结，直接拦截。第二步检查余额是否足够支付本次消费金额。第三步检查如果本次消费使用了积分抵扣，抵扣规则是否允许叠加。全部通过后才进入余额扣减和积分累计阶段。
为了提升并发环境下的安全性，扣款 SQL 不应该写成“先查余额，再更新余额”的两段式。更稳妥的方式是把余额扣减与条件判断合在一条更新语句里。例如“更新会员账户表，将余额减去消费金额，要求当前余额大于等于消费金额”。如果更新的影响行数为零，说明余额不足，事务回滚。这种方式避免了并发请求同时读取到相同余额，然后各自扣款导致超扣的问题。
4.3 并发场景下防止扣成负余额的处理
理发店的收银并发度其实不高，高峰期也就是同时两三个收银台，但这种并发风险依然存在。尤其是顾客用手机扫码付款时，如果前端连续提交两次，或者重试机制触发两次，就可能出现同一笔消费扣两次款。
我除了在更新语句中加上余额条件之外，还引入了数据库唯一健来防止重复扣款。每一笔消费生成一个业务单号，单号在消费流水表中是唯一值。即使前端重复提交，第二次插入会因为唯一健冲突而失败，服务层捕获异常后直接返回“订单已存在”，不会影响账户余额。
积分模块也采用了类似思路。积分的变化全部写积分流水表，每条流水包括会员编号、变动类型、变动数量、关联业务单号。因为关联单号唯一，所以不会出现同一笔消费触发两次积分累计的情况。积分结余则通过汇总流水计算，定期与账户表的总积分字段做核对。
5. 预约、员工提成和数据报表的落地
5.1 预约冲突检测
预约功能看起来简单，但冲突检测是隐藏难点。顾客预约时间通常是“某天某时段”，而店内同时有多个发型师，每个发型师同一时间段只能服务一个顾客。所以判断冲突不能只检查某一天有没有预约，还要精确到“发型师 + 时间段”维度。
我在预约表中记录了发型师编号、服务开始时间、服务结束时间，以及预约状态。新增预约时，查询该发型师在重叠时间段内是否存在状态为“已确认”的预约。只要存在重叠，就提示该时间已被占用，需要另选时段或者选另一位发型师。
当时还遇到一个业务场景：顾客并没有明确指定发型师，只是预约“今天下午两点的剪发”。针对这种情况，系统把该预约挂在门店公共队列下，由前台根据到达顺序分配发型师。这种设计避免了空跑率，也让不完全指定的预约不会因为绑定单一发型师而制造表面冲突。
5.2 员工提成计算的两种方案
员工提成计算直接关系钱，所以必须跟消费流水绑定，不能事后手工填。我考虑了两种方案：一种是在消费流水表上直接加“提成金额”字段，下单时就按发型师的提成比例计算；另一种是通过服务项目设定提成比例，在生成月度报表时再统计。
最终我选择了“消费时记录提成比例和金额”的方案。虽然这样多占了一个字段，但它带来的好处是：每一笔消费一旦完成，提成就固定下来了，不会因为后续调整提成比例而影响历史报表。老板如果给某位发型师临时涨提成，只影响后续消费，不影响之前已经做好的账。
提成明细还单独做了一张员工业绩表，按日汇总每个员工的消费笔数和提成金额，便于日结和月结。这里用“预汇总”的方式并不是多余的，因为月底如果直接对流水表做聚合，数据量大时查询会比较慢，而且把聚合结果保存下来还能起到审计留痕的作用。
5.3 给老板看的经营报表
报表模块是老板真正每天都会看的部分，我优先做了三张表：每日营业汇总、会员充值排行、项目销售排行。每日营业汇总展示当日现金收入、充值收入、消费收入、赠送金额、退款金额，并显示环比变化。会员充值排行按充值金额排序，让老板一眼看到哪些是核心大客户。
项目销售排行则按服务项目统计销售额和单量。这个数据对运营非常有用，比如发现烫发项目占收入的比例异常高，老板就可以考虑在采购相关耗材时增加预算。连续三个月的项目销售额趋势，还能辅助判断季节因素对生意的影响。
这部分的实现没什么高深技术，核心是把 SQL 聚合查询的索引设计好。我给充值流水和消费流水表的时间字段都建了索引，报表接口查询前还加了时间段参数约束，避免一次性统计全量数据。初期这些报表是页面刷新时实时计算的，数据量达到一定程度后，再改成每日凌晨跑批汇总。
6. 开发过程踩过的坑与对应修复
6.1 浮点精度问题：钱少算了一分钱
这个问题在第 3 节简单提过，这里详细讲一下踩坑过程。第一次测试充值赠送功能时，我充了 2000 元、赠送 300 元，显示余额是 2300.00，看起来没问题。后来测试多笔组合消费时发现，有位顾客消费 28.5 元、再消费 12.3 元之后，系统显示的余额比手工计算少了 0.01 元。
排查时我先怀疑是小数显示问题，但验证后发现不是显示问题，就是内部存储的数值变了。问题根源就是浮点数在二进制下无法精确表示部分十进制小数，加减次数越多误差越明显。修复方案很简单：金额字段全部改成定点数，服务层所有运算用高精度计算类型替代基本浮点类型。改完后重新跑了全量测试，精度问题再也没出现过。
这条经验让我之后做任何涉及金额的功能都有了条件反射：先看字段类型是不是定点数，再看运算过程用的什么类型，不满足要求直接不改代码也要先改数据结构。
6.2 重复点击导致重复扣款
收银操作有一个特殊场景：网络稍慢时，收银员看到页面没跳转，习惯性再点一次结账按钮，结果一笔消费被提交两次。这个场景在我自己的测试中复现过，当时后端接口没有做幂等处理，余额直接被扣了两笔。
修复思路有两个层面。前端层面，点击结账按钮后立即置灰并显示“处理中”，防止连点。后端层面，通过业务单号的数据库唯一约束兜底，即使请求被重复提交，第二次写的流水必然冲突，整个二次操作回滚。这种“前端防连点 + 后端幂等兜底”的双层方案，是收银系统这种操作频繁场景下的标配思路。
6.3 手机号重复注册与老会员数据迁移
理发店会员数据经常存在同一个人有两张卡的情况。多体现在：顾客用手机号 A 办了一张卡，后来又用手机号 B 办了一张卡，或者同一个手机号因为店员误操作录了两次。为了处理这个问题，我在会员表上给手机号加了唯一索引，同时提供一个“合并会员卡”的管理功能，把同一顾客的多张卡合并到一张主卡上，余额和积分全部转入。
老会员数据迁移也是被低估的工作。开业三年以上的店，纸质会员名单可能有几百条记录，其中手机号格式不统一，有的缺了一位，有的填了座机号。我设计了一个支持导入模板的 Excel 数据导入功能，导入前先做手机号格式清洗，不符合格式的自动标红，由前台逐条确认后再入库。这个做法在上线时帮了大忙，原本以为要录入一整天的数据，最后两个多小时就导入完成。
6.4 操作日志与账目可追溯性
系统上线两天后，朋友打电话过来说“有笔充值好像不见了”。我查了会员余额，又查了充值流水，发现确实有一笔 200 元的充值记录，但是收银员在操作时选错了会员，把钱充到了另一个同姓名的会员账上。账没有丢，但很难第一时间定位。
经过这件事，我给所有写操作增加了日志模块，记录操作人、操作时间、操作内容、修改前后数据。现在再出现账目疑问，管理员可以在日志管理页面按时间、操作人、操作类型筛选，很快就能定位是谁、什么时候、改了什么。这些日志同时也是审计的底稿，顾客有异议时可以现场调出流水记录。
操作日志对系统的长期运维非常重要，但它常常被忽略。我的建议是，从项目第一天起就为所有写接口接入日志体系，不要等项目运行一段时间后再补，因为补日志意味着这段时间的操作历史全部丢失，是补不回来的。
7. 项目交付之后的使用反馈与扩展思路
7.1 实际上线后的调整
系统在朋友店里跑了一个多星期后，我发现使用频率最高的功能并不是那些复杂的报表，而是最基础的“手机号查余额”和“消费扣款”。于是我把收银首页改成了一个极简结账界面，输入手机号回车即出会员信息，再点服务项目直接扣款。原来的详情页面和数据分析功能则全部折叠到二级菜单里，让收银员每天的工作路径变得非常短。
这个调整让我意识到，功能管理系统的价值不在于功能多，而在于高频操作足够顺手。收银员一天要完成上百笔操作，每笔操作多一步确认，累积下来就是很大的时间损耗。所以后来我做任何小功能都会先问一句：这个功能用在哪个环节？是谁在用？他一天会用多少次？然后根据频率来设计操作路径。
另外还收到一个很实用的建议：顾客充值后要在小票上显示当前余额和累计积分。虽然系统里随时可以查余额，但顾客更习惯看到一张回单上的明确数字。这个需求后来加到了打印模板里，给店铺减少了不少解释成本。
7.2 后续可以继续扩展的方向
m089 目前覆盖了会员、充值、消费、预约、员工、报表六块核心业务，但还有一些可以继续延伸的方向。比如给顾客加在线预约能力，顾客通过手机端或小程序选择发型师和时间，减少前台电话沟通成本。比如接入互联网支付能力，让顾客直接扫码付款，款项自动对账，省去收银员手工录入付款方式的环节。又比如做更细粒度的营销分析，识别超过一个月未到店的沉睡会员，自动生成优惠提醒消息。
数据二次利用也是值得投入的方向。积累半年以上的消费数据后，可以按照时间段、项目、客单价做多维分析，帮助老板判断黄金营业时段、热门项目组合，以及哪些会员的消费频次正在下降。这些在初期看似“锦上添花”的功能，一旦数据量上来，往往会变成店铺经营判断的核心依据。
从项目本身来说，m089 不是什么了不起的作品，但它把一个容易被低估的行业需求踏踏实实落了地。写代码的时候我反复提醒自己：系统最终是要给收银员和老板用的，他们不在意你用了多新的技术，只在意顾客问余额时能不能一秒答出来，月底算账时能不能一分不差。把这件事想透了，很多设计上的取舍就变得简单了。
