简介：这是一套面向美容院、美发店等线下门店经营者及中小型管理系统开发者的一站式会员管理源码，基于PHP构建并整合了微信端入口，可帮助门店实现会员档案、消费记录、权限分配与数据统计的数字化管理。资源包共1601个文件，以662个php业务逻辑文件、272个html页面模板、148个js脚本和35个css样式表为主体，另含164个gif、142个png等界面素材，以及18个config配置、16个functions函数库和1个sql数据库脚本，压缩包约23.4MB。系统权限可细分到每个功能模块，增删改查操作齐全，并内置Excel导出能力，便于日常经营数据整理与二次开发。目前已有3257人学习下载，适合需要快速搭建门店会员体系或研究PHP权限控制与微信端整合的开发者参考借鉴。
1. 美容院会员管理系统源码(含微信端)：一套能跑起来的私域运营底座
很多做美业 SaaS 的朋友都遇到过同一个尴尬：门店老板想要一套能自己掌控会员数据的系统，买现成的 SaaS 每年交钱、数据还在别人服务器上，找外包定制又动辄几万起步。这时候「美容院会员管理系统源码(含微信端)」就成了一个很实际的选项——它本质是一套可私有化部署的会员管理后端，加上一个跑在微信生态里的用户端入口，覆盖会员建档、储值、次卡、预约、消费记录、员工提成这几条主线。
它适合三类人：一是想给单店或小连锁做私域闭环的独立开发者；二是手里有几个美业客户、想沉淀一套可复用底座的小团队；三是想拿它当练手项目、把微信端登录和支付链路跑通的后端同学。不适合谁？不适合指望开箱即用、零代码上线的人，因为源码类项目真正的成本从来不在代码本身，而在部署、配置和业务参数对齐。下面我按「先立住概念、再动手复现、最后讲坑」的顺序拆开讲。
2. 会员模型与微信端登录：先把数据结构和身份链路定死
2.1 会员、储值、次卡三张核心表怎么设计
美容院的会员体系跟普通电商会员最大的区别是「预付费 + 次数核销」并存。一个客户可能既充了 3000 元储值，又买了一张 10 次的肩颈卡，这两条线的余额逻辑必须分开记，否则对账时一定翻车。我一般会拆成三张表：会员主表存基础身份和总余额快照，储值流水表记每一笔充值和扣减，次卡表记卡种、总次数、剩余次数和有效期。
-- 会员主表：只存身份和聚合快照，方便列表页快速查询 CREATE TABLE `member` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `openid` VARCHAR(64) NOT NULL COMMENT '微信端唯一标识', `phone` VARCHAR(20) DEFAULT NULL, `nickname` VARCHAR(64) DEFAULT NULL, `balance` DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '储值余额快照', `store_id` INT NOT NULL COMMENT '所属门店', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 储值流水：所有余额变动必须走这里，禁止直接改 member.balance CREATE TABLE `balance_log` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `member_id` BIGINT UNSIGNED NOT NULL, `change_amount` DECIMAL(10,2) NOT NULL COMMENT '正为充值，负为消费', `balance_after` DECIMAL(10,2) NOT NULL COMMENT '变动后余额，用于对账', `biz_type` TINYINT NOT NULL COMMENT '1充值 2消费 3退款 4调整', `operator_id` INT DEFAULT NULL COMMENT '操作员工', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_member_time` (`member_id`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这里的关键设计是balance_after字段。很多新手只记变动金额，结果一旦出现并发扣款或者人工调整，余额就对不上了，只能靠翻全部流水重算，非常痛苦。把每次变动后的余额落库，等于给自己留了一份后悔药，对账时直接比对最后一条流水的balance_after和主表balance是否一致即可。
次卡表同理，total_times和remain_times分开存，核销时用乐观锁或者UPDATE ... WHERE remain_times > 0保证不会超扣。参数上，store_id一定要留，哪怕你现在只做单店，将来接第二家店时不用改表结构。
2.2 微信端登录：code 换 openid 的最小闭环
微信端的身份链路是整个系统里最容易卡住新手的地方。核心就一句话：前端拿到临时code，后端拿code去换openid，然后自己签发登录态。不要在客户端存openid当凭证，也不要把session_key传给前端。
# 后端：用 code 换取 openid，并签发自己的 token import requests from itsdangerous import TimedJSONWebSignatureSerializer as Serializer APPID = "your_appid" SECRET = "your_secret" TOKEN_TTL = 7 * 24 * 3600 # 登录态 7 天 def login_by_code(code: str, store_id: int): # 1. 调用微信接口换 openid，注意这里必须服务端发起 url = "https://api.weixin.qq.com/sns/jscode2session" params = { "appid": APPID, "secret": SECRET, "js_code": code, "grant_type": "authorization_code", } resp = requests.get(url, params=params, timeout=5).json() if "openid" not in resp: # errcode 40029 表示 code 无效，通常是前端重复用了同一个 code raise ValueError(f"wx login failed: {resp}") openid = resp["openid"] # 2. 查库或自动注册，注意并发下要加唯一索引兜底 member = get_or_create_member(openid, store_id) # 3. 签发自己的 token，payload 里只放 member_id，不放敏感信息 s = Serializer(SECRET, expires_in=TOKEN_TTL) token = s.dumps({"mid": member.id}).decode() return {"token": token, "member_id": member.id}逻辑说明：第一步的jscode2session必须由服务端调用，因为secret不能出现在前端。第二步的get_or_create_member要处理并发，两个请求同时带同一个新openid进来时，靠uk_openid唯一索引让其中一个失败后重查，而不是先查后插。第三步签发 token 时只放member_id，门店、权限这些每次从库里查，避免 token 里信息过期。
参数上，TOKEN_TTL设 7 天是个折中，太长不安全，太短用户老要重新授权。timeout=5是必须的，微信接口偶尔抖动，不设超时会把你的 worker 拖死。常见错误码里，40029是 code 被重复使用，45011是频率限制，这两个在日志里要能一眼认出来。
3. 储值扣款与次卡核销：把并发和幂等这两件事做对
3.1 储值扣款为什么要用「先冻结再确认」
储值消费最怕的不是扣错，而是并发下扣重。用户点了一次「确认消费」，前端因为网络慢重发了一次请求，如果后端不做幂等，就会扣两次钱。我一般会在扣款前先落一条「待确认」的流水，用业务单号做唯一约束，确认成功后再改状态。
def consume_balance(member_id: int, amount: float, biz_no: str, operator_id: int): # biz_no 是前端生成的业务单号，同一次消费必须相同 with db.transaction(): # 1. 幂等检查：同一 biz_no 已处理过就直接返回 exist = query_one( "SELECT id, status FROM balance_log WHERE biz_no=%s", (biz_no,)) if exist: return {"ok": exist.status == 1, "log_id": exist.id} # 2. 行锁 + 余额校验，避免并发扣成负数 member = query_one( "SELECT balance FROM member WHERE id=%s FOR UPDATE", (member_id,)) if member.balance < amount: raise ValueError("余额不足") after = member.balance - amount # 3. 写流水 + 更新快照，两步在同一事务里 log_id = insert( "INSERT INTO balance_log(member_id, change_amount, balance_after, " "biz_type, biz_no, operator_id, status) VALUES(%s,%s,%s,2,%s,%s,1)", (member_id, -amount, after, biz_no, operator_id)) update("UPDATE member SET balance=%s WHERE id=%s", (after, member_id)) return {"ok": True, "log_id": log_id}逻辑说明：FOR UPDATE行锁保证同一会员的并发扣款串行化，biz_no唯一约束保证重发请求不会重复扣。注意biz_no要建唯一索引，光靠代码里的查询在极端并发下仍有窗口。参数上，amount用DECIMAL不要用FLOAT，浮点误差在金额场景是灾难。
3.2 次卡核销的乐观锁写法
次卡核销比储值简单，但同样要防超扣。常见做法是用UPDATE ... WHERE remain_times > 0这种带条件的更新，靠数据库的行锁和影响行数判断是否成功。
-- 核销一次：影响行数为 1 表示成功，为 0 表示次数已用完 UPDATE card SET remain_times = remain_times - 1, last_used_at = NOW() WHERE id = ? AND member_id = ? AND remain_times > 0 AND status = 1; -- 核销记录单独落表，用于员工提成和消费明细 INSERT INTO card_log(card_id, member_id, operator_id, biz_no, created_at) VALUES(?, ?, ?, ?, NOW());逻辑说明：把「判断剩余次数」和「扣减」合并到一条 SQL 里，是避免超扣最省事的办法。如果影响行数为 0，要么次数用完，要么卡已过期，要么member_id不匹配，业务层根据返回给用户不同提示。card_log一定要记operator_id，美业门店的提成计算全靠这张表，漏了就得返工。
参数上，status=1表示卡有效，过期卡用定时任务批量置为status=2，不要每次查询时用时间判断，那样索引用不上。biz_no同样建议加唯一索引做幂等。
4. 微信端支付与预约：把回调和对账链路跑通
4.1 支付回调必须做的三件事
微信支付回调是整个系统里最不能出错的一环。回调没处理好，用户付了钱系统没记账，门店就得手工补，非常影响信任。我一般要求回调处理里必须做三件事：验签、幂等、主动查单兜底。
def handle_pay_notify(headers: dict, body: str): # 1. 验签：用平台证书验证回调来源，失败直接拒绝 if not verify_signature(headers, body): return {"code": "FAIL", "message": "sign error"} data = parse_notify(body) out_trade_no = data["out_trade_no"] # 我们自己的订单号 # 2. 幂等：同一订单号只处理一次 order = query_one("SELECT status FROM recharge_order WHERE order_no=%s", (out_trade_no,)) if order and order.status == 1: return {"code": "SUCCESS"} # 已处理，直接回成功 # 3. 记账：更新订单 + 写储值流水，同一事务 with db.transaction(): update("UPDATE recharge_order SET status=1, paid_at=NOW() " "WHERE order_no=%s AND status=0", (out_trade_no,)) add_balance_log(out_trade_no, data["amount"]) return {"code": "SUCCESS"}逻辑说明：验签是防伪造回调，幂等是防微信重复推送（微信在没收到成功响应时会重推多次），主动查单是防回调丢失——定时任务扫「已支付但未记账」的订单，调微信查单接口确认。这三件事缺一个，线上都会出对账问题。
参数上，回调响应必须是微信要求的格式，返回非SUCCESS会触发重推。out_trade_no建议用「门店号 + 时间戳 + 随机数」生成，全局唯一且可读。
4.2 预约排期的冲突检测
预约功能看着简单，实际最容易出问题的是「同一个技师同一时段被约两次」。常见做法是用时间区间重叠判断，配合数据库唯一约束兜底。
-- 查询某技师在指定时段是否已有预约（半开区间 [start, end)） SELECT id FROM appointment WHERE technician_id = ? AND status IN (1, 2) -- 1待服务 2服务中 AND start_time < ? -- 新预约的结束时间 AND end_time > ?; -- 新预约的开始时间逻辑说明：用<和>而不是BETWEEN，是为了正确处理首尾相接的情况——上一单 10:00 结束，下一单 10:00 开始，不算冲突。status过滤掉已取消和已完成的单。高并发下光靠查询仍有窗口，建议对technician_id + start_time加唯一索引，插入冲突时捕获异常返回「该时段已被预约」。
参数上，时间统一存 UTC 或统一存本地时间，千万别混，混了之后跨时区或夏令时就是玄学 bug。门店营业时间、技师排班这些配置建议单独建表，不要硬编码在代码里。
5. 部署与避坑：源码类项目真正花钱的地方
5.1 从零部署的最小步骤
拿到源码后，别急着改业务代码，先把最小闭环跑起来。我一般的顺序是：环境准备 → 数据库初始化 → 后端配置 → 微信端配置 → 联调。
# 1. 后端依赖安装（以 Python 项目为例） python -m venv venv && source venv/bin/activate pip install -r requirements.txt # 2. 初始化数据库，注意先建库再导表结构 mysql -uroot -p -e "CREATE DATABASE beauty_member DEFAULT CHARSET utf8mb4;" mysql -uroot -p beauty_member < sql/schema.sql # 3. 配置环境变量，敏感信息不要写进代码 export DB_HOST=127.0.0.1 export DB_USER=root export DB_PASS=your_password export WX_APPID=your_appid export WX_SECRET=your_secret # 4. 启动后端，先确认健康检查接口通 python app.py --port 8000 curl http://127.0.0.1:8000/health逻辑说明：先跑通健康检查再配微信端，能把「环境问题」和「业务问题」分开排查。数据库字符集必须是utf8mb4，否则会员昵称里的 emoji 会存失败。环境变量方式管理密钥，是为了避免密钥跟着代码进版本库。
参数上，--port按实际部署环境调整，本地联调常用 8000。微信端配置里，服务器域名要在微信后台配置白名单，本地开发可以用内网穿透工具临时映射，但上线前必须换成正式域名。
5.2 避坑清单：五条血泪经验
现象一：用户付了钱，系统里余额没变。原因通常是支付回调地址配错，或者回调处理抛异常返回了非成功响应，微信重推几次后放弃。解决：先看微信支付后台的回调记录，再看自己服务日志里有没有收到请求；回调处理里所有异常都要捕获并记录，绝不能让它 500。
现象二：同一个会员余额偶尔对不上。原因多半是有人直接UPDATE member SET balance而没走流水表，或者并发扣款没加锁。解决：代码层面禁止直接改balance，全部走consume_balance；上线前用脚本比对member.balance和最后一条流水的balance_after，不一致的列出来人工核。
现象三：微信端登录偶尔失败，报 code 无效。原因是前端把同一个code用了两次，比如页面刷新时重复调用登录。解决：前端拿到code后立即调后端，成功后把 token 存本地，后续用 token 不再用code；后端对40029做明确日志，方便定位。
现象四：次卡核销后剩余次数变成负数。原因是核销逻辑先查后改，中间有并发。解决：改成UPDATE ... WHERE remain_times > 0的条件更新，判断影响行数；同时给核销接口加业务单号幂等。
现象五：预约列表里同一时段出现两条记录。原因是冲突检测只在应用层做，并发下两个请求都通过了检查。解决：对technician_id + start_time加唯一索引，插入冲突时捕获并返回友好提示；应用层检测作为第一道防线保留。
6. 进阶：把提成计算和经营报表做成可验证的
源码类项目跑通之后，真正拉开差距的是提成和报表这两块。提成算错，员工不信任系统；报表不准，老板不信任数据。我的做法是把提成规则配置化，报表用「明细可追溯」的方式生成，任何汇总数字都能下钻到原始流水。
提成规则建议单独建表，按「门店 + 项目 + 员工角色」维度配置比例，支持按固定金额和按比例两种模式。计算时不要实时算，而是每天凌晨跑批，把结果落成提成明细表，报表直接查明细汇总。这样即使规则改了，历史提成也不会被追溯影响。
-- 提成明细表：每条消费对应一条提成记录，可追溯 CREATE TABLE `commission_detail` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, `biz_no` VARCHAR(64) NOT NULL COMMENT '关联的消费单号', `member_id` BIGINT UNSIGNED NOT NULL, `staff_id` INT NOT NULL, `item_id` INT NOT NULL COMMENT '项目ID', `base_amount` DECIMAL(10,2) NOT NULL COMMENT '计提基数', `rate` DECIMAL(5,4) NOT NULL COMMENT '提成比例', `commission` DECIMAL(10,2) NOT NULL COMMENT '提成金额', `settle_date` DATE NOT NULL COMMENT '归属日期', PRIMARY KEY (`id`), UNIQUE KEY `uk_biz_staff` (`biz_no`, `staff_id`), KEY `idx_staff_date` (`staff_id`, `settle_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;逻辑说明：uk_biz_staff唯一约束保证同一笔消费对同一员工只计提一次，跑批重跑也不会重复。settle_date用于按月汇总，base_amount和rate都落库，是为了将来规则变了还能解释历史数据是怎么算出来的。报表查询时按staff_id + settle_date走索引，几万条数据也是毫秒级。
验证方法上，我习惯每周抽一天做「三单对账」：随机抽三笔消费，手工核对会员余额变动、次卡核销记录、提成明细三者是否一致。这个习惯帮我提前发现过好几次规则配置错误。参数上，rate用DECIMAL(5,4)能表示到万分位，够用且不浪费空间。
最后说个我自己的教训：早期做这类系统时，我总想着把功能做全再上线，结果拖了两个月，门店等不及用了别家。后来改成「先上会员建档 + 储值 + 核销三条线，预约和报表第二期补」，两周就跑起来了，门店反馈的问题反而帮我更快对齐了真实需求。源码类项目的价值不在于代码多完整，而在于你能多快把它改成贴合业务的样子。希望帮到你。
本文还有配套的精品资源，点击获取
