简介新畅美容美发平台公众号小程序v1.8.2是一套面向美容美发行业的小程序与公众号完整源码主要帮助开发者快速搭建服务展示、预约下单、会员管理等业务场景的平台。压缩包为zip格式共3366个文件约49.82MB文件类型以png图片素材、js逻辑脚本、html页面、json配置数据为主另有wxss/wxml小程序样式与结构文件、php后台接口文件等前端、后端与静态资源相对齐备。从内容预览可看出项目已内置常用公共样式与UI组件便于直接复用或二次改造。已有111人学习/下载适合具备一定小程序基础、希望研究美业SaaS或预约系统实现的开发者。通过阅读源码可以掌握小程序分包结构、公众号对接方式以及前后台数据交互思路是一套可运行的实战样例。1. 名字叫「新畅」的这套双端平台v1.8.2 到底解决的是什么美容美发这类到店消费生意和普通电商有一个本质区别用户买的不是一件可以快递发货的商品而是一段时间、一个手艺人和一张预约单。很多门店老板一开始想得很简单注册个公众号、挂个二维码、让顾客扫码加微信就行结果发现公众号只能发文章顾客想查项目、看价格、预约技师还是得打电话或者到店问。这时候就需要一套能把「信息展示」和「交易服务」分开、又能互相导流的双端方案公众号负责内容触达和品牌展示小程序负责预约、买单、储值和会员查询。v1.8.2 这个版本号意味着这套方案已经走过从 0 到 1 的搭建期进入到了反复调业务规则、补边界情况的迭代期。这篇文章不会去复述某个开源项目或某位作者的交付件而是以「新畅美容美发平台」这类双端项目为对象把公众号 小程序从账号体系、预约模型、商城交易到发布审核的完整链路讲清楚。读者对象很明确手里已经有一个小程序商城或预约类源码、想把公众号端一起打通的人或者接了一个美容美发行业定制需求、正在纠结技术选型的开发者。你会从这里看到一套能直接照着做的数据模型、几个关键接口的落地写法以及那些不跑到真机上根本发现不了的坑。2. 先想清楚业务底座美容美发平台的订单模型为什么不能照搬电商2.1 预约、排班、服务项目三个容易在开发中期返工的核心实体很多团队做这类项目第一步就急着搭小程序页面把「项目列表」「技师列表」「立即预约」几个页面画出来然后发现做到一半产品经理说「顾客约了 10 点但技师 10 点有另一个单子」于是才开始补排班逻辑。这个顺序是反的。美容美发平台的业务底座不是商品和 SKU而是「人、时间、服务」三者的匹配关系。我的习惯是先落三个核心实体再谈页面。一是服务项目表。美发和美容的服务项差别很大美发按「剪、烫、染、护」分美容按「清洁、补水、抗衰、身体护理」分但它们的共性都是「时长」。一个基础剪发 30 分钟烫发 90 到 120 分钟美容护理通常 60 分钟起步。所以服务项目表里必须有一个duration_minutes字段这是后面所有排班和预约冲突判断的基础。很多新手把时长写在价格表里当展示字段用不参与计算后面做排班冲突检测时才发现拿不到数据。二是技师表。技师除了姓名、头像、资质还需要一组服务能力标签或者项目 ID 关联表。因为美发店里的托尼老师可能只会剪发和烫发不会染发美容师可能只擅长面部护理。预约时选技师必须能过滤出「会做这个项目」的人否则用户约成功了到店才发现技师做不了。三是预约单主表。我一般会加 Order 和 OrderItem 两层Order 记录「谁、哪个门店、什么时间、哪个技师、总价、状态」OrderItem 记录这次预约里的具体项目明细。为什么拆两层因为美容美发经常出现「一个人约了剪发 护理」两个项目时长不同、价格不同如果只用一个字段存项目名后续做业绩统计和技师提成计算时要拆字符串非常痛苦。2.2 排班与时间槽把「技师一天能接几单」做成定时任务而不是即时计算第二个关键设计是排班和时间槽的生成。美容美发门店有明确的营业时间比如早 10 点到晚 8 点技师不是全天都在有的有轮休。所以排班表 First 需要一张technician_schedule表按天记录每个技师的可用时段。然后系统要在每天凌晨或者营业前根据排班和服务项目时长把当天切成若干个可预约的时间槽。常见做法是写一个定时任务每天早上 6 点生成当天每个技师的时间槽。生成逻辑不复杂从排班的开始时间起按项目时长递增判断是否越过技师的下一个已占用时段。这里的关键参数是「服务间隔缓冲」我一般会在门店配置表里加一个buffer_minutes默认 10 分钟。因为美发项目经常有吹干、造型的收尾时间技师的实际占用时间比项目时长要多出几分钟如果没有缓冲连续预约会把技师逼得非常赶到店体验会明显变差。拿一个具体例子来说技师上午 10 点到 12 点排班剪发项目时长 30 分钟缓冲 10 分钟那么时间槽就是 10:00-10:40、10:40-11:2011:20-12:00 不足 40 分钟自动舍弃。这样用户在小程序里看到的时间就是已经处理好冲突的可用时间而不是让用户选了个时间、提交后才告知冲突。用户端体验差异非常大前者是「能选就能约」后者是「选完告诉你不行」这个细节直接决定预约转化率。2.3 会员储值和次卡营销玩法背后的资金流水设计美容美发行业的预付卡比例很高储值赠送、次卡、套餐卡基本是每家店营收的大头。这套系统的数据模型里储值和次卡要单独建表不能简单地在用户表上加一个balance字段。因为储值涉及赠送金额的核销规则、退款时的赠送扣回、不同门店的通用性字段一旦不够用后面财务对账就是灾难。我的建议是四张表会员卡主表卡号、用户 ID、开卡门店、卡类型、储值流水表每笔充值、赠送、消费、退款、次卡商品表比如「10 次剪发卡」「5 次深层清洁卡」、次卡核销表每次消费扣减哪个次卡的哪一次。特别注意两个边界一是充值赠送的金额退款时如果退到现金赠送部分要不要扣回这个规则最好在做之前就由门店确认不要开发完再补二是次卡的有效期有的是「从开卡日起 12 个月」有的是「从第一次使用起 12 个月」虽然只是字段差异但核销逻辑完全不同。这些业务底座设计好再回头看公众号和小程序它们只是「用户触达的入口」和「业务系统的前端」。如果一开始就把注意力放在前端页面上后端模型多半会返工。这也是为什么我每次接手这类项目第一周只做数据模型和接口设计评审不做页面。3. 公众号 小程序双端账号体系从 openid 到 UnionID 的身份打通3.1 为什么同一用户在两端的 openid 不同以及 UnionID 的获取前提公众号和小程序虽然都在微信生态里但它们分属两个不同的应用同一个微信用户在不同应用里的openid是不同的。这带来一个直接问题如果用户先在公众号里点菜单进入商城页面用微信授权登录产生了一笔订单后来又在微信里搜索小程序进来核销储值卡系统就会看到两个「不同用户」会员余额对不上。解决这个问题的标准方案是 UnionID 机制。用户在同一微信开放平台账号下的不同应用公众号、小程序、网站应用等如果都绑定了同一个开放平台账号那么它们拿到的unionid是唯一的。实现前提有两个一是公众号和小程序都必须绑定到同一个微信开放平台账号下这一步需要开放平台认证费用一年 300 元左右很多人做到一半发现 unionid 拿不了回头才知道这个前提二是要在两端都先获取到用户的unionid才能串起来如果开发早期只存了 openid 没存 unionid老用户数据需要做一次清洗合并很痛苦。所以在设计 user 表时一定要把unionid、mp_openid公众号、mini_openid小程序三个字段都建好而且都要加索引。用户第一次通过任何一端进来先查 unionid 是否存在如果不存在说明这个微信号还没在另一个端授权过直接创建新用户。如果存在就把当前端的 openid 补充到现有用户记录上。这个合并逻辑放在登录接口里统一处理双端共用一份用户数据。3.2 微信小程序登录获取手机号从 button 到 code 换手机号的前后端配合小程序端获取用户手机号是这类平台的高频刚需。因为预约和到店核销都需要手机号联系用户而且小程序端拿手机号比让用户手输的转化率要高得多。但现在微信对手机号快速验证组件有严格限制必须通过button open-typegetPhoneNumber让用户主动点击触发不能页面一加载就静默弹窗。而且这个组件只有认证主体的小程序才有权限使用个人主体小程序无权调用需要在开发者工具里检查「用户信息接口」权限是否已开通。前后端配合的流程是用户点击按钮后前端在回调里拿到code注意不是手机号本身把code传给后端后端调用微信接口POST https://api.weixin.qq.com/wxa/business/getuserphonenumber?access_tokenACCESS_TOKENbody 里带{ code: ... }换取手机号信息。这里的access_token需要通过小程序的 appid 和 secret 调用GET https://api.weixin.qq.com/cgi-bin/token获取一般会缓存 7000 秒而不是等它 7200 秒过期才刷新。# Flask 示例通过 wx code 换取手机号 import requests import time from flask import request, jsonify # 全局或 Redis 缓存 access_token token_cache {token: None, expires_at: 0} def get_access_token(appid, secret): now time.time() if token_cache[token] and token_cache[expires_at] now 200: return token_cache[token] url https://api.weixin.qq.com/cgi-bin/token params {grant_type: client_credential, appid: appid, secret: secret} resp requests.get(url, paramsparams).json() token_cache[token] resp[access_token] # 提前 200 秒过期避免临界时间点失败 token_cache[expires_at] now resp[expires_in] - 200 return token_cache[token] app.route(/api/wx/phone, methods[POST]) def wx_phone(): data request.get_json() code data.get(code) token get_access_token(your_appid, your_secret) resp requests.post( https://api.weixin.qq.com/wxa/business/getuserphonenumber, params{access_token: token}, json{code: code}, timeout5, ).json() if resp.get(errcode, 0) ! 0: return jsonify({code: 1, msg: 获取手机号失败: %s % resp}) phone_info resp[phone_info] return jsonify({code: 0, phone: phone_info.get(purePhoneNumber, )})这段代码里的关键点是access_token的过期时间处理。微信接口返回的expires_in是 7200 秒但实际网络请求耗时和系统时钟偏差会让 token 提前失效所以我习惯在 7200 秒基础上减掉 200 秒作为提前刷新阈值。另外code只能用一次5 分钟内有效前端如果拿到 code 后网络请求失败重试需要让用户重新点按钮获取新的 code后端不应该尝试用同一个 code 调两次接口。3.3 公众号网页授权的静默与非静默菜单入口和分享页面的登录差异公众号端的情况比小程序更微妙。用户在公众号里打开的不是小程序页面而是绑定在公众号自定义菜单里的 H5 网页常见方案是使用微信内置浏览器打开。公众号网页授权分两种静默授权snsapi_base只能拿到 openid非静默授权snsapi_userinfo需要用户点确认能拿到昵称和头像。在这个双端架构里我一般会区分两个入口从公众号菜单进来的用户很多是门店的老顾客他们可能不太愿意每次进来都点一次授权所以走静默授权拿 openid然后查数据库里有没有这个用户如果数据库里已经有 unionid 和手机号就直接登录。用户从分享链接或朋友圈海报进来时才是需要snsapi_userinfo的场合因为这种场景往往是「新客领优惠」或「老客带新客」你有充分的理由让用户点一下授权换取头像昵称和手机号。很多新手容易踩的一个坑是把snsapi_userinfo的授权弹窗放在所有公众号入口上导致老用户每次点菜单都要多点一步流失率非常明显。正确做法是服务号如果要推进「个性化订阅消息」必须拿到用户手动授权但如果只是查会员等级和余额静默授权已经足够了。选哪个 scope要以「这次打开页面到底需不需要用户身份信息」为准而不是统一用一个。4. 把预约和商城装进两个入口页面维度、接口与公众号 H5 的深浅关系4.1 小程序页面维度从「项目列表-技师-时间-确认」到订阅消息提醒新畅这类平台的小程序端核心页面一般集中在 5 个维度首页展示热门项目和门店动态、项目列表按分类筛选、技师列表展示排班和评价、预约确认页选时间、选技师、确认会员优惠和个人中心订单、储值卡、次卡。这里最容易被忽视的是预约确认页的「取消条件」设计——美容美发行业的爽约率很高有的门店要求客户提前 2 小时才能免费取消否则要扣储值余额这个规则必须在前端有明确提示、在后端有校验不能只在前端做一个时间判断就完事。预约成功后的小程序订阅消息提醒是用户履约率最高的触达方式。需要注意微信订阅消息的授权策略是「一次授权一次发送」用户点预约提交时弹窗让用户勾选「预约成功通知」「预约提醒」「消费完成通知」三件事但用户可能只勾了一条或两条所以后端要根据用户实际授权的情况决定发送哪条消息。我的做法是在订阅消息授权回调里记录每个模板 ID 的授权状态到 user_subscription 表预约创建时先查这张表能发就发不能发就退回公众号模板消息或者短信兜底绝不在用户未授权时硬调接口否则会触发微信的接口报错限流。4.2 公众号 H5 与小程序的分工公众号做运营小程序做交易公众号端的页面跟小程序不是「同一套页面改个壳」而是根据场景做了分工。公众号承担三个任务品牌文章推送、活动海报页、商城 H5 页面。这里商城 H5 是典型的「轻量应用」——微信内置浏览器打开一套 Vue3 或 React 的单页应用页面结构比小程序简化很多通常只有项目浏览、下单、支付和订单查询这几个功能。因为公众号菜单页的入口价值在于把粉丝转化为客户不在把所有功能都做一遍。两个端共用的是后端 API 和数据库。前端项目拆成两个仓库或两个构建目标小程序用原生或 uniapp公众号 H5 用 Vue3。这里有一个比较关键的技术细节两端的接口鉴权方式要统一。我的方案是统一用 token 机制——小程序静默登录后拿 token公众号 H5 静默授权后拿同一个 token两个端由一个统一的 auth 中间件校验身份。否则容易出现「小程序订单在 H5 里看不到」的串号问题。4.3 小程序动态设置标题onLoad 里根据页面参数改 navigationBarTitle有一个高频需求是「不同门店进入同一个页面时标题显示不同门店名」或者「从项目分类进入列表页标题显示分类名」。微信小程序提供了wx.setNavigationBarTitle接口可以在页面运行时改标题。// 项目列表页根据 URL 参数动态设置标题 Page({ onLoad(options) { const categoryName decodeURIComponent(options.name || 全部项目) wx.setNavigationBarTitle({ title: categoryName }) this.setData({ categoryId: options.id || }) this.fetchProjects(options.id) }, })这个接口是即调即生效的不需要在 app.json 里预设所有标题。但要注意一个体验细节页面首次加载时如果标题是空的或默认值再 setNavigationBarTitle 会有一次短暂闪烁所以我会把每个页面的navigationBarTitleText先在 app.json 里设置一个通用默认值比如「新畅美业」然后在 onLoad 里改具体标题。另外分享出去的卡片标题是独立字段用onShareAppMessage里的title控制不要指望setNavigationBarTitle能影响分享卡片标题这是两个完全独立的配置。4.4 报名和优惠券的接口设计并发场景下的超卖问题商城模块里最容易出问题的不是支付是优惠券和限量活动的并发扣减。比如门店周年庆发 100 张五折券用户同时抢如果用先查库存再 insert 的方式很容易超发。常见做法是数据库层面的原子扣减UPDATE coupon_stock SET remaining remaining - 1 WHERE coupon_id ? AND remaining 0利用数据库的行锁保证不会扣成负数。对于优惠券领取用户表里加唯一索引user_id, coupon_id防止同一用户重复领同一张券。预约业务的并发冲突也类似两个用户同时选了同一个技师的同一个时间槽不能靠前端判断「这个时间可用」就认为预约成功。后端要把「占用时间槽」写成事务——在事务里先对技师当天的排班记录行加锁再检查目标时间是否冲突再创建订单提交事务。很多开发者用单独的 Redis 锁来实现但 Redis 锁在极端情况下的过期问题很玄学数据库行锁反而更可靠因为数据量没大到需要引入 Redis 做分布式锁的程度。这里给一个参考判断单店每日订单不过几百单数据库行锁完全扛得住连锁几十家店的时候再说 Redis 的事。5. 发布前必读类目审核、订阅消息授权与公众号链接归属的典型坑5.1 「链接内容不属于当前公众号」公众号菜单跳转外部地址的校验逻辑做公众号 H5 菜单跳转时遇到最多的报错就是「链接内容不属于当前公众号」。这个问题的本质是微信公众号平台对菜单 URL 有域名白名单校验公众号后台配置的「网页授权域名」和「JS 接口安全域名」必须是已备案且通过校验的域名而且网页授权回调域名要与菜单 URL 同域名。很多团队用多个二级域名拆分环境——api.hair.com、m.hair.com、admin.hair.com结果菜单 URL 配了 m.hair.com网页授权域名只配了 api.hair.com打开菜单直接报错。解决办法是所有公众号相关域名保持一致建议只用一个域名hair.com的二级m作为 H5 入口授权回调也指向它。开发环境和测试环境不要用完整的公众号配置调试微信不允许不同域名混用。另外在本地开发调试 H5 时很多人直接改 hosts 把线上域名指向本机但因为本地没有备案域名的 HTTPS 证书或者证书域名不匹配微信内置浏览器会直接拦截这一块非常容易浪费一整个下午。5.2 小程序类目审核美容美发服务类目和所需资质小程序审核是对项目上线时间影响最大的外部因素。美容美发平台的类目一般归到「生活服务 丽人 美发/美容」下需要提交营业执照且执照经营范围要包含相关服务。很多个体户的执照经营范围写的是「美容美发服务」这没问题但如果写的是「日用品销售」审核会直接打回。另一个隐患是「美发小店」小程序的类目里包含「化妆品销售」时可能需要额外提供《化妆品经营备案凭证》或进货凭证。我的建议是最开始提交审核时不要为了功能完整把所有类目都加上先按核心业务选主营类目审核通过后需要再补充。如果提前加了非必需的敏感类目增加了资质要求做不了反而耽误全盘进度。5.3 订阅消息授权被拒与「长期订阅」的权限边界很多开发者容易混淆「一次性订阅消息」和「长期订阅消息」。美容美发平台的预约提醒场景微信目前开放的基本是一次性订阅用户授权一次你就只能给他发一条。想让用户每次预约都填写「同意接收提醒」体验负担是很大的。这里我建议不要硬做改用灰度思路用户第一次预约时弹订阅授权如果用户拒绝了订阅后端在预约创建后自动走公众号模板消息或短信通知短信需要接入第三方短信服务成本在每条 0.03-0.05 元左右但履约率提升带来的收益远比短信成本高。有些团队尝试用「订阅消息 模版消息」双通道都做结果因为公众号模板消息也在调整权限规则导致代码里两套逻辑互相打架得不偿失。先确保至少一条通知通道可用再优化通道成本这是这类平台的上线节奏。5.4 小程序「转发给朋友」失效页面 onShareAppMessage 配置漏了参数很多店铺活动需要用户把小程序分享给朋友或朋友圈但线上测试时发现分享出去的卡片打开是空白页面。常见原因有两个一是页面没有实现onShareAppMessage生命周期函数微信默认分享当前路径但没有携带必要参数导致对方打开后查不到数据二是分享路径里的参数超过了options能解析的简单字符串比如带中文没有编码。解决办法是手动构造分享路径把门店 ID、活动 ID 和来源渠道都拼进去并用encodeURIComponent处理中文参数。另外某些门店促销页为了「防刷」会在页面 onLoad 里做登录判断用户未登录时跳转登录页导致分享卡片被打开后直接跳出登录页。这里的正确做法是让分享落地页在未登录时也能够展示活动概览登录后再展示用户专属优惠而不是直接拦截否则分享的转化率会低到怀疑人生。5.5 支付回调延迟与掉单对账任务设计最后是支付的掉单问题。用户在小程序里支付成功但门店后台没看到订单这种投诉非常影响口碑。微信支付的回调是异步通知偶尔会有延迟甚至丢失。我的处理方法是在订单表里加一个pay_status字段0 未支付、1 已支付、2 已退款再写一个定时对账任务每小时拉取一次微信支付接口里当天未终态的订单比对订单表的支付状态。这个方案比「等回调再更新」要稳得多。定时任务里注意只查当天的订单不要查全表因为微信支付接口有查询频率限制。如果对账发现「微信侧已支付、订单表未支付」先不要急着退钱要先把微信侧订单立起来再更新本地订单状态最后做财务入账——顺序不能反否则会出现「钱已扣订单不存在」的极端案例。6. v1.8.2 迭代复盘版本演进顺序与遗留问题清单如果我现在拿到一个新项目「新畅美容美发平台公众号小程序」我做的第一件事不是看代码而是看版本号v1.8.2 说明项目已经历过好几轮功能迭代和发布这种版本的项目最怕的不是缺功能而是补丁叠太多业务逻辑分散在各个页面和接口里改一个变量影响面不可控。我在迭代这类项目时有一个固定习惯先做接口清单和数据结构映射把「前端页面依赖哪些接口、接口依赖哪些表」画成一张依赖脑图每次改动前先看影响范围。发布顺序上我会先发小程序端再发公众号 H5因为小程序审核周期通常比 H5 长先提交审核可以并行等审核结果H5 页面随时可以灰度上线。基础设施层面优先确保三件事统一登录状态 token 字段规范、订单 pay_status 与微信侧状态机的对应关系文档、消息通知通道的状态记录表。这三件事如果做好了后续加任何新功能都有底。另一个实践是「发布失败」的快速回滚预案。微信小程序发布有版本管理功能线上版本出问题可以快速切到上一个版本公众号 H5 则要保证每次发版都是可回滚的静态资源用 OSS 上的版本时间戳目录存放nginx 层做版本切换而不是直接覆盖 index.html。这个方法非常老派但极其可靠尤其是在周五下午发版这种场景有后悔药和没有后悔药是完全不同的心态。如果按这个节奏走v1.8.2 到 v1.9 之间的迭代方向我会优先做消息通知的通道降级策略订阅消息不足时短信补位、门店维度的数据看板到店转化率、项目销售排行、技师业绩、以及用户画像标签与公众号文章的个性化推送配合。这三件事方向不同但都是基于现有业务数据的增值不改变核心链路风险低价值高。最后说一句个人体会双端项目最贵的成本不是开发是「两端逻辑不一致」造成的数据错乱和口碑损失每次改业务规则先问一句「公众号和 H5 两端都同步了吗」能省掉非常多半夜处理的线上事故。希望帮到你。本文还有配套的精品资源点击获取