简介这是一套完整的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依赖frameworkmerchant依赖commonwxapi也依赖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 11Spring 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_HOMEC:\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 idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://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哪个版本准备的。如果脚本里有engineInnoDB default charsetutf8mb4那你本机尽量用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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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负责输出部署简单但前后端耦合严重另一种是前后端分离VueElementUI负责页面后端只提供JSON接口。我个人更推荐后者因为后续商家端、微信端能复用同一套后端接口改动更少。你拿到源码时看一眼后台端的resources下有没有templates目录有就是前者纯前后端分离的话会有一个独立的前端工程。3.2 商家端业务闭环里的关键执行层商家端在美容管理系统里的定位是给美容院门店老板或店长用的。它跟平台后台的视角不一样平台后台看的是全局商家端只看自己这个店。商家端功能上通常包含门店信息维护地址、电话、营业时间、门店照片美容师管理技师列表、排班、服务项目绑定预约管理查看本店的预约单、确认或取消预约会员管理查看在本店消费过的会员、会员卡余额团购/套餐核销用户在微信端买了套餐到店出示核销码经营数据本店今日营收、订单量、客单价这套系统里的商家端如果是一个独立的Web工程那通常也是VueElementUI或微信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 先读表结构再动手写代码很多人拿到源码第一件事就是CtrlF找会员、订单之类的关键词然后开始改代码。这种做法不是说不行但你会经常陷入到底在哪加字段这个接口会不会影响别的地方的纠结。我的建议是先把数据库里的表结构理一遍。核心的表无非就这几类系统权限类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.skiptrue。打出来的是三个jar包分别对应三个端。用jar方式部署的好处是服务器上不用额外装TomcatSpring Boot内嵌了Web容器一个java -jar就启动了。6.2 生产环境的配置差异生产环境和本地最大的差异就三个地方数据库application.yml里的数据库地址改成服务器上的地址用户名密码改成生产账号绝对不能使用root加弱密码。上传路径本地用的相对路径在jar包运行时不生效必须改成服务器上的绝对路径比如/data/beauty/upload。记得先建目录再启动项目否则启动时文件写不进去会报错。日志本地看控制台就够了生产必须写文件。在logback-spring.xml里配置按天滚动appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file/data/beauty/logs/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePattern/data/beauty/logs/app.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy /appender日志格式建议加上时间、线程名、类名、行号排查问题时你会感谢自己当初做了这个配置。6.3 启动脚本和内存参数的坑生产启动不能用裸的java -jar因为SSH断开进程就没了。用nohupnohup java -Xms512m -Xmx1024m -jar beautysys-admin.jar --spring.profiles.activeprod /dev/null 21 内存参数要根据服务器的实际配置来如果机器只有2G内存三个端每端都给1024m那直接OOM。我自己遇到过搜索热词里那个java: outofmemoryerror: insufficient memory的报错最典型的原因就是同时启动多个端但JVM默认堆内存分配过高超出了服务器物理内存。最简单的验证方法free -h看一下可用内存和Swap再决定每个JVM给多少。一个只有1G的服务器上三个Spring Boot应用还能同时跑吗能但每个只能给256m到384m要接受频繁的GC。如果用--spring.profiles.activeprod这种方式激活生产配置那你需要在application-prod.yml里准备生产环境专用的配置。注意生产配置里绝不能出现测试环境的数据源连接串这个错误我在真实项目里见过不止一次线上数据写入测试库的事故就是这样来的。启动完成后看日志确认端口起来了再用curl试一下接口通不通curl http://localhost:8080/api/xxx到这一步整套源码算是从别人发的zip变成了你线上跑着的服务。我在实际折腾这类项目时最大的体会是源码包能不能跑起来三分靠项目质量七分靠环境是否顺。JDK版本对不上、Maven依赖拉不下来、MySQL编码不对、端口被占用每一步都能卡掉大量初学者。这个美容管理系统的代码本身并不复杂三端架构的核心在于理解后台端管全局、商家端管门店、微信端管用户这条业务主线。顺着这条线去读代码你会发现自己很快就知道该改哪里、该在哪个文件加接口了。哪怕你最后没有真正上线运营这套系统光是把它完整地跑通一遍再照着它的模式加一两个自己的模块Java后端开发里最常用的Spring Boot、MyBatis、权限控制、微信登录、文件上传这些技能点基本都能覆盖到了。本文还有配套的精品资源点击获取
Java美容管理系统源码实战：从解压到三端联调部署
简介这是一套完整的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依赖frameworkmerchant依赖commonwxapi也依赖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 11Spring 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_HOMEC:\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 idaliyunmaven/id mirrorOfcentral/mirrorOf name阿里云公共仓库/name urlhttps://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哪个版本准备的。如果脚本里有engineInnoDB default charsetutf8mb4那你本机尽量用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?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/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负责输出部署简单但前后端耦合严重另一种是前后端分离VueElementUI负责页面后端只提供JSON接口。我个人更推荐后者因为后续商家端、微信端能复用同一套后端接口改动更少。你拿到源码时看一眼后台端的resources下有没有templates目录有就是前者纯前后端分离的话会有一个独立的前端工程。3.2 商家端业务闭环里的关键执行层商家端在美容管理系统里的定位是给美容院门店老板或店长用的。它跟平台后台的视角不一样平台后台看的是全局商家端只看自己这个店。商家端功能上通常包含门店信息维护地址、电话、营业时间、门店照片美容师管理技师列表、排班、服务项目绑定预约管理查看本店的预约单、确认或取消预约会员管理查看在本店消费过的会员、会员卡余额团购/套餐核销用户在微信端买了套餐到店出示核销码经营数据本店今日营收、订单量、客单价这套系统里的商家端如果是一个独立的Web工程那通常也是VueElementUI或微信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 先读表结构再动手写代码很多人拿到源码第一件事就是CtrlF找会员、订单之类的关键词然后开始改代码。这种做法不是说不行但你会经常陷入到底在哪加字段这个接口会不会影响别的地方的纠结。我的建议是先把数据库里的表结构理一遍。核心的表无非就这几类系统权限类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.skiptrue。打出来的是三个jar包分别对应三个端。用jar方式部署的好处是服务器上不用额外装TomcatSpring Boot内嵌了Web容器一个java -jar就启动了。6.2 生产环境的配置差异生产环境和本地最大的差异就三个地方数据库application.yml里的数据库地址改成服务器上的地址用户名密码改成生产账号绝对不能使用root加弱密码。上传路径本地用的相对路径在jar包运行时不生效必须改成服务器上的绝对路径比如/data/beauty/upload。记得先建目录再启动项目否则启动时文件写不进去会报错。日志本地看控制台就够了生产必须写文件。在logback-spring.xml里配置按天滚动appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file/data/beauty/logs/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePattern/data/beauty/logs/app.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy /appender日志格式建议加上时间、线程名、类名、行号排查问题时你会感谢自己当初做了这个配置。6.3 启动脚本和内存参数的坑生产启动不能用裸的java -jar因为SSH断开进程就没了。用nohupnohup java -Xms512m -Xmx1024m -jar beautysys-admin.jar --spring.profiles.activeprod /dev/null 21 内存参数要根据服务器的实际配置来如果机器只有2G内存三个端每端都给1024m那直接OOM。我自己遇到过搜索热词里那个java: outofmemoryerror: insufficient memory的报错最典型的原因就是同时启动多个端但JVM默认堆内存分配过高超出了服务器物理内存。最简单的验证方法free -h看一下可用内存和Swap再决定每个JVM给多少。一个只有1G的服务器上三个Spring Boot应用还能同时跑吗能但每个只能给256m到384m要接受频繁的GC。如果用--spring.profiles.activeprod这种方式激活生产配置那你需要在application-prod.yml里准备生产环境专用的配置。注意生产配置里绝不能出现测试环境的数据源连接串这个错误我在真实项目里见过不止一次线上数据写入测试库的事故就是这样来的。启动完成后看日志确认端口起来了再用curl试一下接口通不通curl http://localhost:8080/api/xxx到这一步整套源码算是从别人发的zip变成了你线上跑着的服务。我在实际折腾这类项目时最大的体会是源码包能不能跑起来三分靠项目质量七分靠环境是否顺。JDK版本对不上、Maven依赖拉不下来、MySQL编码不对、端口被占用每一步都能卡掉大量初学者。这个美容管理系统的代码本身并不复杂三端架构的核心在于理解后台端管全局、商家端管门店、微信端管用户这条业务主线。顺着这条线去读代码你会发现自己很快就知道该改哪里、该在哪个文件加接口了。哪怕你最后没有真正上线运营这套系统光是把它完整地跑通一遍再照着它的模式加一两个自己的模块Java后端开发里最常用的Spring Boot、MyBatis、权限控制、微信登录、文件上传这些技能点基本都能覆盖到了。本文还有配套的精品资源点击获取