美容美发门店私域运营：公众号+小程序通用版1.6双端联动方案

简介：新畅美容美发平台公众号小程序通用版1.6是一套面向美容美发行业门店的公众号与小程序双端源码资源包，对应版本1.6.1，适合具备一定开发能力的商家、行业服务商或小程序开发者使用。资源可用于搭建线上展示、预约登记、会员维护等基础服务入口，大幅缩短从零手写代码的周期，也方便在现有骨架上进行二次定制与功能叠加。压缩包整体约46.94MB，以zip格式打包；由于平台暂未提供文件总览，目前无法列出具体文件数量与各类型用途，可先下载解压后查看目录结构，再针对所需模块快速定位。资源已有113人学习关注，作为一款通用版平台，其价值一方面体现在部署效率上，门店只需调整基础配置即可上线；另一方面则为开发者提供了一份完整的微信生态下公众号与小程序联动的参考工程，有助于理解美业SaaS常见的业务模块划分、接口调用思路和页面布局方式。总体而言，这份资源适合希望低成本启动线上运营的小型美容美发机构，以及需要行业基础源码进行外包定制的服务团队。

1. 为什么美容美发门店需要一套「公众号+小程序」通用版1.6

一家社区美发店老板跟我算过一笔账：每个月在各平台买曝光，新客确实进店了，但做完头发就走，手机号、微信都留不下来。想发个活动通知，只能等客人下次路过。这不是个例，美发美容行业的复购高度依赖「人」的触达，而触达的前提是先拥有自己的会员池。新畅美容美发平台公众号小程序通用版1.6，解决的就是这个问题——把公众号的内容触达能力和小程序的交易服务能力串在一起，预约、办卡、买单、会员档案全部在一个体系里闭环。所谓通用版，是说它不针对某一家门店定制，而是把美容美发行业最常见的经营模型抽象好，门店只需要按自己的服务项目、卡项规则去配置参数。适合读这篇的人有两类：一类是有门店、想低成本把私域做起来的老板和运营；另一类是接交付的开发或实施，想找一套能快速上线、少改代码的通用方案。1.6这个版本号意味着它已经过了从0到1的阶段，模块边界收敛，坑也相对清楚了。

2. 公众号+小程序双端架构：触达与交易的职责拆分

2.1 为什么不是只做一个小程序

很多第一次接触新畅通用版1.6的人会问：有小程序就够了，为什么要带公众号？这个问题的答案不在技术上，而在微信生态的产品规则里。小程序适合「用完即走」的服务场景：查预约、核销卡项、买单，用户用完就关，没有订阅关系。而公众号天然承载的是「持续触达」：推文、模板消息、菜单入口，用户关注了才会在服务通知里收到提醒。只做小程序，你每次想发活动都得靠用户主动打开，触达成本很高；只做公众号，交易和预约体验又太重。所以1.6做的是双端分工。

我建议把双端的边界记成一句话：公众号负责把人叫回来，小程序负责把人服务好。用户从公众号菜单进入门店主页，查看服务项目和价格，点击预约时跳转到小程序完成选手艺人、选时段、提交订单；到店后核销、办卡、买单也在小程序内完成；离店后公众号推送服务评价提醒、会员余额变动提醒和下一次的优惠券。这套链路里，公众号是小程序的流量入口和消息出口，小程序是公众号的服务承接层，两个端口共用一套会员数据和卡项数据。

2.2 通用版1.6的功能边界：三个基础对象和六个模块

「通用」不是什么都做，1.6把美容美发行业的业务收敛成了三个基础对象：服务项、手艺人、会员。服务项描述「卖什么」，手艺人描述「谁来做」，会员描述「卖给谁」。所有业务逻辑都是这三个对象的关系组合，这样设计之后，美发店、美容院、美甲美睫店都能用同一套系统配置出适合自己的业务规则。

举个例子：美发店的主力产品是「剪发+染烫」，按单次收费，办卡主要是储值卡；美容院的主力产品是「护理疗程」，按疗程收费，卖的是固定次数的疗程卡；美甲美睫店则更依赖次卡和限期卡。这三种业态在1.6里没有任何代码差异，区别只在于后台参数：服务项怎么设、卡项怎么建、预约需要提前多久、爽约怎么判定。这就是通用版的核心价值——不需要为每一种门店写一套定制逻辑。

1.6的模块可以分成六块：基础配置、预约排班、会员档案、卡项储值、收银结算、营销触达。预约排班要解决的是手艺人时间冲突；会员档案要解决的是跨端身份统一；卡项储值要解决的是次卡、时限卡、储值卡三种计费模型；收银结算要解决的是卡扣、现金、线上支付三种支付方式的混合结算；营销触达要解决的是优惠券发放和消息推送。每个模块都是参数化配置，不是写死的功能。

2.3 什么情况别用通用版：先看清边界再动手

通用版1.6不是万能药，我见过几个项目落地失败，问题不是出在系统上，而是需求超出了通用版的能力边界。第一类是大型连锁，总部、区域、门店三级架构，需要按门店隔离数据、按区域汇总报表，还要做跨店权益，1.6的通用模型基本上只支持到单店或几个店的轻量连锁，多级组织架构撑不住。第二类是业绩提成极其复杂的门店，比如按服务项不同比例、按卡项不同比例、跨店业绩拆分，这类需求往往要改结算逻辑。第三类是需要深度对接财务或供应链系统的，接口不开放的时候，后期维护成本会很高。

如果你的需求属于这三类，我的建议是不要硬上通用版，先用两个半天把需求清单过一遍：哪些是标准功能，哪些是定制逻辑。标准功能占比超过七成，可以选通用版然后预留扩展；如果反过来，定制占大头，不如直接走定制开发。通用版的价值在于「标准功能免费附带、按配置即用」，而不是替你把所有特殊规则都消化掉。

3. 从部署到跑通第一笔预约：通用版1.6的落地三步

3.1 部署环境与初始化安装

新畅通用版1.6是标准的三件套架构：Nginx做Web服务，PHP处理业务逻辑，MySQL存数据。这套组合的好处是部署门槛低，任何一台云主机甚至虚拟机都能跑起来，不需要容器环境。我一般建议的配置是2核4G起步，这个版本的数据量按单店规模设计，会员量在十万级别以内不会有压力；如果后续要多店共用，再考虑升级配置。

部署流程第一步是准备Web目录和运行环境，然后把安装包上传到服务器。以常见的Linux云主机为例：

# 创建站点目录并上传通用版1.6安装包（zip格式） mkdir -p /var/www/xinchang cd /var/www/xinchang # 解压安装包，注意使用unzip命令，若未安装先执行 yum install unzip 或 apt install unzip unzip xinchang_1.6_release.zip # 设置运行目录权限，PHP需要写入缓存和上传目录 chown -R www:www /var/www/xinchang chmod -R 755 /var/www/xinchang chmod -R 777 /var/www/xinchang/runtime chmod -R 777 /var/www/xinchang/uploads

这里的重点是最后三行权限设置。runtime目录是框架的缓存和日志目录，不放开写权限，后台会一直报错；uploads目录是门店图片、会员头像的上传落地位置，权限不够会出现「上传成功但前端不显示」的假象。国内云主机经常用www用户跑Nginx和PHP-FPM，所以chown要把目录归属切到www，这一步漏了，后面所有上传功能都会出问题，用root身份跑PHP又是安全隐患，不建议这么干。

解压完成后，在浏览器访问http://你的域名/install/index.php，进入安装向导。向导会要求填写数据库信息：数据库地址、库名、用户名、密码，以及网站后台管理员账号和初始密码。安装完成后务必删除install目录或改名，否则会有被重复安装的风险。部分环境因为PHP版本问题会白屏，优先检查PHP版本是否在7.2到8.0之间，以及pdo_mysql扩展是否启用。

3.2 公众号与小程序联调：AppID、Secret与合法域名

安装完成只是把系统跑起来，要让公众号和小程序两个端连通，必须在对应的公众平台后台做关联配置。这两个端口的数据能打通，靠的是微信侧的AppID和AppSecret。公众号有一套，小程序有一套，通用版后台里需要同时配置两组凭证。

先在后端管理后台的「支付与对接」菜单里填好两套AppID和AppSecret，再到公众平台后台配置服务器域名。小程序端的合法域名是高频出问题的地方：request合法域名、uploadFile合法域名、downloadFile合法域名，这三项都要填。很多人只配了request域名，结果用户上传头像时直接失败，因为uploadFile的域名没在配置里。

拿到AppID和AppSecret之后，我习惯先写一个小的验证脚本，确认凭证能用，再往下配置：

import requests # 用AppID和AppSecret换取微信接口调用凭证 url = "https://api.weixin.qq.com/cgi-bin/token" params = { "grant_type": "client_credential", "appid": "你的公众号AppID", "secret": "你的公众号AppSecret" } resp = requests.get(url, params=params, timeout=10) data = resp.json() if "access_token" in data: print("凭证有效，access_token前8位:", data["access_token"][:8]) else: print("换取失败，返回信息:", data)

这段脚本的逻辑很简单：微信接口的凭证是通过client_credential方式换取，appid和secret正确后会返回access_token。如果返回errcode和errmsg，90%的情况是AppSecret抄错了，少一位或者多了一个空格；还有一部分情况是公众平台的IP白名单没加当前服务器IP。注意access_token不是永久的，有效期大概两个小时，系统会自己刷新，脚本只是为了验证凭证链路是通的。

配置合法域名时还要注意一个细节：公众号后台的「 JS接口安全域名」和小程序后台的「request合法域名」填的是同一个域名，但公众号要求域名不能带端口。如果服务器用了非80或非443端口，公众号后台的配置会直接校验不通过，所以部署时尽量用标准端口，不要把环境建立在域名:8080这种组合上，否则后面每个功能都要踩一遍跨域和合法域名的坑。

3.3 门店业务参数：服务项、手艺人、预约规则

联调完成之后，系统能跑通，接下来这一步决定了门店用起来顺不顺手：业务参数初始化。我见过不少项目，系统装上后放了两个月没人用，原因就是服务项和排班没配好，前台觉得「系统里的店长和实际值班表对不上」。

服务项是第一个要配的对象。在「门店管理-服务项目」里新建项目，核心参数是：项目名称、服务时长、价格、适用手艺人、提成方式。时长一定要按真实操作时间来填，不要为了看起来效率高填个30分钟，实际染发要两个半小时。预约排班会严格按照服务时长去算可约时段，时长填短了，每单都会超时，后面的预约全部往后积压。提成方式这里，通用版支持按固定金额或按比例两种，选哪种取决于门店现有的薪酬规则，这个参数不影响其他模块，但影响后续收银结算里的成本统计。

手艺人配置的重点是排班。1.6的排班模型是「周模板+临时休班」：门店先定义一周七天里每个手艺人的在岗时段，比如周一到周五10:00-20:00，周六日9:00-21:00；遇到请假或临时调休，单独调整某一天的排班。预约规则参数表如下：

这些参数不是拍脑袋定的，几个关键值跟你门店的服务周期要匹配。提前预约天数建议7天以内，美发行业超过一周的计划大概率会被取消重新约；预约取消时限设2小时，是为了给手艺人留出补位时间，如果设太短，用户临时取消，手艺人那一档时间就空掉了。

3.4 卡项与营销初始化：三种卡模型和自动触达

会员卡是美容美发行业的营收核心，通用版1.6里卡项分成三种模型，这个理解透了，后台配置就不会乱。次卡是「买了12次洗剪吹，用完作废」，适合美甲美睫、基础剪发；时限卡是「季度内不限次或每月固定次数」，适合需要高频到店锁客的场景；储值卡是「储值1000送200，每次消费按原价扣」，适合美发店染烫这类高客单价项目。

三种卡可以同时存在，会员可以既有储值卡又有次卡，收银结算时需要指定本次消费用哪种支付方式。这里有一个容易忽略的参数：是否允许混合支付。如果开启，一笔消费可以部分用卡余额、部分用微信支付，体验更好；如果门店希望优先消耗卡余额，可以把支付顺序设为「余额优先」。卡项的创建界面里，每个卡都要设置有效期、适用项目、是否可转赠、开卡赠送规则。期限卡的有效期设置我个人有个血泪经验：界面上填「3个月」不代表90天，而是自然季度，如果活动从3月15日开始，到6月15日截止，不要按90天去推，直接在后台选「按自然月」最省事。

营销模块里最常用的是「自动发券」和「消息触达」。自动发券可以设置用户注册后领新客券、消费满一定金额后领回馈券、卡到期前7天领续卡券。消息触达则要区分公众号模板消息和小程序订阅消息：公众号模板消息用于支付成功、余额变动、卡项到期；小程序订阅消息用于预约成功、预约提醒。这里的分工逻辑是：涉及钱和服务的消息用一次性订阅，涉及营销的内容走公众号推文或客服消息，不要混用。

4. 通用版1.6上线避坑：五个我踩过的双端配置坑

4.1 会员在公众号和小程序里变成了两条档案

现象：同一个用户，在公众号里预约过一次，再到小程序里办卡，后台出现了两个会员。档案数据不合并，储值余额也看不到。
原因：公众号粉丝的标识openid和小程序用户的openid是不同的值，即使是同一个人。通用版1.6如果没有做unionid绑定，系统会把两端当成两个独立用户。
解决：在公众平台后台把公众号和小程序绑定到同一个微信开放平台账号下，拿到unionid后，在通用版后台的「会员合并」功能里按手机号或unionid去重合并。上线前一定要先做这一步，我见过上线三个月后才发现有两套会员档案，合并起来极其痛苦，那句话怎么说的来着，这属于数据层面的后悔药，越早吃越便宜。

4.2 公众号能支付，小程序支付报错

现象：公众号菜单里打开支付页，微信支付正常；同样的商品在小程序上下单，提示「当前商户号未配置」或「调用支付API异常」。
原因：微信支付商户号需要分别与公众号AppID、小程序AppID建立授权关系。只绑了公众号，小程序端自然调不起支付。通用版后台里商户号只填了一份，很多人以为填了就能同时覆盖两端。
解决：登录微信支付商户平台，在「产品中心-APPID授权管理」里把公众号AppID和小程序AppID都添加进去。然后在通用版后台确认商户号、API密钥、证书路径三项配置无误，重新提交支付证书。这个问题属于配置关联缺失，跟代码无关。

4.3 订阅消息权限用完，预约提醒彻底收不到

现象：用户第一次预约时收到了一次「预约成功」通知，第二次预约后什么消息都没收到，到店才发现预约时间搞错了，投诉前台。
原因：小程序订阅消息是「一次性订阅」，用户授权一次只对应一条消息。如果系统把预约成功、预约提醒、服务完成、评价邀请都用同一个订阅模板消耗，第二次预约时授权已经用完，后续消息全部静默失败。
解决：按消息类型申请不同的模板：预约成功用一条模板，提醒用户「预约成功，请按时到店」；服务开始前2小时的提醒用另一条模板。并在前端预约流程里把「允许发送服务提醒」做成交互勾选，每次预约都重新授权。营销类推送不要走订阅消息，走公众号模板消息或客服消息，被拒收的负面影响小得多。

4.4 公众号里上传的门店图，在小程序端裂图

现象：公众号后台编辑门店介绍时上传的图片，小程序端展示区域空白，但门店自己的手机上看又是好的。
原因：公众号素材URL的域名不在小程序后台的downloadFile合法域名列表里，小程序端下载图片被拦截。这跟服务器无关，是两端域名策略不一致。
解决：把通用版自带的统一存储域名加进小程序后台「开发管理-开发设置-服务器域名」的downloadFile合法域名列表里。如果门店图片是直接传到公众号素材库的，建议统一改用系统里的门店相册功能上传，让图片落地到平台自己的存储上，避免跨域问题。

4.5 小版本升级把自定义模板覆盖了

现象：升级1.6的某个小版本后，门店自己改过的打印小票格式、短信通知文案全部恢复成默认。
原因：通用版迭代时，核心模板文件是整体发布的。如果门店基于底层模板做过修改，升级包会把同名文件覆盖掉，git或备份没做的话直接找不回来。
解决：升级前做两件事：第一，备份整站目录和数据库，异地保存；第二，在后台「模板管理」里把自定义项导出一份。升级后先对比模板文件的修改时间，确认哪些被覆盖了，再手工合并。小版本升级不赶时间，每周挑生意最淡的时段操作，错了还能回滚。

5. 进阶：拿通用版1.6沉淀的数据做复购，才算不白上这套系统

系统上线之后，真正拉开差距的不是谁家功能开得多，而是谁家数据回流用得好。通用版1.6的「数据看板」模块会把预约次数、到店频次、卡项消耗、储值余额汇总成几张表，我建议门店每周固定花十分钟看三个数字：到店频次、沉睡会员数、卡项到期数。到店频次低于一个月一次的会员，后台自动触发一张「回归礼」优惠券，用公众号推文触达，比群发短信效果好一个量级；卡项到期前7天，系统会推送续卡提醒，这里我的经验是不要把「续卡优惠」写得太复杂，直接送额外次数或储值金，转化率最高。

多店场景下的权限边界要提前定：1.6支持建立多个门店，但通用模型的权限粒度是「门店管理员-收银员」两级，跨店的数据汇总和储值通用要谨慎评估。门店A办理的储值卡到门店B能不能用，这个如果上线前没确认，开业当天就会翻车。建议单店起步，连锁扩展放在第二阶段。

版本升级策略也提一句：1.6版本号的迭代节奏不算慢，每次升级前先看更新日志，判断本次改动是否涉及你正在用的模块。不涉及就不升，涉及就必须在业务低峰期执行，先备份、后升级、再验证。我自己吃过亏，升级不加备份，自定义模板被覆盖还得花一天重做，那之后每逢升级必一套完整的备份流程走完，绝不偷懒。这套「公众号触达、小程序承接、数据驱动复购」的模式，对中小美容美发门店是性价比很高的私域起点，希望帮到你。

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