企业官网建设流程全解析

简介：一套专注美容院场景的会员管理系统源码，含微信端，面向需要搭建会员档案、消费记录、储值卡与权限体系的开发者、店主或门店运营人员，可直接部署也可二次定制。系统权限可细化到每一个功能节点，增删改查等基础操作完整，同时整合了表格导出能力，方便日常对账和会员数据归档。压缩包共1601个文件，约23.4MB；代码以662个PHP后端逻辑文件、272个HTML页面、148个JS与35个CSS前端文件为主，另含GIF/PNG/JPG图片素材及config、install、sql等安装配置辅助文件，目录结构清晰，便于按模块查看和学习。同时包含功能配置、数据库脚本与扩展接口，可套用到真实门店工作流中。目前已有3256人浏览学习，适合具备一定PHP开发经验、希望快速落地美容院会员管理流程或进行功能扩展的读者参考。

1. 美容院会员管理系统源码含微信端：先别急着部署，先看它到底要解决什么

先说一个比较反直觉的结论：一套美容院会员管理系统源码含微信端，真正值钱的地方往往不是门店管理、项目列表、员工排班这些 CRUD 页面，而是三张资金流水表和两个微信回调。办卡、储值、耗卡、退款，每一笔钱都直接牵动余额和员工提成；微信端表面是登录和余额查询，实际要扛住的是 OAuth 授权、支付回调验签和防重复扣款。很多团队把源码买回来部署完就丢一边，等财务对不上账才开始翻代码，那时候改造成本已经很高了。这篇文章按接手源码的标准动作来拆：先看目录和技术选型判断能不能用，把数据模型立住，再把微信端登录和支付链路跑通，最后给出五个最容易翻车的现场和排查方法。适合给美容院做私域系统外包的开发者，以及想快速评估一套源码能否直接上线的技术负责人。

2. 拆源码结构与技术选型：为什么“单体后台+H5微信端”是美容院最稳的组合

拿到源码后的第一件事不是启动它，而是把整个目录从头到尾过一遍。源码的结构往往能直接暴露这套系统的设计思路和上限：是随手拼出来的演示项目，还是真的在业务里跑过的成品。美容院会员系统的业务量级决定了它不太需要微服务，单体应用加一个 H5 微信端，是最常见也最务实的组合。下面从目录结构、技术栈选择和部署参数三个角度拆开看。

2.1 从源码目录看系统边界：admin、api、h5 三个模块各管什么

一个典型的美容院会员管理系统源码（PHP 版）通常长这样：

project/ ├── app/ │ ├── admin/ # 后台管理：登录、会员列表、卡项配置、员工管理 │ ├── api/ # 微信端接口：授权登录、余额、卡项、下单、核销 │ └── common/ # 公共模型、工具类、支付服务 ├── config/ # 数据库、公众号、支付配置 ├── public/ │ ├── h5/ # 微信端 H5 静态页（HTML/CSS/JS） │ └── uploads/ # 用户上传的图片、资质文件 ├── runtime/ # 日志、缓存 └── database/ └── init.sql # 建库建表脚本

app/admin和app/api是两个入口模块，前者走后台登录，后者给微信端提供 JSON 接口。public/h5是微信端页面本身，调用api模块的接口。这种“一个后端两套入口”的结构，好处是会员表、卡项表、订单表都共用同一套模型，后台改一个字段，微信端接口立即生效。

这里要特别留意标题里“微信端”三个字到底指什么。常见做法是 H5 页面而不是微信小程序源码。原因很现实：H5 部署在同一个域名下，打开即用，不需要单独注册小程序账号、不需要走类目审核，单店客户当天就能用起来。小程序虽然体验更好，但源码里如果没有miniprogram目录，只有public/h5，那它就是 H5 方案。购买前先确认这一点，能避免一大半的沟通纠纷。

2.2 技术选型：什么时候 PHP 老源码够用，什么时候必须上 Java

老源码市场上 PHP 版占绝大多数，Java 版也有但价格和改造成本都高。做选型判断时，关键不是看技术新旧，而是看门店数量和日订单量。

我现在接这类项目，会先问三个问题：有没有连锁门店？有没有多门店分账需求？日订单峰值会不会超过几百笔？如果三个都是否定答案，PHP 老源码加一次代码审计完全够用；如果要做连锁和分账，我一般直接建议用 Java 重写核心资金模块，别在 PHP 上打补丁。另一个判断点是看源码里有没有统一使用 ORM 和事务。如果连事务都没有，后续加储值功能会非常痛苦，这类源码别指望“稍微改改就能上线”。

2.3 部署环境下限：Nginx、PHP、MySQL 三个关键配置

部署环境的最低要求并不高：PHP 7.4 以上、MySQL 5.7 以上、Nginx 即可。微信支付 v3 和公众号 OAuth 都依赖 openssl 扩展，PHP 这边必须装好curl、openssl、pdo_mysql、fileinfo。Nginx 的配置有一个容易踩坑的点是上传目录的 PHP 执行权限，很多老源码把上传目录放在可执行路径下，一张图片马就能打穿整个服务器。

一个安全可用的 Nginx 虚拟主机配置如下：

server { listen 80; server_name your-domain.com; # root 指到 public/，app、config、runtime 都在 web 根目录之外 root /data/www/beauty/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?s=$uri; } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } # 上传目录只当静态资源，禁止解析 PHP location ^~ /uploads/ { expires 30d; } }

这里的逻辑是：root指向public/，业务代码模块全部放在 web 根目录之外，外部无法直接访问；location ^~ /uploads/用了^~前缀匹配，命中后不再往下匹配正则的 PHP location，所以uploads/下的.php文件会被当成静态资源直接返回，不会被 PHP-FPM 执行。这一点是上线前必须检查的，老源码里最容易出问题的地方就是这里。

提示：如果源码是 Java 版，部署就变成 JDK + Tomcat/内置容器 + Maven 打包，但安全原则一样——上传目录不能解析脚本，配置文件不能放在静态可访问路径下。

3. 核心数据模型：六张表理清储值、卡项、流水与消耗的关系

数据模型是一套会员系统的地基。美容院业务有个特点是预付费，钱先进系统，服务后核销。这意味着余额、次数、到期的状态变化都必须有据可查。很多源码翻车就翻在“改余额只改一个字段，不记流水”。先把核心表结构定下来，后面所有功能都是在这几张表上做文章。

3.1 会员、卡项、资金流水：先看清资金怎么流动

核心表就六张：会员表、卡项模板表、会员卡表、订单表、资金流水表、消耗记录表。会员表存实时余额，卡项模板表定义卡种，会员卡表记录会员买的是哪张卡、剩多少次，订单表承载微信支付，资金流水表记录每一笔余额变动，消耗记录表记录每次到店核销。下面是建表脚本里最关键的四张表：

-- 会员表：手机号是登录凭证，balance 是实时储值余额 CREATE TABLE `member` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `phone` varchar(20) NOT NULL COMMENT '手机号，登录与唯一识别', `name` varchar(50) NOT NULL DEFAULT '', `balance` decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT '实时可用余额', `gift_balance` decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT '赠送余额，不可提现', `total_recharge` decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT '累计充值', `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '1正常 0冻结', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员表'; -- 卡项模板：定义次卡/时长卡/储值卡 CREATE TABLE `card_template` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL COMMENT '卡项名称', `type` tinyint(1) NOT NULL COMMENT '1次卡 2时长卡 3储值卡', `total_times` int(11) NOT NULL DEFAULT 0 COMMENT '总次数，0为不限次', `price` decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT '售价', `valid_days` int(11) NOT NULL DEFAULT 0 COMMENT '有效期天数，0为永久', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='卡项模板表'; -- 会员卡：会员和卡项的关系，核销时扣 remain_times CREATE TABLE `member_card` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(11) NOT NULL, `card_template_id` int(11) NOT NULL, `remain_times` int(11) NOT NULL DEFAULT 0 COMMENT '剩余次数', `expire_time` datetime DEFAULT NULL COMMENT '到期时间', `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '1可用 2已用完 3已过期', PRIMARY KEY (`id`), KEY `idx_member_status` (`member_id`,`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员卡表'; -- 资金流水：充值、消费、退款、赠送都记在这里 CREATE TABLE `capital_flow` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `member_id` int(11) NOT NULL, `type` tinyint(1) NOT NULL COMMENT '1充值 2消费 3退款 4赠送', `amount` decimal(10,2) NOT NULL COMMENT '变动金额，正数', `balance_after` decimal(10,2) NOT NULL COMMENT '变动后余额', `gift_balance_after` decimal(10,2) NOT NULL COMMENT '变动后赠送余额', `out_trade_no` varchar(64) NOT NULL DEFAULT '' COMMENT '外部订单号，支付幂等用', `operator_id` int(11) NOT NULL DEFAULT 0 COMMENT '员工ID，0为线上自助', `remark` varchar(255) NOT NULL DEFAULT '', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_out_trade_no` (`out_trade_no`), KEY `idx_member_time` (`member_id`,`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='资金流水表';

member.balance是实时余额，total_recharge只增不减，用来做会员等级和营销统计。capital_flow是资金变动的完整证据链，每一笔充值、消费、退款、赠送都必须写一条流水。判断一套源码能不能用，先看它有没有这张流水表：没有的话，财务对账就是一笔糊涂账。

3.2 储值账户建模：余额精度、赠送余额与并发扣款的取舍

余额字段用DECIMAL(10,2)就够，不要用FLOAT或DOUBLE。前者是定点数，后者是浮点数，浮点运算在涉及分的时候会出现 0.1 + 0.2 = 0.30000000000000004 这类问题。如果是连锁品牌经常搞“充 1000 送 200，余额分本金和赠送”，就把赠送部分拆成gift_balance字段单独存，消费时先扣赠送余额、再扣本金。这些决策不写死在代码里会出大问题。

并发扣款是资金类系统最核心的坑。场景是：会员没退出登录，前台和微信端同时发起消费，两端都先查余额、再改余额，后提交的覆盖了先提交的，余额被多扣或者被少扣。解法是条件更新，把扣款判断交给数据库：

-- 扣储值余额：影响行数为 1 表示扣款成功，为 0 表示余额不足 UPDATE `member` SET `balance` = `balance` - 50.00 WHERE `id` = 10001 AND `balance` >= 50.00;

-- 扣次数：同样用条件判断，避免并发把次数扣成负数 UPDATE `member_card` SET `remain_times` = `remain_times` - 1 WHERE `id` = 10086 AND `remain_times` >= 1 AND `status` = 1;

逻辑说明：这两条 SQL 把“判断”和“扣减”合并成一条原子操作，数据库的行锁保证同一时刻只有一个事务能执行成功。业务代码只需要检查mysqli_affected_rows()或 PDO 的rowCount()，为 1 就是扣款成功，为 0 就返回“余额不足”或“次数不足”。我在代码审计时只要看到源码里是先SELECT再UPDATE，就会直接标红，这是资金系统最典型的超卖和错账来源。

3.3 唯一约束与组合索引：初始化 SQL 里必须写进去的细节

索引设计有两个地方必须提前考虑：一是防止重复支付回调，二是支撑微信端“我的账单”列表。上面capital_flow表里的uk_out_trade_no唯一索引，作用就是让同一笔微信支付订单在数据库层面只能写一条流水。因为微信支付在极端情况下会重复推送回调，如果业务代码没有判断“订单是否已支付”，这个唯一索引就是最后一道保险。

idx_member_time (member_id, create_time)组合索引支撑的是微信端余额明细页和后台会员账单列表。这种查询永远是以member_id过滤、按create_time排序的，组合索引能直接命中，避免文件排序。member_card表上的idx_member_status (member_id, status)组合索引，对应的是“我的卡包”页，查询条件是某个会员、状态可用、按到期时间排序。加这两组索引后，单表几十万行数据也不会卡。老源码里常见问题是没有组合索引，只给member_id建了个单列索引，数据量上来后明细页会越翻越慢。

4. 微信端对接全流程：H5授权登录、支付v3回调验签与接口约定

微信端是整个系统的门面，也是技术风险最集中的地方。H5 页面跑在微信内置浏览器里，登录要过公众号 OAuth，充值要接微信支付，每一环都有它自己的坑。这章按“登录 → 支付 → 接口约定”的顺序，把完整链路串起来。

4.1 H5 怎么用微信登录：OAuth 网页授权的两种 scope

移动端 H5 怎么使用微信登录，是微信端开发第一个要回答的问题。微信网页授权有两种 scope：snsapi_base静默授权，用户无感知直接拿 openid，适合登录识别；snsapi_userinfo需要用户手动确认授权，可以拿到昵称和头像，但会多一步授权页面。美容院会员系统里，老会员应该走静默授权只拿 openid，新会员再引导手机号绑定；一上来就要昵称头像反而流失率高。

跳转授权页的代码：

<?php // 入口：跳转微信授权页 $appid = 'wx1234567890abcdef'; $appsecret = 'your_app_secret'; $redirect = urlencode('https://api.your-domain.com/wechat/callback'); // state 用于防 CSRF，回调时要校验同一个值 $state = md5(uniqid('', true) . session_id()); session_start(); $_SESSION['wechat_state'] = $state; $scope = 'snsapi_base'; // 静默授权，只拿 openid // 需要昵称头像时改成 snsapi_userinfo，用户会看到授权确认页 $authorize_url = "https://open.weixin.qq.com/connect/oauth2/authorize" . "?appid={$appid}" . "&redirect_uri={$redirect}" . "&response_type=code" . "&scope={$scope}" . "&state={$state}#wechat_redirect"; header('Location: ' . $authorize_url); exit;

回调处理代码：

<?php // 回调：用 code 换 openid session_start(); $code = $_GET['code'] ?? ''; $state = $_GET['state'] ?? ''; if ($code === '' || $state !== ($_SESSION['wechat_state'] ?? '')) { exit('微信授权失败，请重新打开页面'); } $token_url = "https://api.weixin.qq.com/sns/oauth2/access_token" . "?appid={$appid}" . "&secret={$appsecret}" . "&code={$code}" . "&grant_type=authorization_code"; $resp = file_get_contents($token_url); $data = json_decode($resp, true); if (!isset($data['openid'])) { // 常见原因：code 已被使用或过期（约 5 分钟） exit('登录已过期，请关闭页面重新进入'); } $openid = $data['openid']; // 查 member 表，没有就按 openid 建立临时会员，再走手机号绑定 $user = member_find_by_openid($openid); if (!$user) { $user = member_create_from_openid($openid); } // 生成业务 token 返回给 H5，后续接口带在 header 里 issue_token($user);

参数说明：state参数必须和自己生成的值一致，防止外部伪造回调；code是一次性的，有效期为 5 分钟，换过一次 openid 之后就失效。很多死循环问题就出在这里，详见第 5 章。

4.2 微信支付 v3 接入：下单、验签、解密、幂等的完整链路

微信支付 v3 和 v2 的最大区别是全面拥抱证书和签名。v2 用 MD5 签名的时代已经过去，v3 用商户私钥做 SHA256withRSA 签名，回调用平台证书验签，通知内容用 AES-256-GCM 解密。第一次接的时候会被证书序列号、APIv3 Key、平台证书这几个概念绕晕，理顺后其实就四步。

下单参数的核心代码：

<?php // 微信支付 v3 下单（H5 场景） $params = [ 'appid' => $appid, // 公众账号 AppID 'mchid' => $mchid, // 商户号 'description' => '会员余额充值', 'out_trade_no' => $outTradeNo, // 商户单号，必须全局唯一 'notify_url' => 'https://api.your-domain.com/wechat/pay/notify', 'amount' => [ 'total' => 1000, // 单位是分：1000 分 = 10 元 'currency' => 'CNY' ], ]; // 签名使用商户私钥做 SHA256withRSA // Authorization 请求头固定格式： // WECHATPAY2-SHA256-RSA2048 mchid="...",nonce_str="...",timestamp="...",serial_no="...",signature="..."

回调处理是整个支付链路里最重要的一环：

<?php // 回调入口：验签、解密、幂等三步缺一不可 $body = file_get_contents('php://input'); $headers = wechatpay_headers(); // Wechatpay-Signature / Timestamp / Nonce / Serial // 1. 验签：用微信支付平台证书公钥验签，明文是 timestamp\nnonce\nbody\n if (!verify_wechatpay_signature($headers, $body)) { http_response_code(401); exit; // 不返回 SUCCESS，微信会在时间窗口内重试 } // 2. 解密：AES-256-GCM，用 APIv3 Key 解出订单真实状态 $plain = decrypt_resource($body, $apiv3Key); // 3. 幂等：先查订单是否已处理过 if (order_is_paid($plain['out_trade_no'])) { echo '{"code":"SUCCESS"}'; exit; // 重复通知，直接告诉微信已收讫 }

逻辑说明：回调验签如果失败，一定不要返回 SUCCESS，否则微信支付会认为通知送达了，实际业务里订单状态就没更新。解密后的$plain里有out_trade_no、transaction_id、trade_state等字段，拿到后先查幂等，再开事务更新订单和余额。transaction_id是微信侧单号，必须落库，后面退款要用。

提示：H5 支付有两种实现路线。一种是用微信支付的 H5 支付接口，用户在微信外浏览器也可用；另一种是公众号支付（JSAPI），只能在微信内用chooseWXPay拉起。美容院会员基本都是微信内操作，走 JSAPI 即可，注意区分。

4.3 微信端接口约定：一个能直接照抄的返回结构

微信端接口统一返回 JSON，约定格式为{code, msg, data}，code = 0表示成功，非 0 表示业务错误。登录成功后接口返回一个自定义 token，H5 每次请求把它放在Authorization头里，后端根据 token 查 session 或缓存拿到会员 ID。会员信息的返回结构如下：

{ "code": 0, "msg": "ok", "data": { "token": "f8a1b2c3...", "member": { "id": 10001, "phone": "138****8000", "balance": "680.50", "gift_balance": "200.00", "cards": [ { "card_name": "面部年卡", "remain_times": 8, "expire_time": "2026-03-01 00:00:00" } ] } } }

这里有个细节：金额字段在 JSON 里用字符串而不是数字返回。因为 JavaScript 对0.1 + 0.2的浮点误差同样存在，如果把balance序列化成数字类型，前端在做余额展示和金额计算时会出现精度问题。后端用DECIMAL存储，接口层转成字符串输出，前端展示时再转成分做计算，是一套最稳妥的约定。老源码里常见毛病是直接回整个数据表结构，把capital_flow的全部字段原样丢给前端，既泄露内部字段，又造成不必要的流量开销。

5. 避坑与排查：美容院会员系统最容易翻车的五个现场

这一章都是实战里的血泪经验，每一条都按“现象 → 原因 → 解决”来写，可以直接对号入座。

5.1 余额对不上账：先跑对账 SQL，再看并发写

现象：财务月底对账，系统余额和实际收入差出好几千，充值记录、消费记录都对得上，但余额加减之后和系统里的余额不一致。

原因：老源码更新余额时只写member.balance，没有同步写capital_flow流水；或者订单退款时改了订单状态但漏了退余额。余额变成无源之水，自然对不上。

解决：先确认流水表和余额字段的对应关系，再跑对账 SQL，把所有会员的系统余额和流水累计额做差：

SELECT m.id, m.phone, m.balance AS system_balance, COALESCE(SUM( CASE WHEN f.type IN (1,4) THEN f.amount WHEN f.type IN (2,3) THEN -f.amount ELSE 0 END ), 0) AS flow_balance, m.balance - COALESCE(SUM( CASE WHEN f.type IN (1,4) THEN f.amount WHEN f.type IN (2,3) THEN -f.amount ELSE 0 END ), 0) AS diff FROM member m LEFT JOIN capital_flow f ON f.member_id = m.id GROUP BY m.id, m.phone, m.balance HAVING diff <> 0;

这条 SQL 能直接列出所有“系统余额和流水对不上”的会员。之后把漏写流水、退款未冲正的数据补录回去，再从代码层面规定：凡是余额变动，必须在一个事务里同时更新member.balance和插入capital_flow，两条 SQL 一起提交或一起回滚。

5.2 微信授权死循环：code 一次性，别在回调里再跳授权

现象：用户在微信里打开 H5 页面，一直在授权页和回调地址之间来回跳，页面刷几次都没法正常登录。

原因：回调里获取 openid 失败后，代码又重定向回授权入口，微信再次生成新 code 再走回调，如果某个环节持续失败，就形成了死循环。另一个常见原因是code被重复使用——微信规定 code 只能换取一次 access_token，换取失败或已过期都会报错。

解决：在 session 里加一个授权流程标记，只有第一次进授权入口时才跳转，已经进入过流程就不再重定向，直接停住报错。

if (empty($_SESSION['wechat_auth_started'])) { $_SESSION['wechat_auth_started'] = time(); header('Location: ' . $authorize_url); exit; } // 已经进过授权流程又失败，说明 code 失效或网络异常 // 此时必须停住，而不是再跳一次授权页 exit('微信授权未完成，请重新打开页面');

这样的处理会让用户看到明确错误提示，而不是无限跳转。真正常见的原因除了代码问题，还有公众号后台的回调域名配置错误，检查时先看redirect_uri域名和公众号后台“网页授权域名”是否一致，这个配置错了，code 回不来，也会表现成跳转异常。

5.3 并发核销把次数扣成负数：普通 select 判断靠不住

现象：同一张会员卡在前后台同时被核销，剩余次数变成负数，或者会员明明只剩一次，两个员工同时核销都成功了。

原因：业务代码先SELECT remain_times判断大于 0，再执行UPDATE。两个请求同时通过判断，后执行的UPDATE把次数扣成负数。这是典型的并发竞态问题。

解决：用条件更新替代先查后改，把判断条件放进 SQL 的WHERE里，参考第 3.2 节的写法。先写UPDATE member_card SET remain_times = remain_times - 1 WHERE id = ? AND remain_times >= 1 AND status = 1，然后检查影响行数。为 0 就返回“次数不足，请先续卡”，为 1 就继续后续的消耗记录写入。也可以给核销操作加一个针对会员卡 ID 的 Redis 锁，但条件更新更简单可靠，不需要额外引入缓存组件。

5.4 支付回调重复通知：事务和唯一索引缺一不可

现象：一笔 1000 元的充值，会员余额到账了 2000 元，后台订单只显示一笔支付成功。

原因：微信支付在极端情况下会对同一笔订单重复推送回调，业务代码在回调里先查订单状态，发现未支付，然后更新余额；第二条回调进来时，订单状态可能已经被更新，但如果代码没有查状态就再次执行“更新余额”操作，就会重复入账。

解决：在数据库层面用out_trade_no唯一索引兜底，业务代码里用事务加锁处理回调。先查订单是否已支付，已支付就直接返回 SUCCESS，不再执行任何写操作：

$this->db->transaction(); // 对订单加锁，防止两个回调同时改同一笔订单 $order = $this->db->where('out_trade_no', $outTradeNo)->lock(true)->find(); if ($order['pay_status'] == 1) { $this->db->commit(); exit('{"code":"SUCCESS"}'); // 已处理过，幂等返回 } // 未处理：更新订单状态 + 写资金流水 + 更新余额，全部在同一事务里 $this->db->where('id', $order['id'])->update(['pay_status' => 1]); // 写 capital_flow、更新 member.balance $this->db->commit(); exit('{"code":"SUCCESS"}');

这样一个事务里完成“查状态 → 改订单 → 写流水 → 改余额”，配合uk_out_trade_no唯一索引，即使两个回调同时进来也能保证只有一条流水。

5.5 H5 页面微信支付没反应：JS-SDK 签名与 H5 支付之分

现象：在微信里打开 H5 页面，点充值按钮没有反应，控制台报invalid signature或者config:fail。

原因：公众号支付用wx.chooseWXPay拉起收银台，调用前必须执行wx.config做 JS-SDK 签名。签名和当前页面的 URL 强相关，页面从列表页跳到支付页，URL 变了，签名就失效。另一个常见原因是公众号后台没有配置“JS 接口安全域名”。

解决：每个页面进入时重新向后端要一次签名，签名使用的 URL 必须取location.href.split('#')[0]，去掉 hash 部分，因为微信签名规则里 URL 不能带#后面的内容：

fetch('/api/wechat/jsconfig?url=' + encodeURIComponent(location.href.split('#')[0])) .then(res => res.json()) .then(res => { wx.config({ debug: false, appId: res.data.appId, timestamp: res.data.timestamp, nonceStr: res.data.nonceStr, signature: res.data.signature, jsApiList: ['chooseWXPay'] }); });

jsApiList里必须包含chooseWXPay，否则wx.chooseWXPay不可用。如果是 Android 微信里点击没反应、iOS 正常，优先看签名 URL 是否带了#，这是最常见的差异。注意此处说的是公众号支付 JSAPI，别和“微信支付 H5 支付”混淆，后者是给外部浏览器用的，不需要 JS-SDK，但需要单独在商户平台开通 H5 支付权限。

6. 上线前先做三次“错账演练”：对账脚本与过期提醒的进阶改造

系统上线前，我有个习惯是故意制造三次错账来验证系统能不能自己发现：第一笔充值订单手动把回调改成重复推送；第二笔把会员余额手工改掉 50 元；第三笔并发核销同一张卡。做完这三件事，对账脚本和幂等逻辑靠不靠谱就全暴露了。

对账脚本是最值得提前做的功能，不需要 UI，跑在命令行就行：

# 每天凌晨 1:30 跑对账，把异常结果写到独立日志 30 1 * * * php /data/www/beauty/cli/reconcile.php >> /data/www/beauty/runtime/reconcile.log 2>&1

脚本核心逻辑就是本章 5.1 节那条 SQL 的包装，把diff <> 0的结果输出成“会员 ID + 手机号 + 差额”，再推送到企业微信群或者写入告警表。每天跑一次，财务对账时直接看日志，而不是翻数据库。我交付时一定会把对账脚本和系统一起交付，告诉甲方“有任何一笔对不上，先跑它”，这样能省掉大量售后沟通。

过期提醒是第二个值得做的改造。H5 页面本身没有主动推送能力，到期提醒最靠谱的落地方式是公众号模板消息：每天早上扫一遍member_card表，把 30 天内到期且状态仍为可用的会员拉出来，通过公众号模板消息发一条“您的面部年卡将于 3 月 1 日到期”。这里要注意，用 H5 的snsapi_base静默授权拿到的 openid，已经足够发送模板消息，不需要额外再引导用户关注公众号。如果源码里“微信端”是 H5 而不是小程序，就不要去折腾小程序订阅消息，公众号模板消息是成本最低的触达通道。

我自己的交付习惯还有一个：把capital_flow表设为只允许程序写入，DBA 和运维都禁止直接改数据，所有余额修正操作必须走“调账单”功能，生成冲正流水。这样即使出错，也能在流水里找到全链路记录。美容院会员系统做得好不好，不跟前端页面美不美观挂钩，只看一件事——钱能不能永远对得上。这一条守住了，系统就立住了。希望帮到你。

本文还有配套的精品资源，点击获取