简介这份美容院会员管理系统源码包面向中小型美容门店的数字化管理需求也适合PHP开发者学习会员系统与微信端的业务实现。系统围绕会员档案维护、门店日常业务和权限管理展开权限可细分到每个功能点增删改查模块较为齐全并整合Excel导出便于搭建内部管理后台或进行二次开发。压缩包共1601个文件、约23.4MB以662个PHP程序文件和272个HTML模板为主体辅以JavaScript、CSS、图片及字体等前端资源并包含配置、公共函数库、SQL脚本等支撑文件整体目录组织较完整便于按模块查找和替换。已有3259人学习读者可从中了解微信端与管理端的协作方式、细粒度权限控制、数据增删改查以及报表导出的实现思路。对于需要快速搭建门店会员管理后台、研究管理端与微信端数据交互的开发者这套源码具有直接的参考和复用意义。1. 美容院会员管理系统前台那本手写卡册其实三天就能搬进微信端接手一个三家门店的美容院项目时前台桌上还摆着一本手写卡册谁办了补水疗程、剩几次、卡里还有多少余额全靠一支笔换个店员就得翻半天。老板想上系统又不想被按年收费的 SaaS 绑住最后选了一套美容院会员管理系统源码自己部署微信端让顾客自己查卡、约时间、看余额。这套代码的定位很清楚把会员档案、卡项、疗程扣次、员工提成、店铺流水这几件事管住后台给店长和前台用微信端给顾客用。它适合手里有台服务器、愿意自己维护的小连锁和单店不适合指望装上就自动拉客的人——会员是要靠门店服务一点点攒的。2. 技术栈与目录结构一套源码怎么同时喂饱后台、门店端和微信端这类系统的并发量其实很低一家店一天几十单三家店加起来上百单用不着微服务那一套。但它对“钱”和“次”的准确度要求很高扣一次疗程、扣一笔余额、算一笔提成三件事要么全成要么全不成。所以这套源码走的是单体 分模块的路子事务边界清楚部署也就一个 jar 加一个前端目录。2.1 技术选型为什么这类项目总是 Spring Boot MyBatis-Plus Vue我见过的美容院会员管理系统源码绝大多数是 Java 路线Spring Boot 起服务MyBatis-Plus 做数据访问MySQL 存业务数据Redis 放登录令牌和门店排班缓存后台前端 Vue Element UI微信端 uni-app 一套代码同时编译小程序和 H5。这个组合不新但它有一个很实际的好处——交付形态简单打成 jar 扔到服务器上就能跑客户环境里不用额外装运行时出问题也好远程看日志。层次常见选型这套业务里为什么这么选服务端Spring Boot MyBatis-Plus扣次扣款能塞进一个方法里事务边界一目了然数据库MySQL会员、卡项、流水都是强关系数据约束能兜底缓存Redis登录态、门店排班、卡项字典读多写少后台前端Vue Element UI表格表单多组件现成加字段改得快微信端uni-app一套代码出小程序和 H5顾客不用装 App定时任务Spring Task 或 XXL-JOB凌晨算提成、发卡项到期提醒、清过期券前后端分离是标配但不是前后端各写各的。后台接口前缀一般是/admin微信端接口走/api两套接口分别做鉴权后台走账号密码 门店权限微信端走 openid 换来的令牌。这个分离要在目录上就体现出来别等到后期才拆。2.2 目录结构按业务域分包别按技术分层平铺很多源码包一打开是这样的controller一个包service一个包mapper一个包。小项目看着整齐一旦要改“卡项到期提醒”这种横跨多层的功能你会在三个包里来回跳。我更推荐按业务域分包这套源码大体也是这个思路beauty-member/ ├── beauty-admin/ 后台管理端接口给店长和前台用 ├── beauty-wechat/ 微信端接口给小程序和 H5 用 ├── beauty-common/ 公共模块统一返回、异常、工具类、常量 ├── beauty-system/ 业务主模块会员、卡项、疗程、订单、提成 └── sql/ ├── beauty_schema.sql 建表脚本 └── beauty_init_data.sql 初始化数据门店、角色、卡项模板beauty-admin和beauty-wechat拆成两个可独立启动的模块不是过度设计。微信端接口要做签名校验、频率限制、返回体精简后台要接门店数据权限混在一起后期很难剥。beauty-common里放Result、BizException、雪花 ID、日期工具所有模块都依赖它它不依赖任何业务模块这个方向不能反。业务主模块内部再按域分beauty-system/src/main/java/com/example/beauty/ ├── member/ 会员档案、标签、等级 ├── card/ 卡项模板、会员持卡、余额 ├── treatment/ 疗程、扣次记录 ├── order/ 收银台、充值、退款 ├── commission/ 员工提成规则与结算 ├── store/ 门店、员工、排班 └── wechat/ 微信登录、预约、卡项展示按域分包之后改一个功能基本只在一个包里动手也不容易在member包里随手引用order的类造成循环依赖。实体命名统一用业务词Member、MemberCard、TreatmentRecord、CommissionRule别出现TbUser1这种导入工具自动生成的表名映射。2.3 数据模型会员、持卡、流水三张表撑起全部业务看这类系统值不值得接手我第一件事是看流水表怎么设计。会员可以改卡项可以下架流水一旦能被覆盖对账就是一笔糊涂账。核心三张表我一般这么定-- 会员主表一个手机号一个会员跨门店共享 CREATE TABLE member ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 会员ID, store_id BIGINT NOT NULL COMMENT 首次建档门店, mobile VARCHAR(20) NOT NULL COMMENT 手机号全局唯一, name VARCHAR(50) NOT NULL COMMENT 姓名/昵称, level_id BIGINT DEFAULT NULL COMMENT 会员等级, balance DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 储值余额单位元, points INT NOT NULL DEFAULT 0 COMMENT 积分, last_visit_at DATETIME DEFAULT NULL COMMENT 最后到店时间, deleted TINYINT NOT NULL DEFAULT 0 COMMENT 逻辑删除, PRIMARY KEY (id), UNIQUE KEY uk_mobile (mobile) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会员档案; -- 会员持卡一张卡对应一个会员 一个卡项模板 CREATE TABLE member_card ( id BIGINT NOT NULL AUTO_INCREMENT, member_id BIGINT NOT NULL COMMENT 会员ID, store_id BIGINT NOT NULL COMMENT 售卡门店, card_tpl_id BIGINT NOT NULL COMMENT 卡项模板ID, remain_count INT NOT NULL DEFAULT 0 COMMENT 剩余次数储值卡为0, remain_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 剩余金额, expire_at DATE DEFAULT NULL COMMENT 到期日NULL 表示长期, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2用完 3过期 4退卡, PRIMARY KEY (id), KEY idx_member (member_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会员持卡; -- 扣次流水只增不改对账全靠它 CREATE TABLE treatment_record ( id BIGINT NOT NULL AUTO_INCREMENT, card_id BIGINT NOT NULL COMMENT 会员持卡ID, member_id BIGINT NOT NULL, store_id BIGINT NOT NULL COMMENT 实际核销门店, staff_id BIGINT NOT NULL COMMENT 服务员工, count INT NOT NULL DEFAULT 1 COMMENT 本次扣减次数退单为负, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 本次扣减金额快照, biz_no VARCHAR(40) NOT NULL COMMENT 幂等号防重复提交, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_biz_no (biz_no), KEY idx_card_time (card_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT扣次/核销流水;三个设计点值得单独说。第一余额和次数分开存。储值卡看remain_amount疗程卡看remain_count不要用一张表加个type字段混着塞后期算提成时基数的取法完全不同。第二流水表带biz_no唯一索引这是防重复扣次的最后一道闸前端置灰只是体验数据库约束才是保障。第三store_id在会员表上是“建档门店”在持卡表和流水表上是“售卡/核销门店”两个含义别混——会员跨店可用卡归属于售出的那家店提成也归那家店这是分成规则的地基。表作用容易出错的地方member会员档案手机号没做唯一同一人建三次档member_card会员持卡状态没维护过期卡还能核销treatment_record扣次流水允许 update对账时查不到原始值commission_rule提成规则比例写死在代码 if-else 里store门店缺少营业时间与结账截止点3. 核心链路拆解一次「到店扣次 算提成」到底走了哪些代码后台菜单再多真正跑在业务主干上的只有三条链路建档、扣次、结算。把这三段读透剩下的会员标签、生日提醒、优惠券都是挂在上面的枝叶。3.1 会员建档先查手机号再决定是新建还是合并前台最常干的事就是“给这位姐建个档”。这段代码看着简单坑不少Transactional(rollbackFor Exception.class) public Long createOrMerge(MemberCreateDTO dto) { // 1. 手机号是全局唯一键先查再插避免收银台重复建档 Member exist memberMapper.selectByMobile(dto.getMobile()); if (exist ! null) { // 2. 老会员只补全空字段不动 level 和 balance if (StringUtils.isBlank(exist.getName())) { exist.setName(dto.getName()); memberMapper.updateById(exist); } return exist.getId(); } // 3. 新会员余额、积分一律从 0 开始不接受前端传值 Member member new Member(); member.setStoreId(dto.getStoreId()); member.setMobile(dto.getMobile()); member.setName(dto.getName()); member.setBalance(BigDecimal.ZERO); member.setPoints(0); memberMapper.insert(member); return member.getId(); }dto里只放门店 ID、手机号、姓名、来源渠道这几个字段余额和等级坚决不放进 DTO——前端能传余额等于把收银台的钱袋子敞开。第 3 步之后如果还要发新人券放在事务外的AFTER_COMMIT事件里做别让发券失败把建档整体回滚。为什么不“先插入、撞唯一键再捕获异常”这是我有过一次血泪经验的地方在同一个事务里捕获DuplicateKeyException之后事务已经被标记成 rollback-only后面哪怕不再抛异常提交时照样炸。要么先查要么把插入放到独立事务里。3.2 疗程卡扣次一个事务里必须做完的四件事扣次是整个系统最不能出错的地方写法上我坚持“条件更新 流水兜底”Transactional(rollbackFor Exception.class) public void consume(TreatmentConsumeDTO dto) { // 1. 幂等biz_no 有唯一索引重复提交直接返回成功 if (recordMapper.existsByBizNo(dto.getBizNo())) { return; } // 2. 带条件扣减把 remain_count ? 放进 where靠数据库保证不超扣 int rows cardMapper.deductCount(dto.getCardId(), dto.getCount()); if (rows 0) { throw new BizException(卡项次数不足或卡已失效); } // 3. 写流水金额按卡项单价做个快照退单写负数冲正 TreatmentRecord record new TreatmentRecord(); record.setCardId(dto.getCardId()); record.setMemberId(dto.getMemberId()); record.setStoreId(dto.getStoreId()); record.setStaffId(dto.getStaffId()); record.setCount(dto.getCount()); record.setAmount(dto.getUnitPrice() .multiply(BigDecimal.valueOf(dto.getCount())) .setScale(2, RoundingMode.HALF_UP)); record.setBizNo(dto.getBizNo()); recordMapper.insert(record); // 4. 更新最后到店时间沉睡会员唤醒名单靠这个字段筛 memberMapper.touchLastVisit(dto.getMemberId()); }配套的更新语句是关键update iddeductCount UPDATE member_card SET remain_count remain_count - #{count} WHERE id #{cardId} AND status 1 AND remain_count gt; #{count} /updaterows 0就代表三种情况之一卡不存在、卡状态不对、次数不够。业务上不需要区分得太细给前台的提示统一成“次数不足或卡已失效”更好用具体原因写进日志。biz_no一般由前端生成 UUID前端重试时带同一个值如果前端没传后端用“门店 ID 时间戳 三位随机数”补一个但绝不能每次请求都重新生成那样幂等就白做了。3.3 提成结算规则落表别写死在一串 if-else 里提成规则是店长最爱改的东西这个月疗程卡提 8%下个月做活动提到 12%写死在代码里的结果就是每次改都要重新发版。做法是把规则落成表按“门店 卡项 岗位”匹配取优先级最高的一条public BigDecimal calcCommission(TreatmentRecord r, MemberCard card) { // 1. 按门店、卡项、员工岗位匹配规则priority 大的优先 CommissionRule rule ruleMapper.match(r.getStoreId(), card.getCardTplId(), r.getStaffId()); if (rule null) { return BigDecimal.ZERO; // 没配规则就是 0不默认给比例 } // 2. 基数疗程卡按单价乘次数储值卡按本次实际消费金额 BigDecimal base rule.getBaseType() 1 ? card.getUnitPrice().multiply(BigDecimal.valueOf(r.getCount())) : r.getAmount(); // 3. 比例存 12.50 这种百分比数值先保留 4 位再收敛到分 return base.multiply(rule.getRate()) .divide(new BigDecimal(100), 4, RoundingMode.HALF_UP) .setScale(2, RoundingMode.HALF_UP); }第 3 步的两级舍入不能省。直接multiply完setScale(2)遇到 0.5 分这种边界值会和财务算出来的差一分钱一个月几百单攒下来就是几十块的窟窿。结算结果写进commission_record明细按流水一行一条汇总按月按员工一条月底导出时两边能对上。真正跑的时候提成计算放在凌晨的定时任务里不在扣次事务里同步做。扣次是顾客在前台等着的必须快提成是老板月底才看的慢一点没关系失败了还能补跑。4. 环境搭建与跑通从导入 SQL 到微信端扫码能看到自己的卡源码拿到手最想知道的其实是“我这台机器上能不能跑起来”。这一章按我实际操作的顺序走一遍。4.1 本地环境与配置项先改这四处环境我一般用 JDK 8、Maven 3.6 以上、MySQL 5.7 以上、Redis 5 以上前端 Node 14 以上微信端装开发者工具。装完先别急着编译把配置文件里这四处改掉server: port: 8080 spring: datasource: # 时区必须显式指定不写的话跨时区服务器上时间会漂 url: jdbc:mysql://127.0.0.1:3306/beauty?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 redis: host: 127.0.0.1 port: 6379 database: 3 # 别和其他项目共用 0 号库清缓存会误伤 beauty: upload-path: /data/beauty/upload/ # 会员头像、卡项封面别放 jar 同级目录 wechat: app-id: wx0000000000000000 # 换成自己的小程序 AppID app-secret: 00000000000000000000000000000000 mch-id: # 不接微信支付可以先留空upload-path单独拎出来是有原因的打成 jar 之后jar 同级目录在重新部署时经常被整个覆盖顾客头像一夜间全变成叉号。database: 3也是经验多个项目共用 0 号库某天随手一个flushdb就把别人的登录态清了。4.2 建库导数据与启动后端库一定要用utf8mb4。会员昵称里带个表情符号utf8三字节存不进去插入直接报错前台会以为系统坏了。# 1. 建库字符集必须是 utf8mb4 mysql -uroot -p -e CREATE DATABASE beauty DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_general_ci; # 2. 先导结构再导初始化数据顺序反了会缺菜单和角色 mysql -uroot -p beauty sql/beauty_schema.sql mysql -uroot -p beauty sql/beauty_init_data.sql # 3. 打包第一次跑先跳过测试别被环境问题卡住 mvn clean package -DskipTests # 4. 启动后台服务profile 指向本地 java -jar beauty-admin/target/beauty-admin.jar --spring.profiles.activedev前端单独起cd beauty-ui npm install --registryhttps://registry.npmmirror.com npm run dev启动后先看控制台有没有打印出接口前缀和端口后台默认账号密码在beauty_init_data.sql的sys_user表里第一次登录完记得改。如果后台页面能打开但接口全 404八成是前端.env.development里的VUE_APP_BASE_API没对上后端端口这个错我见过太多次。4.3 微信端联调AppID、请求域名和一次性的 code微信端的请求封装是第一个要动的地方// utils/request.js const BASE_URL http://127.0.0.1:8081/api; // 微信端接口走 beauty-wechat 模块 export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { content-type: application/json, X-Token: uni.getStorageSync(token) || // 登录后写入的令牌 }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { uni.reLaunch({ url: /pages/login/login }); // 令牌过期直接回登录页 reject(res.data); } else { uni.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: reject }); }); }后端的登录换 openid 这一段写法上有几个不能让步的点public String login(String code) { // 1. code 只能用一次五分钟内有效绝对不能缓存复用 String url https://api.weixin.qq.com/sns/jscode2session ?appid appId secret secret js_code code grant_typeauthorization_code; JSONObject json restTemplate.getForObject(url, JSONObject.class); String openid json.getString(openid); if (StringUtils.isBlank(openid)) { throw new BizException(微信登录失败 json.getString(errmsg)); } // 2. sessionKey 只留在服务端一律不下发给前端 Member member memberMapper.selectByOpenid(openid); if (member null) { member new Member(); // 首次进入先建一个只有 openid 的空档案 member.setOpenid(openid); member.setStoreId(0L); memberMapper.insert(member); } String token UUID.randomUUID().toString().replace(-, ); redis.opsForValue().set(wx:token: token, member.getId(), 7, TimeUnit.DAYS); return token; }首次进入的顾客只有 openid没有手机号这时查不到任何持卡记录。我的处理是页面照常展示卡列表返回空并提示“到店报手机号即可绑定”绑定动作放在后台收银台做由前台确认本人后手动关联。让顾客自己在小程序里输手机号也行但要加短信验证码不然有人拿别人手机号试一遍就能看到别人的消费记录。4.4 上线前的配置切换清单本地能跑通和能上线是两件事下面这几项我在每次部署前都会过一遍检查项本地线上不改的后果接口域名127.0.0.1HTTPS 域名并在小程序后台配好真机请求全部失败AppID/Secret测试号正式小程序拿不到 openid数据库时区Asia/ShanghaiAsia/Shanghai流水时间和实际差 8 小时上传目录jar 同级独立挂载目录重新部署后图片全丢定时任务可以关多实例只能开一个提成算两遍日志级别debuginfo按天切割磁盘被日志写满最后一行不是危言耸听日志级别留在 debug 跑一个月磁盘写满导致服务起不来是我遇到过最没技术含量但最难第一时间想到的故障。5. 避坑与排查门店上线后最容易出问题的五个点代码能跑起来只是开始真正的问题都在门店真实环境里冒出来。下面五条是我在不同项目里反复遇到的按“现象 → 原因 → 解决”记下来。5.1 报表金额差一分钱现象收银台充 500 送 50会员卡余额显示 550.00月底报表合计 549.99。差一分钱财务就是不签字。原因实体字段用了Double或者数据库字段定义成float。二进制浮点表示不了 0.1 这种十进制小数几百次加减之后误差累积最后在汇总时暴露出来。解决数据库一律DECIMAL(10,2)Java 一律BigDecimal构造时用字符串new BigDecimal(0.01)别用new BigDecimal(0.01)。比较大小用compareTo而不是equals因为1.0和1.00的equals返回 false。除法必须指定精度和舍入模式缺一个参数就可能抛ArithmeticException。5.2 连点两次核销次数少了两现象前台网络有点慢店员以为没点上又点了一次“确认核销”会员的疗程次数从 8 变成 6顾客当场就不高兴了。原因幂等只做在页面层——按钮置灰 800 毫秒。网络重试、用户双击、浏览器回退再提交任何一种都能绕过这层。解决接口层用biz_no唯一索引兜底前端每次打开核销页生成一个 UUID重试时带同一个值扣减用带条件的UPDATE ... WHERE remain_count ?不要“先 select 查剩余、再 if 判断、最后 update”。这两道加起来重复请求最多是查一次幂等表然后返回不会真的扣两次。5.3 真机上微信登录拿不到 openid现象开发者工具里一切正常真机扫码后一直卡在登录页日志里能看到errcode 40163或者40029。原因code被用了两次。常见于前端把code存进缓存登录失败时原样重发或者后端做了接口重试第一次其实已经成功。另一种情况是appid和secret不是同一个小程序测试阶段复制粘贴最容易搞混。解决code一次性使用失败就让前端重新调一次uni.login拿新的。在code2session那一步加日志把errcode、errmsg原样打出来不要只抛一句“登录失败”否则排查时完全是黑匣子。secret一旦怀疑泄露去后台重置别心存侥幸。5.4 门店数据串了现象A 店店长登录后会员列表里出现了 B 店的顾客甚至有 B 店的消费流水。原因SQL 忘了带store_id条件或者用了 MyBatis-Plus 的selectList直接查全表。还有一种更隐蔽的会员本身是跨店共享的但卡不是结果按会员维度查卡时把别的店的卡也带出来了。解决先把业务边界写死在文档里——会员共享、持卡归售卡门店、流水归核销门店、提成归核销门店。然后所有列表查询强制带门店条件能上租户插件就上让框架统一拼store_id。测试时至少造两家店的数据只造一家店的测试环境永远发现不了这个问题。5.5 跨天营业半夜的单子查不到现象晚上十一点半做的核销第二天上午查昨天的报表这笔单子不见了。原因营业日不等于自然日。很多门店凌晨一两点才结账用DATE(created_at) CURDATE()按自然日切零点之后的单子就被算到今天了。解决加一个business_date字段写库时按门店配置的结账截止时间算营业日/** 门店营业日截止时间之前算前一天 */ public static LocalDate businessDate(LocalDateTime now, LocalTime cutOff) { return now.toLocalTime().isBefore(cutOff) ? now.toLocalDate().minusDays(1) : now.toLocalDate(); }cutOff存在门店表里默认02:00报表、提成、日结全部按business_date分组不要再用created_at做日期维度。这个改动越早做越好等到有了历史数据再补就得回头刷全表。6. 二次开发加一套「门店分账」从加表开始而不是改主流程这套源码最常被提的改造需求是多门店分账顾客在 A 店买卡可以去 B 店消费收的钱和做的服务不是同一家店怎么分。我的原则是主流程一行不改。先加两张表store_share_rule存分配规则按售卡店和核销店的比例share_record存每次消费产生的分账明细。然后在扣次成功之后不去直接调用分账逻辑而是发一个事件// 扣次事务内只负责发事件不关心谁监听 applicationEventPublisher.publishEvent(new CardConsumedEvent(record)); // 分账监听器主事务提交后才执行失败只记日志不影响核销 TransactionalEventListener(phase TransactionPhase.AFTER_COMMIT) public void onConsumed(CardConsumedEvent event) { shareService.calculate(event.getRecord()); // 内部自己开新事务 }这样写有两个好处。核销不会因为分账规则没配好而失败前台该扣的次照扣分账逻辑出问题只需要补跑不用去修流水。验证方法也简单造三家门店、两种卡项、各做一笔跨店核销跑一段对账 SQL把share_record里两边的金额加起来必须等于流水的amount差一分都算没过。还有个小技巧给member和member_card各留一个ext_json字段二次开发要加的临时字段比如顾客的肤质备注、卡的赠送来源先塞进去别急着改表结构。等需求稳定了再抽成正式字段这样升级源码时冲突最少。从那以后我每次接这类美容院会员管理系统源码都强制先把扣次流水和分账金额跑一遍对账脚本再谈功能加不加——账对不上功能做得再花哨也是白搭。希望帮到你。本文还有配套的精品资源点击获取
