简介这是一套面向美容院、美业门店及中小型连锁机构的前后端一体化会员管理源码适合具备PHP与前端基础的开发者二次开发或直接部署使用。系统以会员档案、消费记录、项目与产品管理为核心权限可细分到每个功能点增删改查操作一应俱全并整合了Excel导出能力方便门店做数据统计与报表留存同时附带微信端可支撑会员在移动端查询与互动。压缩包共1601个文件约23.4MB以662个php业务逻辑文件、272个html页面模板、148个js脚本与35个css样式为主另含gif、png、jpg等界面素材及config、functions、inc等配置与公共函数文件并附sql建库脚本、readme与install安装说明目录结构完整。目前已有3257人学习下载可作为美业门店数字化管理的参考实现帮助读者快速理解会员权限体系、数据导出流程与微信端对接思路。1. 美容院会员管理系统的真实开发场景从手工记账到微信端打通一家中型美容院前台抽屉里塞着三本会员卡登记册店长每天下班前要花四十分钟对账客户预约靠微信聊天记录翻找会员卡余额和消费记录经常对不上。这不是段子是我接触过的一个模拟项目里的真实起点。美容院会员管理系统源码含微信端要解决的就是这类场景把会员档案、卡项管理、消费扣次、预约排班、微信端自助查询这几件事串成一条线。它适合谁一是想给自家店铺做数字化改造的店主二是需要一套可二次开发底座的开发者三是拿它当全栈练手项目的学生。这套源码的核心价值在于微信端和后台共用一套会员数据模型不是两个独立系统拼起来的。2. 会员数据模型与卡项设计先想清楚再写代码2.1 会员、卡项、消费记录三张核心表怎么定美容院系统的地基是数据模型。很多新手一上来就写界面结果做到扣次功能时发现卡项和会员的关系没设计好返工成本极高。常见做法是围绕三张主表展开会员表存基础信息和余额卡项表存次卡、储值卡、期限卡的类型和规则消费记录表存每一次扣次或扣款的流水。先看会员表的关键字段设计CREATE TABLE member ( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 会员ID, openid VARCHAR(64) DEFAULT NULL COMMENT 微信openid微信端绑定用, name VARCHAR(32) NOT NULL COMMENT 会员姓名, phone VARCHAR(20) NOT NULL COMMENT 手机号登录和查询凭证, balance DECIMAL(10,2) DEFAULT 0.00 COMMENT 储值余额, level TINYINT DEFAULT 1 COMMENT 会员等级 1普通 2银卡 3金卡, created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 建档时间, PRIMARY KEY (id), UNIQUE KEY uk_phone (phone), KEY idx_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会员主表;这里有几个参数值得说明。openid字段是微信端和后台打通的钥匙微信端用户授权后拿到 openid后台通过它关联到具体会员不需要用户每次输手机号。balance用 DECIMAL 而不是 FLOAT因为金额计算用浮点会出现精度问题这是血泪经验。uk_phone唯一索引防止同一个手机号重复建档idx_openid加速微信端查询。卡项表要区分卡类型因为次卡扣次数、储值卡扣金额、期限卡看有效期逻辑完全不同CREATE TABLE card ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, member_id INT UNSIGNED NOT NULL COMMENT 所属会员, card_type TINYINT NOT NULL COMMENT 1次卡 2储值卡 3期限卡, card_name VARCHAR(64) NOT NULL COMMENT 卡项名称, total_times INT DEFAULT 0 COMMENT 总次数次卡用, used_times INT DEFAULT 0 COMMENT 已用次数, amount DECIMAL(10,2) DEFAULT 0.00 COMMENT 卡内金额储值卡用, expire_at DATE DEFAULT NULL COMMENT 到期日期限卡用, status TINYINT DEFAULT 1 COMMENT 1正常 2冻结 3用完, PRIMARY KEY (id), KEY idx_member (member_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT会员卡项表;card_type决定了后续扣次逻辑走哪个分支。status字段很关键卡用完或过期后不删除记录只改状态方便对账和追溯。我一般会把used_times和total_times分开存而不是只存剩余次数因为客户经常问“我一共买了多少次、用了多少次”分开存查询更直接。2.2 扣次与余额变更的事务处理扣次操作是这类系统最容易翻车的地方。客户做了一次面部护理前台点扣次如果程序先更新卡项再写消费记录中间网络断了就会出现卡扣了但没记录的情况。正确做法是把扣次和写流水放在一个事务里# 扣次核心逻辑使用数据库事务保证一致性 def deduct_card(db, card_id, member_id, operator): try: db.begin() # 行锁防止并发扣次同一张卡同时被两个前台操作 card db.query_one( SELECT * FROM card WHERE id%s FOR UPDATE, (card_id,) ) if card[status] ! 1: raise Exception(卡项状态异常无法扣次) if card[card_type] 1: # 次卡检查剩余次数 if card[used_times] card[total_times]: raise Exception(次数已用完) db.execute( UPDATE card SET used_timesused_times1 WHERE id%s, (card_id,) ) elif card[card_type] 2: # 储值卡检查余额是否足够 if card[amount] 100: raise Exception(余额不足) db.execute( UPDATE card SET amountamount-100 WHERE id%s, (card_id,) ) # 写消费流水 db.execute( INSERT INTO consume_log(member_id,card_id,operator,created_at) VALUES(%s,%s,%s,NOW()), (member_id, card_id, operator) ) db.commit() except Exception as e: db.rollback() raise eFOR UPDATE是行级锁防止两个前台同时给同一张卡扣次导致超扣。事务的 commit 和 rollback 保证要么全成功要么全回滚。operator字段记录操作人方便后续追责。这段逻辑看着简单但少了FOR UPDATE或事务在并发场景下必出问题。3. 微信端对接授权、绑定与自助查询3.1 微信授权登录与会员绑定流程微信端的核心是让会员在公众号或小程序里查到自己的卡项和余额。流程分三步微信授权拿 code后端换 openid再用 openid 匹配会员。常见做法是用静默授权snsapi_base拿 openid不弹窗用户体验好。// 前端跳转微信授权页redirect_uri 是后端回调地址 const appId your_appid; const redirectUri encodeURIComponent(https://your-domain.com/wx/callback); const scope snsapi_base; // 静默授权只拿openid const state bind; // 自定义参数回调时带回 window.location.href https://open.weixin.qq.com/connect/oauth2/authorize?appid${appId} redirect_uri${redirectUri}response_typecodescope${scope}state${state}#wechat_redirect;后端回调拿到 code 后换 openid# 后端用code换openid再绑定会员 import requests def wx_callback(code): url https://api.weixin.qq.com/sns/oauth2/access_token params { appid: APPID, secret: APPSECRET, code: code, grant_type: authorization_code } resp requests.get(url, paramsparams).json() openid resp.get(openid) if not openid: raise Exception(授权失败: %s % resp.get(errmsg)) # 查会员是否已绑定openid member db.query_one(SELECT * FROM member WHERE openid%s, (openid,)) if not member: # 未绑定引导用户输入手机号验证 return {need_bind: True, openid: openid} return {need_bind: False, member: member}scope选snsapi_base还是snsapi_userinfo要看需求。只要 openid 做身份识别用 base 就够不弹授权框。要拿昵称头像才用 userinfo但会多一次弹窗转化率会降。state参数用来防 CSRF回调时要校验。openid 拿到后先查是否已绑定没绑定就引导输手机号手机号验证通过后把 openid 写回会员表。3.2 微信端卡项查询接口与缓存策略会员绑定后微信端要展示卡项列表和余额。这个接口调用频率高但数据变化不频繁适合加缓存。我一般用 Redis 缓存会员卡项数据扣次时主动删缓存下次查询再重建。# 微信端查询会员卡项带Redis缓存 import json def get_member_cards(openid): cache_key member:cards:%s % openid cached redis.get(cache_key) if cached: return json.loads(cached) member db.query_one(SELECT * FROM member WHERE openid%s, (openid,)) if not member: return {error: 未绑定} cards db.query( SELECT * FROM card WHERE member_id%s AND status1, (member[id],) ) result { balance: str(member[balance]), cards: cards } # 缓存5分钟扣次时会主动删除 redis.setex(cache_key, 300, json.dumps(result)) return result缓存时间设 300 秒是个折中太短缓存没意义太长数据不一致。关键是扣次接口里要加一行redis.delete(member:cards:%s % openid)保证扣次后微信端立刻能看到最新次数。这个细节很多源码包会漏掉导致客户扣完次刷新还是旧数据前台被投诉。4. 预约排班与消费流水对账4.1 预约时间段冲突检测美容院的预约不是简单选个日期要精确到时间段还要检测美容师是否已被占用。常见做法是预约表存开始时间和结束时间插入前查重叠。-- 查询某美容师在指定时间段是否已有预约 SELECT COUNT(*) FROM appointment WHERE staff_id %s AND status 1 AND start_time %s -- 新预约结束时间 AND end_time %s; -- 新预约开始时间这个重叠判断逻辑是已有预约的开始时间小于新预约的结束时间且已有预约的结束时间大于新预约的开始时间两个条件同时满足就是冲突。参数传入时注意时间格式统一我一般用YYYY-MM-DD HH:MM:SS。status1过滤掉已取消的预约。如果返回大于 0就提示该时段已被占用。4.2 消费流水与卡项余额的对账脚本系统跑一段时间后店长最关心的是账对不对。写一个对账脚本把每个会员的卡项余额和消费流水汇总比对# 对账脚本比对卡项余额与流水汇总 def reconcile(): members db.query(SELECT id,name FROM member) for m in members: # 卡项表里的当前余额 cards db.query( SELECT SUM(amount) AS card_total FROM card WHERE member_id%s AND card_type2 AND status1, (m[id],) ) card_total cards[0][card_total] or 0 # 流水表里的充值减消费 logs db.query( SELECT SUM(CASE WHEN type1 THEN amount ELSE -amount END) AS log_total FROM consume_log WHERE member_id%s, (m[id],) ) log_total logs[0][log_total] or 0 if abs(float(card_total) - float(log_total)) 0.01: print(对账不平: %s 卡项%s 流水%s % (m[name], card_total, log_total))type1表示充值其他表示消费用 CASE WHEN 汇总。差额超过 0.01 就报警因为金额是 DECIMAL理论上不该有误差出现差额说明有绕过事务的写操作。这个脚本建议每天凌晨跑一次输出到日志店长早上就能看到。5. 避坑与常见问题排查5.1 微信端 openid 拿不到或为空现象用户授权后回调后端换 openid 返回空。原因通常是redirect_uri域名没在微信后台配置或者appid、secret填错。解决检查微信后台的网页授权域名是否包含当前域名确认配置文件里的 appid 和 secret 与后台一致。注意redirect_uri要 URL 编码且不能带端口号除非后台配了。5.2 扣次后微信端数据不刷新现象前台扣次成功会员微信端刷新还是旧次数。原因查询接口加了缓存扣次时没删缓存。解决在扣次事务 commit 之后调用redis.delete删除对应会员的缓存 key。注意删除操作要放在事务外事务回滚了就不该删缓存。5.3 并发扣次导致次数超扣现象同一张卡两个前台同时操作扣了两次但只显示扣了一次或者次数变成负数。原因扣次逻辑没加行锁或事务隔离级别不够。解决用SELECT ... FOR UPDATE加行锁并把扣次和写流水放同一事务。注意 MySQL 的 InnoDB 引擎才支持行锁MyISAM 不支持。5.4 金额计算出现小数误差现象储值卡余额扣款后出现 0.009999 这类数字。原因金额字段用了 FLOAT 或 DOUBLE。解决金额字段一律用 DECIMAL(10,2)Python 里用 Decimal 类型计算不要用 float。注意数据库连接配置里要设置decimal转换否则取出来还是字符串。5.5 预约时间重叠判断失效现象同一美容师同一时段被预约了两次。原因重叠判断的 SQL 条件写反了或者时间格式不统一导致比较失败。解决确认条件是start_time 新结束 AND end_time 新开始并统一时间格式。注意前端传的时间要转成标准格式再入库不要直接存字符串。6. 二次开发与数据导出把系统用出花来源码包拿到手直接跑起来只是第一步。真正让这套系统产生价值的是二次开发。我一般会先做两件事一是把会员数据导出成 Excel 给店长做月度分析二是加一个消费提醒的定时任务。数据导出用 Python 的 openpyxl 库把会员、卡项、流水三张表拼成一张宽表# 导出会员消费汇总到Excel from openpyxl import Workbook def export_report(): wb Workbook() ws wb.active ws.title 会员消费汇总 ws.append([会员姓名, 手机号, 卡项名称, 总次数, 已用次数, 剩余金额]) rows db.query( SELECT m.name, m.phone, c.card_name, c.total_times, c.used_times, c.amount FROM member m LEFT JOIN card c ON c.member_id m.id WHERE c.status 1 ) for r in rows: ws.append([r[name], r[phone], r[card_name], r[total_times], r[used_times], str(r[amount])]) wb.save(/tmp/member_report.xlsx)LEFT JOIN保证没有卡项的会员也能出现在报表里。str(r[amount])是因为 openpyxl 不认 Decimal 类型要转字符串。这个报表店长拿去就能看哪些会员卡快用完了主动打电话提醒续卡比群发广告有效得多。消费提醒的定时任务用 APScheduler 挂在后台每天扫一遍卡项剩余次数少于 3 次或余额低于 200 的往微信端推一条模板消息。模板消息的 openid 从会员表取注意要过滤掉没绑定的会员。还有一个进阶玩法是给系统加操作日志。前台扣次、改余额、删预约这些敏感操作全部记到operation_log表字段包括操作人、操作类型、操作前后的值、时间。出了纠纷直接查日志比翻聊天记录靠谱。我一般会在扣次函数里加一行写日志的代码和业务逻辑放同一事务保证日志和操作一致。从那以后我每次拿到一套会员管理源码第一件事就是跑对账脚本确认账目逻辑没问题再动界面。这套系统看着简单但金额和次数相关的逻辑一旦有漏洞后期补数据的成本远高于前期多花两小时检查。希望帮到你。本文还有配套的精品资源点击获取