简介基于JavaSpringBootVueHTML5构建的美发门店管理系统专为美发店日常运营与数字化升级打造覆盖顾客、预约、员工、服务项目、库存、财务及收银等核心业务模块适合门店管理者快速上线信息化工具也适合开发者学习前后端分离项目实战。资源包共825个文件体积仅13.37MB以Java源码、Vue组件、HTML页面、CSS样式、JavaScript脚本为主附有SQL数据库初始化脚本和调试文档结构清晰便于按模块研读与部署。目前已有101人浏览学习。整套资料不仅包含可直接运行的完整项目源码还提供了安装部署脚本、配置说明与常见问题解答能够帮助使用者在本地环境快速搭建系统理解SpringBootVueHTML5的整合思路掌握美发门店管理系统的数据表设计与收银流程实现是兼具实用价值与教学意义的优质资源。 做美发门店管理系统这个项目起点特别朴素——有位开理发店的朋友跟我吐槽会员卡是拿本子记的员工提成全靠月底算收银偶尔还会漏单客人预约老是撞时间。他说“规模不大毛病不少”。我一听就懂了这种门店缺的不是生意是一套能把收银、会员、预约、提成、流水全串起来的管理工具。后来我按Java SpringBoot Vue HTML5这套技术栈把系统做了出来顺便整理成了一份完整的开源毕设/商用项目包正好适合正在找Java实战项目、做毕业设计或者想给美发店类小商户落地管理系统的人参考。我要先说明一点这套系统不是只做个增删改查的示例而是真正奔着“能用”去做的。它覆盖了美发店日常最核心的几件事——办卡充值、消费扣款、预约排班、员工提成、商品库存、营业报表。技术栈上后端用了SpringBoot前端用VueHTML5做单页应用前后端分离部署简单二次开发空间也大。整个项目做下来踩了不少坑也沉淀了不少实战经验这篇文章就把项目从需求分析到最终交付的完整过程拆开讲清楚。1. 项目给我的第一课先理清门店业务再谈代码1.1 美发门店每天都在为什么头疼我在做需求调研时发现绝大多数中小美发店的日常管理还停留在“半手工”状态。办卡用的是纸质登记表顾客报手机号店员翻本子收银用的是普通收款码钱进了个人账户跟店里订单对不上预约靠微信群喊话发型师时间撞了才知道。这些问题看似零零碎碎聚合起来就是三件事账算不清、客留不住、人排不开。所以系统设计的第一步不是建表而是把门店的业务闭环理清楚。我把它归纳成一条主线顾客线上或到店预约到店后确认服务项目理发师开始服务服务完成后收银结账结账时判断是否会员、是否用储值余额同时计算员工提成和库存消耗最后所有数据沉淀成营业报表。这条链路上任何一个环节断掉后面都会乱。1.2 系统边界哪些功能必须做哪些先不碰任何项目最怕的就是需求蔓延。美发店管理系统可以做得很重——排班、绩效、客户画像、营销短信、连锁门店管理都能往里塞。但我从一开始就定了边界第一版只做门店日常经营真正高频使用的功能也就是收银、会员、预约、员工、商品、基础统计六大模块。这里有个很重要的取舍经验像复杂的员工排班、多门店数据同步、小程序用户端这些要么涉及复杂算法要么需要额外部署和审核把它们塞进第一版只会拖垮交付节奏。更务实的做法是先把单店核心业务跑通留下清晰的扩展接口后面再逐步加。事实证明这个决策是对的后期所有新增需求都是在稳定基础上做加法而不是推倒重来。1.3 技术选型为什么是Java SpringBoot Vue HTML5选这套技术栈不是因为它最时髦而是因为它最稳妥。Java的生态和稳定性不用多说SpringBoot大幅降低了配置成本开发效率比传统SSH高出一大截内嵌Tomcat也让部署变得很轻量。前端用Vue HTML5一方面组件化开发让收银台、预约看板这种交互复杂的页面更容易维护另一方面HTML5的特性可以很好地支持店内触摸屏和现代浏览器的使用场景。对比一下其他方案如果用纯JSP/Servlet做前后端耦合太深界面响应和交互体验都一般改个样式都可能牵动后端代码如果后端选Node.js或Python开发和部署确实更轻但美发店管理这类业务面对的是实体门店老板更看重系统稳定性和后续找人来维护的成本Java在这方面有天然优势。实际开发中SpringBoot Vue这套组合的资料多、解决方案成熟遇到问题基本都能快速找到答案这对单兵作战或者小团队开发来说太重要了。2. 系统整体架构与数据结构设计2.1 前后端分离的模块划分系统整体采用前后端分离架构后端负责业务逻辑和数据处理前端负责界面交互。后端按业务域拆分为系统登录认证模块、会员管理模块、服务项目管理模块、预约管理模块、收银订单模块、员工管理模块、商品库存模块、数据统计模块。前端则拆成两个入口一个是面向店长/管理员的管理后台另一个是面向收银员/前台的操作端两者共用大部分组件只是菜单权限和页面布局不同。之所以采用这种拆分方式是因为美发店的实际使用场景中收银台需要快速响应、大按钮展示、减少误触而管理后台更偏向信息查询和报表分析。两个入口的交互逻辑差异较大如果硬塞进同一个页面反而会让操作效率下降。前端通过Vue Router做页面路由每个模块对应独立视图API请求统一封装接口地址直接调用后端RESTful API。2.2 数据库表到底怎么设计数据库设计我花的时间最多因为业务逻辑绕不开它。核心表包括系统用户表、会员表、会员卡类型表、卡项充值记录表、预约记录表、服务项目表、商品表、订单表、订单明细表、员工提成记录表、操作日志表。这里我以订单表为例展示一下关键字段设计字段名类型说明idbigint主键自增order_novarchar(32)订单编号业务唯一member_idbigint会员ID可空total_amountdecimal(10,2)订单原价合计discount_amountdecimal(10,2)优惠金额pay_amountdecimal(10,2)实际应付金额pay_typetinyint支付方式1现金、2微信、3支付宝、4储值卡statustinyint订单状态1待支付、2已支付、3已退款、4已完成operator_idbigint操作员工IDremarkvarchar(255)备注create_timedatetime创建时间这里有个容易被新手忽略的细节订单号不要直接用数据库自增ID而要单独生成业务编号。因为自增ID在并发、对账、外部查询时都不够安全而且容易暴露门店经营规模。我在项目里用“时间戳 随机数”的方式生成order_no保证并发场景下不重复同时方便按时间范围排查订单。2.3 一个容易忽略的设计点逻辑删除与审计字段我见过不少初级项目的表结构连create_time都不加更别提逻辑删除了。但在美发店这类真实业务场景里数据审计极其重要。比如顾客充了钱如果某天误删了会员订单记录后果很麻烦。所以我的所有核心表都统一加了create_time、update_time、deleted这几个字段deleted默认0表示未删除逻辑删除时置为1。这样一来删数据不是真删而是标记删除。列表查询时统一过滤deleted 1的数据既能防止误操作导致数据彻底丢失又能在后续做数据回溯和对账时找到原始记录。代价是要多写一点查询条件但这个成本跟数据安全性相比完全不值一提。3. 后端实现里最花心思的四个模块3.1 SpringBoot工程结构与统一返回体后端的工程结构我用的是标准分层模式controller、service、mapper、entity、dto、common。Controller层只做参数接收和结果封装Service层写业务逻辑Mapper层负责数据库交互。为了让前端拿到统一的响应格式我封装了一个Result类包含code、message、data三个字段接口返回时统一用Result.success(data)或Result.fail(msg)。public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message 操作成功; result.data data; return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.code 500; result.message message; return result; } }与此同时我用RestControllerAdvice做了全局异常处理业务异常、参数校验异常、系统异常分开捕获。这样前端拿到的错误信息永远是“可读、可展示”的而不是一堆堆栈痕迹。这看起来是个小细节但真实项目里这种统一处理能省掉前后端联调时的大量沟通成本。3.2 会员储值与卡项消费的事务处理会员模块里最核心的就是储值余额变动。顾客充1000送100消费时扣余额退款时退回余额这些操作都要面对同一个问题余额不能算错。我用了MySQL的Transactional事务来保证一组操作要么全部成功、要么全部失败。以一个“会员消费使用余额支付”的场景为例同时要更新会员余额、生成消费流水、记录订单状态、计算员工提成。这四个动作跨了多张表如果不同步操作很容易出现余额扣了但订单没生成的情况。用Spring的声明式事务管理Service层方法只要加上Transactional注解事务边界就自动建立起来。还需要注意事务方法里不要捕获异常后吞掉否则事务不会回滚这点我在代码里特意做了注释提醒。3.3 收银台结算优惠计算与订单流水收银是整个系统最频繁的操作也是我设计得最谨慎的地方。前端页面上收银员勾选服务项目系统自动累加原价再判断会员等级对应的折扣最后算出实付金额。这里有一个关键原则优惠计算必须以后端为准前端只是展示。为什么这么定因为如果前端算好金额传给后端懂点接口知识的人完全可以自己改价格或者前端代码有bug导致金额错误对账时根本查不出来。正确做法是前端只传“项目ID集合”和“会员ID”后端根据数据库里的价格、会员折扣动态计算订单金额前端只负责把结果展示给顾客确认。这样既安全又保证数据口径一致。订单生成的同时还会往订单明细表写入每一条服务项目或商品方便后期看营业构成。这部分我用了循环插入明细外层套事务保证订单主表和明细表数据一致。收银完成后再触发一次异步统计更新同步刷新当日营业额汇总。3.4 员工提成计算如何避免拍脑袋美发店员工提成是个敏感点算错了非常伤和气。我在系统里把提成规则拆成“服务项目提成比例”和“商品销售提成比例”两类。服务项目按项目维度设置比例比如剪发提成为30%染发提成为20%商品则按商品分类设置比如洗发水卖出提成为10%。每笔订单完成后系统自动按当时的设置计算提成并记入员工提成记录表。之所以在“订单完成”时就计算并固化提成是为了避免月底统一计算时因为数据变更产生纠纷。业务上还有一个细节如果订单退款已经生成的提成记录要同步生成负数冲销保证月度提成汇总准确。这些逻辑不复杂但一定要提前想清楚否则后期对账会非常痛苦。4. 前端页面与交互细节4.1 Vue项目的搭建与路由设计前端我用Vue 2 Element UI搭建项目结构按模块拆分views目录下放登录页、工作台、收银页、会员管理、预约看板、报表统计等页面router目录下配置路由并为需要登录才能访问的页面统一设置前置守卫没登录就跳转到登录页。router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.path /login) { next(); } else if (!token) { next(/login); } else { next(); } });这个守卫逻辑很简单但很实用。实际开发中我还给页面按钮做了权限控制店长和收银员看到的菜单不同操作权限也不同。比如普通收银员能收银但不能查看营业利润报表。权限控制在真实门店场景中很重要否则员工之间容易因薪资、流水数据产生矛盾。4.2 收银界面的交互体验收银页是前端工作量最大的地方。页面布局上左侧是服务项目和商品列表支持搜索和分类筛选右侧是当前挂单的购物车显示项目名称、单价、折扣、实付金额底部是结算按钮和支付方式选择。考虑到美发店收银员可能在忙碌时单手操作所有按钮都设计得比较大关键操作按钮之间的间距也做了加大处理。这里有一个交互细节容易踩坑顾客临时说“我先不剪了”收银台需要支持挂单和取单。我用一个数组保存当前购物车内容点击挂单时把数据暂存到内存同时清空当前界面取单时重新加载。数据量不大不需要在后端建表但一定要考虑这个场景否则收银员只能被迫取消整单很影响效率。4.3 预约看板的状态流转预约管理我采用了看板式设计以时间为横轴、理发师为纵轴每个格子显示预约时间、顾客姓名、服务项目。这样门店前台一眼就能看到谁几点来、哪个理发师什么时候有空。预约状态我用数字标识1已预约、2已到店、3服务中、4已完成、5已取消前端用标签颜色区分。状态流转上前端会做二次确认比如把已预约修改为已到店弹窗提示“确认顾客已到店”避免误触。页面数据刷新我用的是定时轮询每10秒拉一次最新预约列表。用轮询而不是WebSocket是因为门店场景并发量不大轮询实现简单、稳定不依赖额外组件对部署环境要求更低。如果后续要做连锁店实时调度再替换成WebSocket也不迟。5. 调试、部署与交付资料的实用经验5.1 本地开发环境搭建的完整步骤项目拿到手或者自己从零开发时第一步永远是搭环境。后端环境我列一下我自己多次验证过的版本组合JDK 1.8、Maven 3.6、MySQL 5.7或8.0、Node.js 14。SpringBoot版本用的2.7.x这个版本兼容性好踩坑少。数据库初始化时需要注意MySQL 8.0的驱动配置和时区问题。我在application.yml里是这样配的spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/hair_salon?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456很多新手在这步卡住报错The server time zone value Öйú±ê׼ʱ¼ä is unrecognized就是因为没加serverTimezone参数。另外MySQL 8.0驱动名是com.mysql.cj.jdbc.Driver不是老版本的com.mysql.jdbc.Driver这个区别我吃了不少亏。5.2 源码拿到手之后怎么跑起来如果是从交付包里获取源码来学习和部署推荐按以下顺序操作。第一步用IDE导入后端Maven项目等待依赖下载完成第二步创建数据库并导入项目里自带的SQL文件第三步修改application.yml中的数据库账号密码第四步启动后端服务确认端口8080没有占用第五步在cmd里进入前端项目目录依次执行npm install和npm run serve第六步浏览器访问localhost:8080对应的前端地址完成登录。这里有个很常见的问题前后端分离项目前端访问后端接口会有跨域问题。我在后端CorsConfig里做了全局跨域配置允许本地开发地址访问。实际部署时如果前端打包后放到Nginx里建议用Nginx反向代理/api路径指向后端服务这样不用暴露后端端口跨域问题也一并解决。5.3 交付文档怎么看源码、LW、调试文档、讲解怎么配合使用这个项目交付时通常包含源码、LW设计文档/配套论文、调试文档和讲解资料这里我分享一个比较高效的使用顺序。先看LW的目录结构它一般包含需求分析、系统设计、数据库设计、页面原型和测试报告能让你在动手前就对整个系统有完整认知。然后按调试文档走一遍环境搭建和部署流程这样能排除绝大多数环境问题。最后才是打开源码对照LW里的设计逐步理解每个模块是怎么实现的。很多同学拿到代码就直接开始读源码结果被各种类之间调用关系绕晕其实我觉得最好的方式是“带着问题读代码”。比如LW里写了会员储值的时序图你就去找ServiceImpl里对应的Transactional方法看实际实现跟文档描述的差异在哪。这套方法对做毕设答辩或者面试准备都很有帮助因为你对项目的理解是成体系的而不是零散记代码。6. 常见问题排查与项目扩展方向6.1 开发与运行阶段的高频报错我在开发和辅导别人跑项目时整理了一些高频报错和解决办法这里列成速查表希望能帮大家省点排查时间。报错现场根本原因解决方式Access denied for user rootlocalhost数据库密码错误或权限不足检查application.yml核对MySQL账号密码Port 8080 was already in use后端端口被占用改端口或释放占用进程Windows用netstat -ano查PIDnpm install卡住或报错依赖源慢或网络问题用淘宝镜像npm config set registry https://registry.npmmirror.com页面请求接口报404前端代理路径与后端接口前缀不一致统一在vue.config.js里配置proxy代理路径时间查询结果差8小时数据库时区和JVM时区不一致URL加serverTimezoneAsia/ShanghaiJackson设置时间格式中文乱码字符集不统一确认数据库、连接URL、页面编码均为UTF-8我发现大部分问题都出在环境配置上真正的代码逻辑bug反而少。所以在排查问题时优先级应该是“环境问题 数据问题 代码问题”别一上来就追代码。6.2 业务流程上的隐藏坑除了技术报错业务流程上也有几个很容易踩的坑。第一个是会员储值并发扣款。如果同一个会员在两个收银台同时结账可能出现余额被超扣的情况。我在更新会员余额的SQL里加了条件判断update member set balance balance - #{amount} where id #{id} and balance #{amount}这样即使并发请求到达数据库也只有一个能成功扣减另一个会因为不满足条件而失败。第二个坑是订单删除与营业统计不一致。比如某个订单完成后被误删当日营业额报表就少了这笔。所以订单不提供物理删除只有“退款”和“作废”状态统计时只统计状态为“已完成”的订单这样数据口径永远一致。第三个坑是操作日志。我把关键操作充值、退款、删除会员统统写入操作日志表方便后续追溯。这个功能看似占用不多但在真实门店纠纷处理中价值巨大。6.3 这套系统还能怎么扩展如果已经把这个项目跑通了或者正在用它做毕业设计我建议可以从以下几个方向做扩展。第一增加小程序会员端让顾客自己在线预约、查看余额、接收消费通知这一步能直接提高门店服务体验。第二引入短信或公众号模板消息在预约前自动提醒顾客降低爽约率。第三增加连锁门店支持在门店表基础上扩展数据权限让不同门店只能看到自己的数据。第四做更细致的权限管理引入Spring Security或Sa-Token把按钮级别的权限控制做完整。我最推荐的是把预约模块做成“微信小程序 后端API”的方式。小程序端用原生或uni-app开发后端只要把已有的预约接口做一下适配就能把顾客预约体验从线下搬到线上。这个扩展既实用又能作为项目亮点写进简历或毕设答辩里。最后再分享一个我做完这个项目后的体会管理系统这类项目技术本身其实不难真正难的是把业务流程理解透并且能在代码层面守住数据一致性和可追溯性这两条底线。如果你也在做类似项目我建议先从自己熟悉的业务场景入手把需求拆细再决定技术和数据库设计。等你把一个完整项目跑通从中获得的远远不止技术能力还有对业务、对工程化、对交付的整体认知。这套美发门店管理系统我希望你能在跑通的基础上加入自己的想法和扩展做出真正属于自己的东西。本文还有配套的精品资源点击获取