ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

三端分离Java美容管理系统源码:课程设计级实战与二次开发指南

三端分离Java美容管理系统源码:课程设计级实战与二次开发指南 简介这是一套面向Java开发者与美容行业信息化从业者的美容管理系统源码采用多端架构包含后台管理、商家端与微信端适合用于二次开发、毕业设计或商业项目参考。系统以消费者关注服务号后在线预约项目、到店消费服务为主线集成威富通第三方支付覆盖微信、支付宝、扫码枪扫码及微信H5支付并接入微信JSSDK实现分享、地图定位与模板消息推送同时集成阿里大于短信功能。技术栈方面后台基于IMS框架搭配EasyUI商家端使用EasyUI美化主题包微信端采用AUI框架开发。压缩包为zip格式共约2000个文件整体约85.05MB其中png、gif、jpg等图片资源用于界面展示js、css、scss、less负责前端交互与样式java、jsp、xml构成后端业务逻辑另有jar依赖、sql脚本及各类配置文件目录结构完整。目前已有303人学习下载适合希望研究多端协同、支付集成与微信生态开发的读者参考借鉴。1. 三端分离的 Java 美容管理系统一份能直接跑起来的课程设计级源码最近在整理手头的 Java 课程设计素材时翻到一套美容管理系统的源码包结构挺典型后台管理端、商家端、微信端三个入口共用一套 Java 服务端。这类系统在毕设和课程设计里出现频率很高但真正把三端拆清楚、权限分明白的并不多。它解决的核心问题是一个美容门店既要总部管项目、管会员、管订单又要让门店自己排班、核销还得让顾客在微信里预约、查卡。三端各管一段数据却要一致。适合正在找 Java 课程设计案例源码的人也适合想拿一套完整业务系统练手 MyBatis、Spring 前后端分离的开发者。下面按「它是什么 → 怎么跑起来 → 坑在哪 → 怎么改」的顺序拆一遍。2. 三端架构拆解后台、商家端、微信端各自管什么2.1 三端的职责边界与数据流向先把三端的分工说清楚不然后面改代码会迷路。后台端是平台运营视角管的是全局基础数据美容项目分类、项目定价、会员等级规则、优惠券模板、门店入驻审核。商家端是单个门店视角管的是本店资源美容师排班、预约时段、到店核销、本店订单和业绩。微信端是顾客视角管的是个人行为浏览项目、在线预约、查看会员卡余额、消费记录。数据流向是单向收敛的微信端产生的预约和订单先落到商家端确认再汇总到后台端做统计。反过来后台端配置的项目和价格下发到商家端展示再透传到微信端。这个方向不能反反了就会出现门店私自改价、顾客看到未审核项目的问题。常见做法是用一个 Spring Boot 单体服务承载三端接口通过 URL 前缀或请求头区分端类型比如/api/admin/**、/api/merchant/**、/api/wx/**。权限用拦截器加角色判断后台角色是ROLE_ADMIN商家是ROLE_MERCHANT微信端走ROLE_CUSTOMER或直接放行部分只读接口。2.2 技术栈与目录结构速览这套源码的技术栈是典型的 Java Web 组合Spring Boot 做服务端MyBatis 做持久层MySQL 存数据前端后台和商家端大概率是 Vue 或 Layui 这类管理后台模板微信端是 H5 页面。目录结构一般长这样src/main/java/com/example/beauty/ ├── controller/ │ ├── admin/ # 后台端接口 │ ├── merchant/ # 商家端接口 │ └── wx/ # 微信端接口 ├── service/ ├── mapper/ ├── entity/ └── config/ src/main/resources/ ├── mapper/ # MyBatis XML ├── application.yml └── static/ # 前端静态资源拿到包先别急着跑先看application.yml里的数据库配置和端口再看pom.xml里的依赖版本。Java 版本建议用 8 或 11Spring Boot 版本如果是 2.x 就别硬升 3.xJDK 17 以上会有兼容问题。前端如果是 Vue2Node 版本控制在 14 到 16 之间Node 18 以上跑老项目容易报 OpenSSL 错误。2.3 数据库表设计的几个关键点美容管理系统的表不算多但有几张核心表必须看懂。member表存会员信息关键字段是phone、level_id、balance。appointment表存预约记录关键字段是member_id、technician_id、start_time、status。order表存消费订单关键字段是order_no、member_id、amount、pay_status。这里有个容易忽略的点预约和订单是两张表不是一张。预约是意向订单是实际消费。顾客预约后到店商家核销预约生成订单订单支付后扣会员卡余额或走微信支付。如果源码里把预约和订单合成一张表改起来会很痛苦因为状态机混在一起了。提示导入 SQL 文件时注意字符集美容项目名称里常有中文和特殊符号用utf8mb4避免乱码。3. 本地跑通三端环境配置、启动顺序与接口验证3.1 数据库导入与配置修改第一步永远是数据库。找到源码包里的.sql文件用 Navicat 或命令行导入。命令行方式mysql -u root -p --default-character-setutf8mb4 -e CREATE DATABASE beauty_ms DEFAULT CHARACTER SET utf8mb4; mysql -u root -p beauty_ms beauty_ms.sql导入后检查表数量一般核心表在 15 到 25 张之间。如果只有几张表可能是分库脚本没导全。然后改application.ymlspring: datasource: url: jdbc:mysql://localhost:3306/beauty_ms?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver server: port: 8080serverTimezone必须设不设的话预约时间会差 8 小时这是血泪经验。characterEncodingutf8配合数据库的utf8mb4能覆盖大部分中文场景。3.2 服务端启动与常见报错处理配置改完直接跑主类。如果报Table beauty_ms.xxx doesnt exist说明 SQL 没导全或者表名大小写不一致。Linux 下 MySQL 默认表名区分大小写Windows 不区分跨平台迁移时容易翻车。解决办法是在my.cnf里加lower_case_table_names1或者统一表名小写。如果报Access denied for user检查密码和权限。如果是Public Key Retrieval is not allowed在 JDBC URL 后面加allowPublicKeyRetrievaltrue。启动成功后访问http://localhost:8080看是否能出登录页。后台端默认账号一般是admin/123456商家端是merchant/123456微信端直接访问 H5 路径。3.3 三端接口的验证顺序不要三端一起点按依赖顺序来。先验后台端登录后看项目列表、会员列表是否能加载。再验商家端用商家账号登录看本店预约列表是否有数据。最后验微信端打开 H5 页面看项目列表是否展示预约提交是否成功。接口验证可以用 Postman 或浏览器直接访问。比如后台端项目列表curl -X POST http://localhost:8080/api/admin/project/list \ -H Content-Type: application/json \ -H token: 登录后返回的token \ -d {page:1,size:10}如果返回 401说明 token 没带或过期。如果返回 403说明角色不对检查登录时用的账号角色。如果返回 500看服务端日志大概率是 SQL 映射字段和实体类对不上。3.4 前端资源打包与联调如果源码里前端是独立目录需要单独跑。Vue 项目常见命令npm install npm run servenpm install如果卡住换淘宝源npm config set registry https://registry.npmmirror.com。跑起来后前端默认端口 8081 或 8082需要在vue.config.js里配代理指向后端 8080否则跨域报错。// vue.config.js module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }changeOrigin: true必须加不加的话后端收到的 Host 头不对某些拦截器会拦掉。前端跑通后三端页面应该都能正常加载数据。4. 避坑与排查三端联调时最容易翻车的五个点4.1 预约时间差 8 小时现象微信端提交预约选的是下午 3 点商家端看到的是晚上 11 点。原因JDBC 连接没设serverTimezone或者设成了 UTC。解决URL 里加serverTimezoneAsia/Shanghai同时检查 MySQL 全局时区SELECT global.time_zone;如果是 UTC 就改成08:00。4.2 商家端看不到微信端的预约现象微信端提示预约成功商家端预约列表为空。原因预约表里merchant_id字段没写对或者微信端提交时没传门店 ID。解决查appointment表最新一条记录看merchant_id是不是 null 或 0。如果是检查微信端提交接口的参数门店 ID 应该从项目详情里带过来。4.3 后台改价后微信端不更新现象后台把某个项目价格从 198 改成 168微信端还是显示 198。原因微信端接口做了缓存或者前端把价格写死了。解决先看微信端接口返回的 JSON 里价格字段是不是新值。如果是新值但页面没变清浏览器缓存或看前端有没有localStorage缓存。如果接口返回旧值检查 MyBatis 二级缓存配置关掉cache/标签。4.4 会员卡余额扣减不对现象顾客消费后余额扣了两次或者扣了但订单没生成。原因扣余额和生成订单不在同一个事务里。解决在 Service 层方法上加Transactional确保扣余额、写订单、写流水三件事要么全成要么全败。同时检查是不是有重复提交前端按钮加防抖后端加幂等判断。4.5 微信端页面白屏现象H5 页面打开一片白控制台报Uncaught SyntaxError。原因前端打包路径不对或者后端静态资源映射没配。解决如果是 Vue 项目检查vue.config.js里的publicPath部署到子路径时改成./。如果是后端直接放静态文件检查application.yml里spring.resources.static-locations是否指向了正确的目录。5. 二次开发切入点从改一个字段到加一个模块5.1 最快上手改项目分类名称和图标想快速看到自己的改动生效从最简单的开始。找到后台端项目分类管理页面改分类名称和图标。数据库里对应project_category表改name和icon字段。前端如果图标是字体图标改 class 名如果是图片替换static目录下的文件。改完刷新后台端和微信端确认两边都变了。这一步能帮你摸清「后台改数据 → 前端展示」的完整链路。5.2 中等难度给预约加一个备注字段预约表加字段是常见的二次开发需求。步骤ALTER TABLE appointment ADD COLUMN remark VARCHAR(255) DEFAULT NULL COMMENT 顾客备注 AFTER status;然后改实体类Appointment.java加remark属性改 Mapper XML 的resultMap和insert、update语句改微信端提交预约的表单加输入框改商家端预约列表加备注列。四个地方缺一不可漏一个就出现「填了没存」或「存了不显示」。5.3 进阶接入微信支付的回调处理如果源码里微信支付是模拟的想接真实支付核心是回调接口。微信支付回调会 POST 一个 XML 或 JSON 到你的notify_url你需要验签、解析、更新订单状态。常见做法是单独写一个WxPayNotifyController不经过登录拦截器因为微信服务器不会带你的 token。PostMapping(/api/wx/pay/notify) public String payNotify(RequestBody String notifyData) { // 1. 验签确认是微信发来的 // 2. 解析出 out_trade_no 和 result_code // 3. 根据 out_trade_no 查订单更新 pay_status // 4. 返回 SUCCESS否则微信会重复通知 return xmlreturn_code![CDATA[SUCCESS]]/return_code/xml; }注意回调接口必须返回微信要求的格式返回错了微信会一直重试。另外订单状态更新要加锁或幂等防止重复通知导致重复加积分。5.4 验证改动是否生效的通用方法每次改完按这个顺序验先看数据库字段有没有、数据对不对再看接口返回的 JSON 有没有新字段最后看前端页面有没有展示。三步都过了才算改完。如果中间断了就停在断的那一步排查不要跳步。我一般会在改之前先备份数据库和源码改崩了直接回滚比一点点修快得多。6. 从这套源码里能带走什么一个可复用的三端权限模型这套美容管理系统最值得带走的不是美容业务本身而是三端权限模型。后台、商家、微信端共用一套用户体系但角色隔离接口按前缀分权数据按merchant_id做行级过滤。这个模型换成餐饮、健身、教培都能用。具体做法是用户表加role字段区分端类型登录时返回不同角色的 token拦截器根据 URL 前缀和 token 里的角色做双重校验。商家端所有查询强制带merchant_id条件这个条件从 token 里解析不从前端传防止越权查别家数据。// 商家端查询预约时merchantId 从 token 取不信任前端参数 Long merchantId TokenUtil.getMerchantId(request); queryWrapper.eq(merchant_id, merchantId);这个习惯我每次做多端系统都强制走一遍凡是涉及数据隔离的查询隔离字段必须从服务端会话取绝不从前端参数取。吃过一次亏前端传了别家门店 ID把人家会员列表拉出来了虽然只是测试环境但那种后背发凉的感觉记到现在。希望这套源码和上面的拆解能帮到你跑通之后试着把权限模型抽出来比单纯改业务代码值钱得多。本文还有配套的精品资源点击获取
返回列表