简介：这是一套完整的Java美容行业SaaS管理系统源码，面向中小型美容连锁门店、IT开发者及Java全栈学习者，解决线上预约、多端协同、支付集成与门店服务管理等核心业务场景。系统采用IMS框架构建，划分为后台管理端（EasyUI实现）、商家运营端（基于EasyUI美化主题）和微信H5端（AUI框架+微信JSSDK），支持服务号关注、项目预约、门店消费、地图定位、模板消息推送、阿里大于短信及威富通聚合支付（含微信/支付宝扫码、扫描枪、H5支付）。压缩包共2000个文件，涵盖253个Java业务逻辑类、196个JSP页面、723个JS交互脚本、360个CSS样式文件、421个配置与说明文本，以及大量图片、字体与第三方依赖资源，整体85.05MB。已有301人下载学习，结构清晰、模块解耦，附带完整支付与微信生态集成实践，是理解企业级Java Web多端协同开发的优质参考案例。 你先从一个看起来平平无奇的zip压缩包开始，这套Java美容管理系统源码就装在里面。网上这种"多端源码"的zip包少说也有几百个，但真正能下载下来、解压开、跑起来、还敢往自己项目里抄的，其实不多。它的核心价值不在于代码量有多少，而是市面上带完整后台管理端、商家端、微信端三端联动的Java项目源码，往往要么挂在付费资源站里，要么故意抽掉核心模块。这个zip如果三个端齐全、数据库脚本完整，那它本身就是一套很适合拿来练手、做毕设，甚至是直接做二次开发起点的骨架项目。
我这篇文章不打算给你逐行念代码，那种事你自己打开IDEA就能干。我更想聊聊拿到这种源码包之后，从解压到启动，再从调通到改造，整条路上最容易卡住的地方，以及为什么很多人在第一步"解压"就放弃了。
1. 源码包到手，先别急着解压：文件校验与目录结构
1.1 为什么zip包总是解压失败——"invalid zip archive"的根因
很多人下载完这种源码包，双击解压，然后WinRAR或者系统自带解压工具直接甩出来一句：
file is not a zip file或者更具体一点的：
invalid zip archive: could not find EOCDEOCD这个缩写全称是End of Central Directory Record，翻译过来就是"中央目录记录结尾"。你不需要把它背下来，你只需要理解它是什么——zip文件的末尾会有一段元数据，记录着这个压缩包总共有多少个文件、每个文件的偏移量、压缩方式等等。解压工具是靠这段元数据来定位和还原每个文件的。如果这段数据缺失或者损坏，解压工具就会认为这个文件根本不是合法的zip。
出现这个报错，绝大多数情况下不是你的解压工具不行，而是文件下载不完整。尤其是从百度网盘、某些下载站、论坛附件方式下载的资源，HTTP断点续传做得不好，或者浏览器下载过程中网络抖动，就会导致文件后半部分丢失。而zip的EOCD恰恰在最末尾，所以它是最先被截断的部分。
我的建议是，拿到任何zip源码包，先看一眼文件大小。比如标题写着完整源码，压缩包却只有几MB，那大概率是文本文件被压缩的极限了，源码包通常至少在20MB以上；如果页面标注的是50MB，你下载下来只有30MB，那基本不用尝试解压了，直接重新下载。重新下载的时候尽量用支持断点续传的下载工具，比如IDM、Motrix，浏览器自带下载器在大文件场景下真的不靠谱。
另外还有一种情况，文件大小完全正常，但解压到一半报"文件头损坏"，或者某几个Java文件解压出来是乱码。这种一般是压缩包在传输过程中出现了二进制级别的错位。你可以先用7-Zip打开看看，7-Zip的容错能力比WinRAR强不少；如果7-Zip能打开但提取报错，再试试命令行修复：
zip -FF damaged.zip --out repaired.zip这个命令会把损坏的压缩包尝试修复，重建一份新的zip文件。对于仅仅是EOCD缺失、但前面文件数据还完整的包，修复成功率挺高的。
1.2 中文文件名乱码：Windows压缩的包在Linux上解压的坑
如果你是把zip包传到Linux服务器上解压，那还有一个经典的坑——中文文件名乱码。Windows上压缩文件时，中文文件名默认是GBK编码，而Linux的unzip默认按UTF-8解压，结果就是解压出来的目录和文件名全部变成乱码。
����ϵͳ这类乱码虽然不影响代码内容，但会直接影响后续的路径引用，比如linux下找不到resources目录、脚本执行路径不对。解决办法是用指定编码的方式解压：
unzip -O CP936 beautysys.zip如果你用的是较新版本的unzip，可能没有-O参数，这时候可以用Python的zipfile模块或者安装p7zip后用7z解压。7z对编码的自动识别做得更好，在运维环境不确定的情况下，我一般在Linux上装一下p7zip再解压源码包。
1.3 一个合格的Java美容管理系统源码目录长什么样
解压完之后，先别急着用IDEA打开，先在文件管理器里过一遍目录结构。一套结构清晰的三端Java项目，通常长这样：
├── beautysys-admin // 后台管理端 ├── beautysys-merchant // 商家端 ├── beautysys-wxapi // 微信端接口 ├── beautysys-common // 公共模块 ├── beautysys-framework // 框架配置 ├── sql // 数据库脚本 ├── docs // 文档 └── pom.xml // 父级Maven配置如果你看到是这样的结构，那说明这个源码包质量还不错，至少用了Maven多模块管理。Module之间的依赖关系通常是admin依赖framework，merchant依赖common，wxapi也依赖common，而framework又依赖common。这种分层很典型，后台、商家端、微信端三端共用一个业务核心，只是暴露的Controller不同、权限边界不同。
如果解压出来是一个巨大的单模块工程，所有代码堆在src/main/java里，三个端靠包名区分，那代码质量就要打一个问号了。不是说不能跑，而是后续你改A端的时候很容易碰坏B端，代码耦合度太高。后面要做二次开发的话，我建议优先考虑那些多模块结构的版本。
还有一件事，打开源码包后第一时间找sql文件夹，确认有没有完整的.sql脚本。商城类、美容类管理系统如果没有数据库脚本，那你拿到的基本是个半成品，后面所有功能都要自己建表，工作量大到足以让你放弃。我这个zip包里有SQL脚本，这算是最大的加分项。
2. 环境准备要点：JDK版本、Maven私服和MySQL导入的坑
2.1 JDK版本和编译级别：Spring Boot版本决定一切
很多人在导入项目时选的JDK版本不对，一打开pom.xml就是一堆红色报错。实际上你首先要看的是Spring Boot的版本，再看Java版本要求。
- Spring Boot 2.x，比如2.3.x、2.5.x，对应JDK 8或JDK 11
- Spring Boot 3.x，对应JDK 17及以上
美容管理系统这种实战型项目，绝大多数基于Spring Boot 2.x，对应JDK 8。因为JDK 8在中小型企业里依然是绝对主流，很多服务器上跑的还是JDK 8。但你本机如果装的是JDK 17，项目也能编译，只要pom.xml里<java.version>改成17或者兼容版本就行。不过我不建议你上来就改版本，尽量先用项目原本配好的JDK版本跑，跑通了再考虑升级。
验证JDK环境的时候，记住不要只看java -version，还要看javac -version。只装了JRE没装JDK的情况下，java能跑但javac不存在，Maven编译必然失败。Windows上配置JAVA_HOME，最容易犯的几个错：
JAVA_HOME=C:\Program Files\Java\jdk1.8.0_291\ ← 多了反斜杠这个反斜杠有时候会在某些工具解析路径时出问题，更安全的写法是不带末尾反斜杠。
然后Path变量里追加%JAVA_HOME%\bin。有些教程还让你配CLASS_PATH，但现在的JDK版本已经不需要了，配了反而可能在特殊场景下引入莫名的冲突。配置完环境变量，务必新开一个终端窗口验证，因为环境变量只在终端启动时读取一次，已经在旧窗口里跑的命令行是不会刷新环境变量的。
2.2 Maven依赖下载不下来的问题：配置国内镜像
Java项目用Maven管理依赖是常态，但很多人的Maven本地仓库里什么依赖都没有，第一次mvn clean install的时候要从中央仓库下载，那个速度在国内环境下能让你怀疑人生。更离谱的是，spring-beans、spring-core这些基础依赖下到一半突然连接超时，整个构建失败。
解决办法很简单，在Maven的settings.xml里配置阿里云镜像:
<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>我在实际使用中，还会把mirrorOf配置成*，这样不管项目里配了什么私服地址，统统走阿里云镜像，速度有保障。不过如果你的项目里有自定义私服依赖（比如公司内部封装的jar），那就不能这么干了，mirrorOf还是得写central。
还有一个常见问题：IDEA里打开项目后，右侧Maven面板总是报某个依赖Cannot resolve ...。排查步骤我建议这样走一遍：
- 确认
settings.xml里配置的镜像URL能正常访问 - 看本地仓库路径下有没有对应依赖的
lastUpdated后缀文件，有就说明上次下载失败了，手动删掉 - 在IDEA里执行
mvn clean compile，观察到底卡在哪个依赖上
依赖下载失败这种问题，很多时候不是网络问题，而是本地的.lastUpdated文件缓存了失败状态，Maven默认在24小时内不会重新下载。删除整个_remote.repositories和lastUpdated文件，再reimport一次，基本能解决。
2.3 MySQL导入：编码和版本一个都不能少
SQL脚本导入之前，先看清楚脚本是给MySQL哪个版本准备的。如果脚本里有engine=InnoDB default charset=utf8mb4，那你本机尽量用MySQL 5.7以上或者MySQL 8.0。MySQL 8.0和5.7在驱动上也有区别，com.mysql.jdbc.Driver已经废弃了，新版本要用com.mysql.cj.jdbc.Driver，连接串上最好加上时区参数：
jdbc:mysql://localhost:3306/beauty?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/ShanghaiserverTimezone这个参数如果你不加，MySQL 8.0会报时区相关的错误，项目直接启动失败。这个错误非常常见，很多新手死在这一步，其实就是一个参数的问题。
导入SQL脚本，我喜欢用命令行，比可视化工具更稳妥：
mysql -u root -p source /root/beautysys.sql如果脚本文件很大，用mysql -u root -p database_name < script.sql这种重定向方式导入即可。导入完成后，进MySQL里执行show tables;看一眼，确认核心表都在，比如sys_user、sys_role、member、shop、appointment、order之类。表结构完整了再进下一步，否则你后面启动永远会卡在某个表找不到的报错上。
3. 后台、商家端、微信端：三端功能边界与技术栈拆解
3.1 后台管理端：典型的RBAC权限管理框架
这套系统的后台管理端，服务对象是平台运营方，也就是美容连锁总部的管理员。它管的不是某一个店铺的日常，而是整个平台的商家入驻审核、会员数据、订单流水、项目分类、营销活动配置、系统用户和权限分配。
你打开代码会发现，后台端基本都是经典的RBAC模型，五张核心表：
sys_user 用户表 sys_role 角色表 sys_menu 菜单权限表 sys_user_role 用户角色关联表 sys_role_menu 角色菜单关联表登录后根据用户ID查出角色，再根据角色查出所有可访问的菜单和按钮权限。前端路由根据后端返回的菜单列表动态生成，你没有权限的模块，连入口都不显示。这套机制在若依、芋道源码这些开源框架里已经非常成熟了，这套美容系统如果也是这种实现，那基本可以确定它基于类似架构改造而来。
后台管理端常见技术栈有两种：一种是传统的Thymeleaf服务端渲染，所有页面由Java负责输出，部署简单但前后端耦合严重；另一种是前后端分离，Vue+ElementUI负责页面，后端只提供JSON接口。我个人更推荐后者，因为后续商家端、微信端能复用同一套后端接口，改动更少。你拿到源码时看一眼后台端的resources下有没有templates目录，有就是前者，纯前后端分离的话会有一个独立的前端工程。
3.2 商家端：业务闭环里的关键执行层
商家端在美容管理系统里的定位，是给美容院门店老板或店长用的。它跟平台后台的视角不一样：平台后台看的是全局，商家端只看自己这个店。
商家端功能上通常包含：
- 门店信息维护（地址、电话、营业时间、门店照片）
- 美容师管理（技师列表、排班、服务项目绑定）
- 预约管理（查看本店的预约单、确认或取消预约）
- 会员管理（查看在本店消费过的会员、会员卡余额）
- 团购/套餐核销（用户在微信端买了套餐，到店出示核销码）
- 经营数据（本店今日营收、订单量、客单价）
这套系统里的商家端，如果是一个独立的Web工程，那通常也是Vue+ElementUI或微信H5的形态。如果商家端只是后台端里的一个子模块，那权限控制上会弱一些，但代码量会少很多，对学习来说反而更友好。
要注意的是，商家端和后台端的数据隔离。商家端的查询全部要带上当前登录商家的shop_id，不然一个商家就能看到全平台的数据，这属于越权漏洞。你可以在代码里搜索shop_id字段，看看查询条件里是不是都有它。如果这个做得好，说明源码工程质量不错，可以放心用。
3.3 微信端：C端用户的主要入口
微信端是整个系统离用户最近的一层，消费者在微信里搜小程序、看项目、预约、买单、查会员卡，全部走这里。
技术层面，微信端通常分两部分：
- 微信小程序前端（原生小程序或者uni-app）
- 后端专门给小程序提供接口的模块，也就是
wxapi模块
登录流程是这套系统里最值得研究的点。小程序的登录跟网页登录完全不是一回事：
wx.login获取code → 小程序把code发给后端 → 后端拿着code + appid + secret请求微信接口 → 换取openid和session_key → 后端生成自己的token返回给小程序 → 小程序后续请求都带这个token这里有两个容易踩坑的地方。第一，appid和secret要用你自己注册的小程序账号的，源码包里带的那个是作者的，你用不了。第二，微信接口返回的session_key是用来解密手机号、用户敏感信息的密钥，绝对不能返回到前端，也不能写进日志，否则会有安全问题。
微信支付部分，美容系统里最常见的是充值、买单、购买套餐。支付的回调地址必须是HTTPS的正式域名，本地开发时微信的支付回调到不了你的电脑，所以联调支付时一般用内网穿透工具或者直接改代码跳过支付步骤，只验证订单状态流转。
3.4 三端的启动顺序和数据流关系
我第一次跑通这个项目的时候，犯过一个低级错误：一次性把三个端全部启动，结果后台端和微信端都在用8080端口，直接冲突。后来总结出的正确启动顺序是：
- 先启动MySQL，确认数据库表完整
- 启动Redis（如果项目里用到了缓存或验证码存储）
- 启动后台管理端，确认平台登录页能打开
- 启动商家端，确认商家账号能登录
- 最后启动微信端接口模块，配合微信开发者工具调试小程序
数据流方向是单向的，微信端用户产生的预约单、订单，由商家端接收和处理，后台管理端则汇总所有商家和用户的数据做平台级管理。所以你先启动后台端不会影响商家端的调试，但商家端某些报表数据如果依赖微信端的真实订单，那就要等有数据流入后才有内容可看。
4. 跑通三端联调：端口、跨域、微信登录态与文件上传
4.1 端口规划：三端各占一个端口，别打架
三端跑的虽然是同一个Spring Boot框架，但为了在本地同时运行，必须给各自指定不同的端口。常见的分配方式：
| 模块 | 默认端口 | 说明 |
|---|---|---|
| 后台管理端 | 8080 | 平台管理员入口 |
| 商家端 | 8081 | 商家登录入口 |
| 微信端 | 8082 | 小程序接口 |
这个端口配置在各自的application.yml里，server.port属性。如果你启动的时候发现端口被占用了，先查一下是谁占的：
Windows下：
netstat -ano | findstr 8080 taskkill /f /pid 12345Linux下：
netstat -tunlp | grep 8080 kill -9 12345还有一个细节：如果三个端启动时打印的日志里，端口下方还带context-path，比如/api，那访问地址就要变成http://localhost:8080/api，前端对接的时候也要拼上这个前缀。很多人在前后端对接时接口404，就是因为没注意context-path。
4.2 跨域：微信端接口被小程序拦截的解决办法
网页端访问后端接口有跨域限制，小程序其实也有，尽管小程序的跨域模型跟浏览器不完全一样，但处理方式类似。小程序里请求http://localhost:8082/api/xxx，如果后端没做跨域配置，会报"url not in domain list"或者请求直接被拦截。
后端解决跨域，最推荐的做法是单独写一个配置类，实现WebMvcConfigurer接口的addCorsMappings方法，统一配置允许的来源、请求头和请求方法：
@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }我不是很建议在每个Controller上单独加@CrossOrigin注解，那样代码太分散，后期维护容易漏。全局配置一次搞定，哪个端都能用。
4.3 微信登录态：token的设计与鉴权拦截器
微信端的最核心问题，就是怎么让后端认识"当前请求来自哪个微信用户"。由于HTTP是无状态的，每次请求都要带上一个身份凭证，这个凭证就是登录成功后后端下发的token。
在这套源码里，token通常放在请求头里，名字可能是Authorization、token或X-Token。后端用拦截器加HandlerInterceptor实现统一的解析逻辑：
@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (StringUtils.isBlank(token)) { // 返回未登录错误 return false; } // 解析token，获取userId，写入ThreadLocal或request attribute return true; }重点来了：解析出的用户信息，应放在ThreadLocal里，方便后续在Service层直接获取当前登录用户ID。但你没用完就一定要记得移除，不然线程池复用线程时，下一个请求会拿到上一个请求的用户信息，这是非常典型的内存泄漏和越权隐患。
具体到这个美容项目，微信端登录后的预约、下单操作，都需要拿当前用户的openid或userId去关联数据。如果你发现某个下单接口可以从请求参数里直接传用户ID，那这个设计就有问题，属于可被刷接口的漏洞。
4.4 文件上传：美容项目图片为什么老是加载不出来
美容系统里，门店照片、美容师头像、项目图片、用户评价图片，全是文件上传的场景。本地开发时，上传的文件通常存在一个本地目录，比如/upload文件夹下，然后通过虚拟路径映射来对外提供访问：
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); }这里最常出的问题就是路径配置。Windows上要注意盘符和反斜杠转义，Linux上要注意权限。如果你上传成功了，但页面上图片地址返回404，先检查访问的URL是/upload/xxx.jpg，而实际文件是否真的在那个映射目录里。还有一个更隐蔽的问题：项目打包成jar运行后，user.dir指向的是jar所在的目录，而不是项目代码目录，这时候相对路径的upload目录就跑到别的地方去了。生产环境部署时，uploadPath这种配置一定要写成绝对路径。
我建议你在本地调试时就把上传路径配置成绝对路径，比如/data/beauty/upload，这样后期部署到服务器不用改代码，只要在服务器上创建这个目录并设置权限即可。
5. 二次开发：读懂权限模型后怎么加一个美容项目管理模块
5.1 先读表结构，再动手写代码
很多人拿到源码，第一件事就是Ctrl+F找"会员"、"订单"之类的关键词，然后开始改代码。这种做法不是说不行，但你会经常陷入"到底在哪加字段""这个接口会不会影响别的地方"的纠结。
我的建议是，先把数据库里的表结构理一遍。核心的表无非就这几类：
系统权限类：sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu 商家门店类：shop、shop_user 会员用户类：member、member_card、member_recharge_record 业务交易类：project（服务项目）、appointment（预约）、order、order_item 营销类：coupon、coupon_user把表之间的外键关系理清楚，比如order表里的member_id、shop_id、project_id分别关联了谁，你改起来心里就有数了。这一步花不了多少时间，但能让你少走很多弯路。
5.2 新增一个管理模块的完整路径
假设现在要加一个"美容项目分类"的管理功能，完整路径是这样的：
- 在数据库里建表
project_category，字段包括id、category_name、sort、status、create_time - 在后台端的
mapper层写Mapper接口和XML文件，对应基础的增删改查 - 在
service层写业务逻辑，简单的模块可以直接复用IService和ServiceImpl - 在
controller层写REST接口，/admin/category/add、/admin/category/list等 - 如果用了若依或类似框架，还要往
sys_menu表插两条记录，给管理员分配菜单权限和按钮权限 - 前端页面对应加一个
category.vue，调用后端接口渲染列表
每一步都有固定的套路，你照着已有的模块抄就行。这个美容系统里完全可以找到"项目"或者"套餐"模块，它的代码结构就是你要模仿的模板。
5.3 商家数据隔离：别把A店的数据给B店看
二次开发时最需要注意的，就是商家端的数据隔离。你给商家端加任何查询接口，都要带上当前登录商家的shop_id过滤条件。
怎么保证每个接口都带上？我见过最简单粗暴的办法是在SQL里手动写where shop_id = ?，稳妥但容易漏。更优雅的做法是在MyBatis层做一个拦截器，自动给Mapper的SQL注入租户ID条件，这也就是MyBatis-Plus的TenantLineInnerInterceptor干的事。
如果源码里已经用了MyBatis-Plus，直接在配置里加上多租户插件，然后指定哪些表需要租户隔离、租户字段叫什么，就能全局生效：
interceptor.addInnerInterceptor(new TenantLineInnerInterceptor(new TenantLineHandler() { @Override public Expression getTenantId() { return new LongValue(tenantId); } }));这种方案的好处是所有新增Mapper自动带上隔离条件，不用你每条SQL手写。缺点是需要对框架有一定了解才能调明白。如果你暂时不想碰这些，那就老老实实每一个新接口都手动加shop_id，虽笨但不容易出错。
5.4 商家端只显示自己的数据：前端路由和菜单的权限适配
数据层面的隔离解决后，前端还要配合。商家登录后，只能看到商家端相关的菜单，不能看到平台后台的管理菜单。这同样依赖权限系统。
如果你在做二次开发时给商家也分配了后台端的角色，就要特别小心角色携带的菜单范围。一个常见的做法是建两个角色模板：一个"平台管理员"，包含全部菜单权限；一个"商家管理员"，只包含门店管理、预约管理、会员管理等业务菜单。这样从角色层面就限制了商家能看到的界面和能调的接口。
6. 打包部署上线的流程与生产环境差异
6.1 Maven打包时跳过测试和前端构建
本地跑通之后，部署到服务器就是另一套流程了。先在本地做一次完整打包：
mvn clean package -DskipTests-DskipTests跳过单元测试，但不是跳过测试代码编译，如果想编译都不敢编，就用-Dmaven.test.skip=true。打出来的是三个jar包，分别对应三个端。用jar方式部署的好处是服务器上不用额外装Tomcat，Spring Boot内嵌了Web容器，一个java -jar就启动了。
6.2 生产环境的配置差异
生产环境和本地最大的差异就三个地方：
数据库：application.yml里的数据库地址改成服务器上的地址，用户名密码改成生产账号，绝对不能使用root加弱密码。
上传路径：本地用的相对路径在jar包运行时不生效，必须改成服务器上的绝对路径，比如/data/beauty/upload。记得先建目录再启动项目，否则启动时文件写不进去会报错。
日志：本地看控制台就够了，生产必须写文件。在logback-spring.xml里配置按天滚动：
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/data/beauty/logs/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/data/beauty/logs/app.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> </appender>日志格式建议加上时间、线程名、类名、行号，排查问题时你会感谢自己当初做了这个配置。
6.3 启动脚本和内存参数的坑
生产启动不能用裸的java -jar，因为SSH断开进程就没了。用nohup：
nohup java -Xms512m -Xmx1024m -jar beautysys-admin.jar --spring.profiles.active=prod > /dev/null 2>&1 &内存参数要根据服务器的实际配置来，如果机器只有2G内存，三个端每端都给1024m，那直接OOM。我自己遇到过搜索热词里那个java: outofmemoryerror: insufficient memory的报错，最典型的原因就是同时启动多个端但JVM默认堆内存分配过高，超出了服务器物理内存。最简单的验证方法：
free -h看一下可用内存和Swap，再决定每个JVM给多少。一个只有1G的服务器上，三个Spring Boot应用还能同时跑吗？能，但每个只能给256m到384m，要接受频繁的GC。
如果用--spring.profiles.active=prod这种方式激活生产配置，那你需要在application-prod.yml里准备生产环境专用的配置。注意生产配置里绝不能出现测试环境的数据源连接串，这个错误我在真实项目里见过不止一次，线上数据写入测试库的事故就是这样来的。
启动完成后，看日志确认端口起来了，再用curl试一下接口通不通：
curl http://localhost:8080/api/xxx到这一步，整套源码算是从"别人发的zip"变成了"你线上跑着的服务"。
我在实际折腾这类项目时，最大的体会是：源码包能不能跑起来，三分靠项目质量，七分靠环境是否顺。JDK版本对不上、Maven依赖拉不下来、MySQL编码不对、端口被占用，每一步都能卡掉大量初学者。这个美容管理系统的代码本身并不复杂，三端架构的核心在于理解后台端管全局、商家端管门店、微信端管用户这条业务主线。顺着这条线去读代码，你会发现自己很快就知道该改哪里、该在哪个文件加接口了。哪怕你最后没有真正上线运营这套系统，光是把它完整地跑通一遍，再照着它的模式加一两个自己的模块，Java后端开发里最常用的Spring Boot、MyBatis、权限控制、微信登录、文件上传这些技能点，基本都能覆盖到了。
本文还有配套的精品资源，点击获取
