三月份这个节点很多计算机专业的大四学生已经开始正式动工毕设了。如果你正好拿到“防晒护肤品店销售管理平台”这个题目或者正在找一个能用Java稳定落地、答辩又能讲出东西来的管理系统选题那这篇博客应该能帮你省下不少折腾时间。我会从选题逻辑、技术栈选型、数据库设计、核心功能实现、常见坑位这几个角度把这个项目彻底拆开来讲最后再聊聊演示录像录什么、答辩时怎么讲才不会被问住。先说一句实在话毕设项目不是越复杂越好而是越“自洽”越好。所谓自洽就是题目、功能、技术方案、演示效果四条线能串成一条完整的故事线。防晒护肤品店销售管理平台这个题目正好符合这个标准——它既不是那种烂大街的“学生管理系统”“图书管理系统”业务场景又足够具象防晒、护肤、SPF值、适用肤质、效期管理这些行业细节能让你的设计和答辩内容自动拉开差距。1. 选题逻辑为什么这个题目值得做1.1 业务场景天然匹配管理系统的核心套路任何一个销售管理系统跑不出“商品管理、库存管理、销售管理、会员管理、统计报表”这五件事。防晒护肤品店的业务场景恰好把这五件事全部覆盖了而且每件事都有自己独特的业务约束。举个例子一般的图书管理系统商品只有“书名、作者、价格”几个属性CRUD写来写去就那些套路。但护肤品店不一样一支防晒霜除了名称和价格还必须维护SPF值、PA等级、适用肤质、净含量、生产批号、保质期这些维度。这意味你的商品表设计比教科书上的例子更真实你的界面表单比普通的“名称价格”更有内容你做出来的系统一眼看过去就知道是“为这个行业定制的”而不是拿模板改的。从答辩角度来说这个题目也很好讲。评委老师即使完全不懂Java他也买过防晒霜他能理解“夏天防晒霜卖得好所以要搞促销”“临期商品要提醒下架”这些业务逻辑。你不需要费半天劲解释“这个系统到底解决了什么”业务本身就已经给出了答案。1.2 行业细节是天然的答辩加分项防晒护肤品这个细分领域有几个让系统设计变得“有灵魂”的特性。第一是商品属性的多样化。防晒类目有SPF值防晒指数和PA等级防晒强度护肤类目有适用肤质油性、干性、敏感肌还有容量规格30ml、50ml、100ml、质地乳液、霜、喷雾。这些属性在筛选和展示时都需要进入查询条件意味着你的系统不是简单的全表SELECT而是有组合筛选逻辑的。第二是效期管理。化妆品是有保质期的正规门店对临期商品一般指剩余保质期不足6个月要单独管理。这在系统里就是一个很自然的预警功能设定一个预警阈值每天扫描库存里剩余效期不足N天的商品生成提醒列表。这个功能写起来不难但它体现的是“你懂这个行业的真实痛点”而不是只会写代码。第三是季节波动。防晒品类的销售有明显的季节性夏天是旺季冬天是淡季。这就可以引出销售统计里的“按月销售趋势”“品类销售占比”这些报表维度让统计模块有话可讲。这些细节不需要你都实现得很重只要在数据库设计、界面字段、查询条件里留出位置答辩时就是“业务理解深度”的证明。很多人的毕设被挑毛病恰恰是因为系统太“通用”看不出和题目里那个行业有什么关系。1.3 适合不同基础的同学可深可浅这个题目最好的地方在于难度梯度很友好。如果你Java基础一般可以做一个纯SSH或者SSM的单体Web项目JSP页面直接渲染把增删改查和权限做好就已经是一个合格的毕设了。如果你基础不错可以上Spring Boot MyBatis Thymeleaf把事务、报表、拦截器、异常处理做扎实。再往上走还能接一个微信小程序端做会员查询或者用ECharts做可视化大屏直接往“亮点功能”方向扩展。也就是说这个题目不会因为技术选型太浅而被毙掉也不会因为天花板太低而没有提升空间。对大多数同学来说这是一笔非常划算的“投入产出比”。2. 技术栈选型别一上来就卷微服务2.1 三代Java Web方案对比在正式写代码之前先把技术栈这件事聊透。每年都有学生上来就问“能不能用Spring Cloud微服务做”我的回答都是毕业设计不要为了技术而技术稳定的、能讲清楚的技术方案才是好方案。Java Web方向现在大致有三代方案方案组成特点适不适合毕设传统JSP方案JSP Servlet JDBC结构直观但代码冗余多现在公司很少这么写适合基础很弱的但不推荐SSM框架Spring Spring MVC MyBatis经典组合配置略繁琐但网上资料极多可以但属于上一代主流Spring Boot方案Spring Boot MyBatis/MyBatis-Plus起步快配置少当前企业主流强烈推荐我建议直接选Spring Boot。原因很简单Spring Boot把大量繁琐的XML配置变成了“约定优于配置”你写一个Controller、配一个数据源、加几个注解就能把接口跑起来省下来的时间可以去打磨业务逻辑和界面而不是耗在配置上头疼。2.2 前后端要不要分离这是近两年毕设里经常被问到的选择前后端分离Vue Spring Boot还是服务端渲染Thymeleaf Spring Boot我的观点是如果你是独立完成且没有系统的前端训练经历Thymeleaf这种服务端渲染方案更稳。前后端分离意味着你要同时维护两个工程要处理跨域、Token鉴权、接口联调、打包部署这些问题。任何一个环节出问题排查成本都翻倍。而Thymeleaf把页面模板直接放在后端工程里一个Spring Boot项目就能把增删改查完整跑起来少了层层沟通成本。当然如果你简历上明确写了“熟悉Vue”想在毕设里展示前后端分离能力那就用Vue Spring Boot的组合。答辩时老师会问“跨域怎么解决的”“权限怎么控制的”你需要提前准备好答案。能做出来就是加分项做一半卡住了就很尴尬。自己权衡实力再选。2.3 我推荐的基础组合与理由我给你的基础组合是Spring Boot 2.7.x MyBatis-Plus MySQL 5.7/8.0 Thymeleaf Bootstrap或Layui。用Maven管理依赖项目结构用标准的Controller-Service-Mapper三层。为什么不推荐纯MyBatis因为毕设的核心时间应该花在业务逻辑上MyBatis-Plus帮你把通用的单表CRUD都生成好了你只需要写那些真正有业务含义的SQL比如销售统计、库存扣减、报表查询。省出来的时间可以做更多页面和功能细节。为什么用Bootstrap而不是Element UI因为Thymeleaf模板里直接引入Bootstrap的CDN最快表格、表单、弹窗、标签页都有现成样式不需要学Vue组件那一套。Layui也同理它甚至内置了表格分页和表单验证做后台管理界面非常顺手。MySQL版本上如果你本机装的是5.7就用5.7不要为了“最新”去折腾8.0的认证插件问题。如果你新装数据库装8.0问题也不大但要注意驱动版本、时区参数配置后面第三节我会把容易踩的坑列出来。除了后端代码你还得准备一个趁手的数据库管理工具。Navicat、DataGrip、DBeaver都可以看个人习惯。这个项目里你会在建表、导数据、看查询结果上花不少时间一个能看到ER图、能直接执行SQL的客户端能帮你少走很多弯路。3. 功能模块拆解与数据库设计3.1 平台的核心功能模块销售管理平台虽然叫“销售管理”但实际功能需要覆盖商品、库存、销售、会员、报表五个方向。我按模块拆解给你看商品管理商品分类维护、商品信息维护名称、品牌、SPF值、适用肤质、容量、价格等、商品上下架。库存管理入库单进货入库、库存查询、库存预警低库存提醒、效期管理临期商品列表。销售管理收银台选择商品、计算金额、结算开单、销售记录查询、退货处理可选。会员管理会员信息维护手机号、姓名、等级、积分累计与消耗、会员折扣。系统管理管理员/收银员账号管理、角色权限、操作日志可选加分项。这五个模块之间有清晰的数据依赖关系商品是基础库存是商品的动态数量销售单引用商品并扣减库存会员给销售单带去折扣和积分报表统计销售单数据反过来指导进货。3.2 商品表设计做得专业和不专业差在哪商品表是整个系统的地基。多数人做商品表就三五个字段名称、类别、价格、库存。但你要做的是护肤品行业商品表就要把行业维度放进去。这是我建议的商品表结构CREATE TABLE product ( id int(11) NOT NULL AUTO_INCREMENT, code varchar(32) NOT NULL COMMENT 商品编码, name varchar(100) NOT NULL COMMENT 商品名称, category_id int(11) NOT NULL COMMENT 分类ID, brand varchar(50) DEFAULT NULL COMMENT 品牌, spf varchar(10) DEFAULT NULL COMMENT 防晒值如SPF50, pa varchar(10) DEFAULT NULL COMMENT PA等级如PA, skin_type varchar(50) DEFAULT NULL COMMENT 适用肤质, spec varchar(50) DEFAULT NULL COMMENT 规格容量如50ml, purchase_price decimal(10,2) NOT NULL COMMENT 进价, sale_price decimal(10,2) NOT NULL COMMENT 售价, stock_qty int(11) DEFAULT 0 COMMENT 当前库存, warn_stock int(11) DEFAULT 10 COMMENT 库存预警阈值, shelf_life_days int(11) DEFAULT NULL COMMENT 保质期天数, production_date date DEFAULT NULL COMMENT 生产日期, status tinyint(1) DEFAULT 1 COMMENT 状态 1上架 0下架, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意这几个字段的设计用意。code是商品编码前台扫码或者手动录入POS时需要一个唯一业务编码它和自增ID不同是给人看的、能对应到货架标签的。spf和pa是防晒品类特有的筛选字段如果不上防晒霜这个属性你的系统就撑不起“防晒护肤品店”这个题目。shelf_life_days和production_date配合能算出到期日这是效期预警功能的数据基础。warn_stock是每个商品独立的预警阈值大件商品卖得慢阈值可以设低一点热门防晒霜卖得快阈值设高一点。分类表也不要只做一个字段。我建议用二级分类体系一级分类是“防晒”“护肤”“洁面”“面膜”“彩妆”二级分类比如护肤下面再分“水乳”“精华”“面霜”。在分类表里加一个parent_id字段就能实现无限级分类前台筛选时可以按照一级大类进入然后按二级细分。3.3 销售单与库存的联动是核心中的核心销售模块是让整个系统活起来的环节它牵动的不只是一张表。一次完整的销售行为系统要做三件事生成销售主单、生成销售明细、扣减商品库存。所以销售设计至少要有两张表sale_order和sale_order_item。前者记录“谁在什么时间用哪种方式付了多少钱”后者记录“这单里包含哪些商品、每个商品多少钱、买了几个”。CREATE TABLE sale_order ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, member_id int(11) DEFAULT NULL COMMENT 会员ID, total_amount decimal(10,2) NOT NULL COMMENT 原价总额, discount_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, pay_method varchar(20) DEFAULT NULL COMMENT 支付方式现金/扫码/刷卡, operator_id int(11) DEFAULT NULL COMMENT 操作员ID, sale_time datetime DEFAULT NULL COMMENT 销售时间, remark varchar(255) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;主单字段里有个容易忽略的点订单号不要用数据库自增ID直接展示要按时间规则生成比如yyyyMMddHHmmss 三位随机数。原因很简单自增ID暴露订单数量而且不好看、不像真实系统。生成订单号的代码放在Service层用时间和随机数拼出来就可以了。明细表order_item记录下单时商品快照即可包括当时的价格这样以后查询这张单的时候即使商品表价格改了历史单据里看到的价格还是成交时的数字。这是电商系统非常基础的设计原则但很多毕设里会忽略。库存联动是另一个关键点。这里的难点不是“写一个UPDATE语句”而是要确保“扣库存”这个动作不会超卖。用MyBatis-Plus实现时不要用“先查库存→判断库存是否足够→再UPDATE”的三步式因为并发场景下两个请求可能同时通过检查。正确做法是用一条带条件的UPDATE原子完成扣减UPDATE product SET stock_qty stock_qty - #{qty} WHERE id #{productId} AND stock_qty #{qty}如果影响行数为0说明库存不足直接抛异常返回“库存不足”。配合Spring的Transactional事务注解保证订单写入和库存扣减要么都成功要么都回滚。这段逻辑虽然代码量不大但能把“并发安全”“事务”两个概念讲得明明白白是答辩时很出彩的一段。3.4 会员与折扣逻辑的数据库表达会员模块不只是存一个手机号和姓名它要能支持“积分累计”和“会员打折”这两个在护肤品门店常见的运营动作。会员表至少要有这些字段手机号一般作为登录账号、姓名、会员等级、累计积分、折扣率、创建时间。会员等级和折扣率怎么设计最简单的方式是直接在会员表里放一个discount_rate字段比如0.95表示95折。会员等级可以作为另一个字段普通会员/银卡/金卡也可以用一张独立的等级表来维护“等级与折扣率”的对照关系。对于毕设来说直接用一个字段存折扣率是最可控的方案。在生成销售单时判断当前单是否有会员ID有会员就按折扣率计算优惠金额同时给会员加积分。积分的规则可以写死每消费1元累计1积分积分表可以单独做也可以在销售单表里加一个points_earned字段。简化方案是后者因为积分要跟着订单走完全可以用字段记录这次消费产生了多少积分要查“某人总积分”时SUM一下就出来了。会员登录这块我建议用手机号密码或者手机号验证码的简化版密码写死为初始密码演示时直接输入手机号就能查到会员信息不要过度设计到短信验证因为毕设环境根本没有短信服务商搞一套假的反而画蛇添足。4. 核心功能实现与踩坑实录4.1 登录鉴权与权限控制用最经典的方式实现管理系统的登录鉴权在Spring Boot里最经典也最好讲的方式是“Session 拦截器”。管理员登录成功后把用户信息放进Session然后写一个拦截器拦截所有需要登录的URL没有Session就跳回登录页。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(loginUser); if (user null) { response.sendRedirect(/login); return false; } return true; } }注册拦截器时放行登录页、登录接口、静态资源其他/**路径全部拦截。这个方案代码少、好理解、答辩也好讲。有些同学一上来就上Spring Security或者Shiro结果配了一周还没跑通完全没必要。权限上可以再做轻量的一层管理员和收银员两个角色。菜单和功能入口根据角色判断是否显示比如“系统管理”模块只有管理员能进。Service层可以通过Session里的用户角色来判断操作是否被允许不用做成复杂的RBAC权限表那样会拖慢开发进度。这里有个很容易踩的坑Session序列化问题。如果你把整个用户对象放进Session而实体类没有实现Serializable某些容器环境下部署会报错。解决办法很简单用户实体实现Serializable接口或者只往Session放一个用户ID和用户名这种轻量数据。4.2 销售结算购物车到订单的完整链路销售收银台是这个系统的门面流程大致是选择商品加入购物车购物车可以用ListCartItem放在Session里不用建表→ 结算页面显示购物车清单、计算合计 → 提交订单 → 生成销售主单、明细、扣库存、累加会员积分 → 清空购物车。购物车放Session是毕设里合理的简化方案因为收银台是单机操作不需要跨终端共享购物车。但提交订单的后端方法必须放在Service层加上Transactional这样才能保证四步操作的一致性。下面是一个简化版的核心代码逻辑Transactional(rollbackFor Exception.class) public SaleOrder createOrder(SaleOrderDTO dto) { // 1. 生成订单号 String orderNo generateOrderNo(); // 2. 计算金额遍历购物车明细累加原价总额 BigDecimal total BigDecimal.ZERO; for (CartItem item : dto.getItems()) { total total.add(item.getPrice().multiply(new BigDecimal(item.getQty()))); } // 3. 会员折扣如果有会员按折扣率计算实付金额 BigDecimal payAmount total; if (dto.getMemberId() ! null) { Member member memberMapper.selectById(dto.getMemberId()); payAmount total.multiply(member.getDiscountRate()).setScale(2, RoundingMode.HALF_UP); } // 4. 插入主单、明细 // 5. 扣减库存逐条执行带条件的 UPDATE库存不足则抛出异常触发回滚 return order; }商品价格这个问题也要注意结算时价格以哪里的为准应该以数据库中商品表的实时价格为准而不是用户加入购物车时页面上的价格。前端显示的价格只做展示后端在生成订单时重新从商品表查一遍价格这样可以防止“页面被抓包修改价格”这种问题。虽然毕设不涉及真实攻击但这个逻辑体现的是正确的前后端信任边界。订单生成后页面不要跳转到一个简单的“提交成功”而是跳到订单详情页显示订单号、实付金额、商品明细、找零信息如果演示支付方式是现金。这页做得好看演示录像会很出彩。4.3 报表统计靠几张SQL撑起来报表模块是吸引答辩老师注意力的地方。不用做得多复杂但要把“从数据里能看到业务”这个点体现出来。三个最经典的统计维度按日销售趋势查最近7天或30天每天的单数、销售额画成折线图。SELECT DATE(sale_time) AS sale_date, COUNT(*) AS order_count, SUM(pay_amount) AS sale_amount FROM sale_order WHERE sale_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(sale_time) ORDER BY sale_date;按品类销售占比关联分类表统计每个大类卖了多少金额、占比多少。按商品销售排行统计一段时间内卖出数量最多的Top10商品这个榜单一出来老板就知道哪些商品该补货、哪些该做活动。图表展示我推荐用ECharts。它支持折线图、柱状图、饼图后端只需要把SQL查出来的结果组装成JSON返回前端引入ECharts的CDN就能画图。不需要后端再引什么图表插件库。这里有一个实操细节ECharts要展示中文、加载数据需要等页面DOM渲染完成后初始化用th:inlinejavascript或者ajax从后端接口取数都行。我建议单独做一个/report/salesData接口返回JSON然后前端用fetch拉数据这样前后端数据格式清晰调试也方便。4.4 效期提醒与低库存预警两个细节功能撑起业务感这两个功能实现起来都很快但能显著提升系统完整度。低库存预警商品表里已经有warn_stock字段和stock_qty字段。库存管理页打开时查一遍所有stock_qty warn_stock且状态为上架的商品在顶部用红色警示条列出“以下商品库存不足”。MySQL的写法SELECT * FROM product WHERE status 1 AND stock_qty warn_stock;效期预警根据production_date和shelf_life_days算出到期日查到期日在未来90天内的商品。这里一定要在Java里算好日期边界再查询不要在SQL里做复杂的日期函数Java的LocalDate处理起来更直观也方便答辩时说清楚逻辑。LocalDate deadline LocalDate.now().plusDays(90); // 到期日 production_date shelf_life_days // 条件到期日在今天和 deadline 之间这两个功能在演示时只要提前插入几条测试数据在页面上就会看到“库存预警3条、临期商品2条”的提示。评委一看就会觉得“这个系统考虑得挺细”成本极低但收益很高强烈建议大家别跳过。5. 本机部署、演示录像与“白嫖源码”的正确用法5.1 环境版本与启动顺序最容易卡住新手的三关很多同学源码拿到了第一步就卡在“跑不起来”。这个项目涉及的环境大概是JDK 8或11、MySQL 5.7或8.0、Maven 3.6、IDEA或Eclipse。启动顺序是先启动MySQL并导入数据库脚本再修改Spring Boot的application.yml里的数据库账号密码然后运行启动类最后浏览器访问http://localhost:8080。这里有几个高频坑第一个是MySQL 8.0的驱动问题。application.yml里的驱动类要写com.mysql.cj.jdbc.DriverURL里要带serverTimezoneAsia/Shanghai否则会报时区错误。很多人卡在这里一整天其实就是一行配置的事。第二个是端口占用。8080被占用了改server.port换一个就行别硬着头皮杀进程容易把别的服务误杀掉。第三个是数据库脚本导入失败。要保证数据库的字符集是utf8mb4导入前先执行CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARSET utf8mb4;否则中文注释可能乱码或者导入报错。5.2 演示录像应该录什么录多长演示录像说白了就是“你给评委表演这个系统怎么用”的录像。有的人录了半小时全是鼠标点来点去效果反而不好。我建议录6到10分钟按下面的顺序开场10秒把系统标题、登录页面露出来自报家门说一句“这是防晒护肤品店销售管理平台”。登录环节演示管理员登录进入后台后先在系统管理里新建一个收银员账号然后退出用新账号登录。这30秒展示了账号管理功能和权限概念。商品环节新建一个分类“防晒”添加一支防晒霜SPF50、PA、50ml、售价198元再改一下库存和预警值。这一分钟展示了表单设计和字段专业度。销售环节把刚建的商品加入购物车故意多填数量触发库存不足提示再把数量改回正常。然后添加或者选择一个会员让会员享受95折最后结算生成订单。这是最核心的演示建议给两分钟把这个过程的每一步讲清楚。库存与报表环节演示库存预警列表和临期提醒然后去看销售日报、品类占比图、商品销量排行。最后回到销售记录页展示刚才那笔订单的明细和金额。录像时注意不要录代码编译过程不要录你怎么改配置把这些都提前弄好。录制时说话声音要清晰语速放慢每做一步就说一句“这一步做了什么、为什么做”。录像比现场演示最大的优势是你可以反复剪辑把最好的版本放出来。5.3 “白嫖源码”之后千万别直接交网上说“白嫖源码”听着很爽但我必须提醒你一句源码拿到手接下来几天的功课一点不能少。第一把源码完整跑通。不要只跑演示录像里那几个功能你要把每个菜单都点一遍搞清楚每个功能对应的Controller是哪个、Service做了什么事。第二把关键代码自己敲一遍。商品管理、销售订单、库存扣减这三段逻辑一定要能不看源码自己写个大概因为答辩时老师极大概率会问“库存是怎么扣的”“订单和明细是怎么保存的”。第三在项目里加上一点自己的东西。系统名改一改、主题色调改一改、把某个报表维度换成自己的理解这些“二次创作”能让你在查重和论文里更有底气。有个很现实的规律凡是直接在答辩时照着念源码的基本都会被追问到露馅凡是认真把代码走读一遍、能讲清楚设计逻辑的哪怕功能做得简单点分数也不会低。源码只是一个起点真正属于你的是你对它理解和改造的部分。6. 一个题目的多种做法Python、PHP、小程序与大数据方向6.1 其他技术栈怎么选怎么改这个销售的业务模型是可以平移到其他技术栈的。如果你不是Java方向拿到的是Python或者PHP版本核心思路不变只是实现工具换了。Python版如果用的是Flask或Django商品表、订单表、会员表的设计完全可以参考上面的SQL结构。Python这边的优势是写数据库脚本和生成报表方便Pandas处理统计数据非常顺手。PHP版用ThinkPHP框架的话数据库设计和模块划分也基本一致模板渲染用自带的模板引擎就行。关键是搞清楚你拿到的版本是什么框架、数据库脚本是哪个文件别用Java的思维去硬套Python的工程结构。6.2 小程序端能做什么怎么加如果你有Java后端基础在小程序上做一个“护肤会员中心”是不错的扩展方向。它可以实现三个功能会员登录手机号密码、查看积分和会员等级、浏览商品列表和商品详情含SPF值、肤质信息。小程序端通过HTTP请求访问后端接口遇到两个技术问题一是接口鉴权小程序登录后需要后端返回一个Token可以用简单的UUID或者JWT后续请求带在请求头里二是跨域后端要开启CORS配置否则浏览器调试时会拦截。这块内容加上去项目整体就从“管理系统”升级成了“后端管理平台 移动端会员服务”答辩时直接把小程序页面切出来演示说服力非常强。6.3 爬虫大数据方向得注意边界如果你收到的是“爬虫大数据”方向的衍生版本常见做法是采集公开的护肤品价格数据和用户评价做价格趋势分析和商品热度分析。比如爬取主流电商平台某几款防晒霜公开的价格历史数据或者采集社区评论做词频分析看“清爽”“不油腻”“敏感肌可用”这些关键词的出现频次。做这个方向有一个重要的边界必须守住只采集公开的、非个人隐私的数据遵守网站的robots协议不涉及用户个人信息、不绕过访问限制、不抓取非公开接口。毕设只是证明你掌握了数据采集、清洗、分析和可视化这一套流程不需要去碰灰色地带。强调一下合规永远是底线用公开合法的数据源同样能完成一套漂亮的数据分析报告。最后的几句心里话我见过太多人把毕设当成“过关任务”最后交上去一个自己都讲不清楚的系统。其实做一件能讲明白的小事远比做一个半吊子的“大系统”有价值。这个防晒护肤品店销售管理平台难度适中、业务真实、可扩展性强你把它吃透不仅答辩能过以后找工作面试聊项目时它也是一个能拿得出手的实战案例。给你留一个百试百灵的答辩小技巧提前准备一笔“演示数据”把库存设成低于预警值的状态把一支防晒霜的生产日期设成一年前这样演示库存预警和效期提醒时一进页面就有红色提示跳出来不用现场手忙脚乱地造数据。这种提前埋好的演示细节评委看了会觉得你是真的自己动手调过、用过这个系统而不是拿了源码就交差。 Spring Boot实战：防晒护肤品店销售管理平台毕设全解析
三月份这个节点很多计算机专业的大四学生已经开始正式动工毕设了。如果你正好拿到“防晒护肤品店销售管理平台”这个题目或者正在找一个能用Java稳定落地、答辩又能讲出东西来的管理系统选题那这篇博客应该能帮你省下不少折腾时间。我会从选题逻辑、技术栈选型、数据库设计、核心功能实现、常见坑位这几个角度把这个项目彻底拆开来讲最后再聊聊演示录像录什么、答辩时怎么讲才不会被问住。先说一句实在话毕设项目不是越复杂越好而是越“自洽”越好。所谓自洽就是题目、功能、技术方案、演示效果四条线能串成一条完整的故事线。防晒护肤品店销售管理平台这个题目正好符合这个标准——它既不是那种烂大街的“学生管理系统”“图书管理系统”业务场景又足够具象防晒、护肤、SPF值、适用肤质、效期管理这些行业细节能让你的设计和答辩内容自动拉开差距。1. 选题逻辑为什么这个题目值得做1.1 业务场景天然匹配管理系统的核心套路任何一个销售管理系统跑不出“商品管理、库存管理、销售管理、会员管理、统计报表”这五件事。防晒护肤品店的业务场景恰好把这五件事全部覆盖了而且每件事都有自己独特的业务约束。举个例子一般的图书管理系统商品只有“书名、作者、价格”几个属性CRUD写来写去就那些套路。但护肤品店不一样一支防晒霜除了名称和价格还必须维护SPF值、PA等级、适用肤质、净含量、生产批号、保质期这些维度。这意味你的商品表设计比教科书上的例子更真实你的界面表单比普通的“名称价格”更有内容你做出来的系统一眼看过去就知道是“为这个行业定制的”而不是拿模板改的。从答辩角度来说这个题目也很好讲。评委老师即使完全不懂Java他也买过防晒霜他能理解“夏天防晒霜卖得好所以要搞促销”“临期商品要提醒下架”这些业务逻辑。你不需要费半天劲解释“这个系统到底解决了什么”业务本身就已经给出了答案。1.2 行业细节是天然的答辩加分项防晒护肤品这个细分领域有几个让系统设计变得“有灵魂”的特性。第一是商品属性的多样化。防晒类目有SPF值防晒指数和PA等级防晒强度护肤类目有适用肤质油性、干性、敏感肌还有容量规格30ml、50ml、100ml、质地乳液、霜、喷雾。这些属性在筛选和展示时都需要进入查询条件意味着你的系统不是简单的全表SELECT而是有组合筛选逻辑的。第二是效期管理。化妆品是有保质期的正规门店对临期商品一般指剩余保质期不足6个月要单独管理。这在系统里就是一个很自然的预警功能设定一个预警阈值每天扫描库存里剩余效期不足N天的商品生成提醒列表。这个功能写起来不难但它体现的是“你懂这个行业的真实痛点”而不是只会写代码。第三是季节波动。防晒品类的销售有明显的季节性夏天是旺季冬天是淡季。这就可以引出销售统计里的“按月销售趋势”“品类销售占比”这些报表维度让统计模块有话可讲。这些细节不需要你都实现得很重只要在数据库设计、界面字段、查询条件里留出位置答辩时就是“业务理解深度”的证明。很多人的毕设被挑毛病恰恰是因为系统太“通用”看不出和题目里那个行业有什么关系。1.3 适合不同基础的同学可深可浅这个题目最好的地方在于难度梯度很友好。如果你Java基础一般可以做一个纯SSH或者SSM的单体Web项目JSP页面直接渲染把增删改查和权限做好就已经是一个合格的毕设了。如果你基础不错可以上Spring Boot MyBatis Thymeleaf把事务、报表、拦截器、异常处理做扎实。再往上走还能接一个微信小程序端做会员查询或者用ECharts做可视化大屏直接往“亮点功能”方向扩展。也就是说这个题目不会因为技术选型太浅而被毙掉也不会因为天花板太低而没有提升空间。对大多数同学来说这是一笔非常划算的“投入产出比”。2. 技术栈选型别一上来就卷微服务2.1 三代Java Web方案对比在正式写代码之前先把技术栈这件事聊透。每年都有学生上来就问“能不能用Spring Cloud微服务做”我的回答都是毕业设计不要为了技术而技术稳定的、能讲清楚的技术方案才是好方案。Java Web方向现在大致有三代方案方案组成特点适不适合毕设传统JSP方案JSP Servlet JDBC结构直观但代码冗余多现在公司很少这么写适合基础很弱的但不推荐SSM框架Spring Spring MVC MyBatis经典组合配置略繁琐但网上资料极多可以但属于上一代主流Spring Boot方案Spring Boot MyBatis/MyBatis-Plus起步快配置少当前企业主流强烈推荐我建议直接选Spring Boot。原因很简单Spring Boot把大量繁琐的XML配置变成了“约定优于配置”你写一个Controller、配一个数据源、加几个注解就能把接口跑起来省下来的时间可以去打磨业务逻辑和界面而不是耗在配置上头疼。2.2 前后端要不要分离这是近两年毕设里经常被问到的选择前后端分离Vue Spring Boot还是服务端渲染Thymeleaf Spring Boot我的观点是如果你是独立完成且没有系统的前端训练经历Thymeleaf这种服务端渲染方案更稳。前后端分离意味着你要同时维护两个工程要处理跨域、Token鉴权、接口联调、打包部署这些问题。任何一个环节出问题排查成本都翻倍。而Thymeleaf把页面模板直接放在后端工程里一个Spring Boot项目就能把增删改查完整跑起来少了层层沟通成本。当然如果你简历上明确写了“熟悉Vue”想在毕设里展示前后端分离能力那就用Vue Spring Boot的组合。答辩时老师会问“跨域怎么解决的”“权限怎么控制的”你需要提前准备好答案。能做出来就是加分项做一半卡住了就很尴尬。自己权衡实力再选。2.3 我推荐的基础组合与理由我给你的基础组合是Spring Boot 2.7.x MyBatis-Plus MySQL 5.7/8.0 Thymeleaf Bootstrap或Layui。用Maven管理依赖项目结构用标准的Controller-Service-Mapper三层。为什么不推荐纯MyBatis因为毕设的核心时间应该花在业务逻辑上MyBatis-Plus帮你把通用的单表CRUD都生成好了你只需要写那些真正有业务含义的SQL比如销售统计、库存扣减、报表查询。省出来的时间可以做更多页面和功能细节。为什么用Bootstrap而不是Element UI因为Thymeleaf模板里直接引入Bootstrap的CDN最快表格、表单、弹窗、标签页都有现成样式不需要学Vue组件那一套。Layui也同理它甚至内置了表格分页和表单验证做后台管理界面非常顺手。MySQL版本上如果你本机装的是5.7就用5.7不要为了“最新”去折腾8.0的认证插件问题。如果你新装数据库装8.0问题也不大但要注意驱动版本、时区参数配置后面第三节我会把容易踩的坑列出来。除了后端代码你还得准备一个趁手的数据库管理工具。Navicat、DataGrip、DBeaver都可以看个人习惯。这个项目里你会在建表、导数据、看查询结果上花不少时间一个能看到ER图、能直接执行SQL的客户端能帮你少走很多弯路。3. 功能模块拆解与数据库设计3.1 平台的核心功能模块销售管理平台虽然叫“销售管理”但实际功能需要覆盖商品、库存、销售、会员、报表五个方向。我按模块拆解给你看商品管理商品分类维护、商品信息维护名称、品牌、SPF值、适用肤质、容量、价格等、商品上下架。库存管理入库单进货入库、库存查询、库存预警低库存提醒、效期管理临期商品列表。销售管理收银台选择商品、计算金额、结算开单、销售记录查询、退货处理可选。会员管理会员信息维护手机号、姓名、等级、积分累计与消耗、会员折扣。系统管理管理员/收银员账号管理、角色权限、操作日志可选加分项。这五个模块之间有清晰的数据依赖关系商品是基础库存是商品的动态数量销售单引用商品并扣减库存会员给销售单带去折扣和积分报表统计销售单数据反过来指导进货。3.2 商品表设计做得专业和不专业差在哪商品表是整个系统的地基。多数人做商品表就三五个字段名称、类别、价格、库存。但你要做的是护肤品行业商品表就要把行业维度放进去。这是我建议的商品表结构CREATE TABLE product ( id int(11) NOT NULL AUTO_INCREMENT, code varchar(32) NOT NULL COMMENT 商品编码, name varchar(100) NOT NULL COMMENT 商品名称, category_id int(11) NOT NULL COMMENT 分类ID, brand varchar(50) DEFAULT NULL COMMENT 品牌, spf varchar(10) DEFAULT NULL COMMENT 防晒值如SPF50, pa varchar(10) DEFAULT NULL COMMENT PA等级如PA, skin_type varchar(50) DEFAULT NULL COMMENT 适用肤质, spec varchar(50) DEFAULT NULL COMMENT 规格容量如50ml, purchase_price decimal(10,2) NOT NULL COMMENT 进价, sale_price decimal(10,2) NOT NULL COMMENT 售价, stock_qty int(11) DEFAULT 0 COMMENT 当前库存, warn_stock int(11) DEFAULT 10 COMMENT 库存预警阈值, shelf_life_days int(11) DEFAULT NULL COMMENT 保质期天数, production_date date DEFAULT NULL COMMENT 生产日期, status tinyint(1) DEFAULT 1 COMMENT 状态 1上架 0下架, create_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意这几个字段的设计用意。code是商品编码前台扫码或者手动录入POS时需要一个唯一业务编码它和自增ID不同是给人看的、能对应到货架标签的。spf和pa是防晒品类特有的筛选字段如果不上防晒霜这个属性你的系统就撑不起“防晒护肤品店”这个题目。shelf_life_days和production_date配合能算出到期日这是效期预警功能的数据基础。warn_stock是每个商品独立的预警阈值大件商品卖得慢阈值可以设低一点热门防晒霜卖得快阈值设高一点。分类表也不要只做一个字段。我建议用二级分类体系一级分类是“防晒”“护肤”“洁面”“面膜”“彩妆”二级分类比如护肤下面再分“水乳”“精华”“面霜”。在分类表里加一个parent_id字段就能实现无限级分类前台筛选时可以按照一级大类进入然后按二级细分。3.3 销售单与库存的联动是核心中的核心销售模块是让整个系统活起来的环节它牵动的不只是一张表。一次完整的销售行为系统要做三件事生成销售主单、生成销售明细、扣减商品库存。所以销售设计至少要有两张表sale_order和sale_order_item。前者记录“谁在什么时间用哪种方式付了多少钱”后者记录“这单里包含哪些商品、每个商品多少钱、买了几个”。CREATE TABLE sale_order ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, member_id int(11) DEFAULT NULL COMMENT 会员ID, total_amount decimal(10,2) NOT NULL COMMENT 原价总额, discount_amount decimal(10,2) DEFAULT 0.00 COMMENT 优惠金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, pay_method varchar(20) DEFAULT NULL COMMENT 支付方式现金/扫码/刷卡, operator_id int(11) DEFAULT NULL COMMENT 操作员ID, sale_time datetime DEFAULT NULL COMMENT 销售时间, remark varchar(255) DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;主单字段里有个容易忽略的点订单号不要用数据库自增ID直接展示要按时间规则生成比如yyyyMMddHHmmss 三位随机数。原因很简单自增ID暴露订单数量而且不好看、不像真实系统。生成订单号的代码放在Service层用时间和随机数拼出来就可以了。明细表order_item记录下单时商品快照即可包括当时的价格这样以后查询这张单的时候即使商品表价格改了历史单据里看到的价格还是成交时的数字。这是电商系统非常基础的设计原则但很多毕设里会忽略。库存联动是另一个关键点。这里的难点不是“写一个UPDATE语句”而是要确保“扣库存”这个动作不会超卖。用MyBatis-Plus实现时不要用“先查库存→判断库存是否足够→再UPDATE”的三步式因为并发场景下两个请求可能同时通过检查。正确做法是用一条带条件的UPDATE原子完成扣减UPDATE product SET stock_qty stock_qty - #{qty} WHERE id #{productId} AND stock_qty #{qty}如果影响行数为0说明库存不足直接抛异常返回“库存不足”。配合Spring的Transactional事务注解保证订单写入和库存扣减要么都成功要么都回滚。这段逻辑虽然代码量不大但能把“并发安全”“事务”两个概念讲得明明白白是答辩时很出彩的一段。3.4 会员与折扣逻辑的数据库表达会员模块不只是存一个手机号和姓名它要能支持“积分累计”和“会员打折”这两个在护肤品门店常见的运营动作。会员表至少要有这些字段手机号一般作为登录账号、姓名、会员等级、累计积分、折扣率、创建时间。会员等级和折扣率怎么设计最简单的方式是直接在会员表里放一个discount_rate字段比如0.95表示95折。会员等级可以作为另一个字段普通会员/银卡/金卡也可以用一张独立的等级表来维护“等级与折扣率”的对照关系。对于毕设来说直接用一个字段存折扣率是最可控的方案。在生成销售单时判断当前单是否有会员ID有会员就按折扣率计算优惠金额同时给会员加积分。积分的规则可以写死每消费1元累计1积分积分表可以单独做也可以在销售单表里加一个points_earned字段。简化方案是后者因为积分要跟着订单走完全可以用字段记录这次消费产生了多少积分要查“某人总积分”时SUM一下就出来了。会员登录这块我建议用手机号密码或者手机号验证码的简化版密码写死为初始密码演示时直接输入手机号就能查到会员信息不要过度设计到短信验证因为毕设环境根本没有短信服务商搞一套假的反而画蛇添足。4. 核心功能实现与踩坑实录4.1 登录鉴权与权限控制用最经典的方式实现管理系统的登录鉴权在Spring Boot里最经典也最好讲的方式是“Session 拦截器”。管理员登录成功后把用户信息放进Session然后写一个拦截器拦截所有需要登录的URL没有Session就跳回登录页。public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object user request.getSession().getAttribute(loginUser); if (user null) { response.sendRedirect(/login); return false; } return true; } }注册拦截器时放行登录页、登录接口、静态资源其他/**路径全部拦截。这个方案代码少、好理解、答辩也好讲。有些同学一上来就上Spring Security或者Shiro结果配了一周还没跑通完全没必要。权限上可以再做轻量的一层管理员和收银员两个角色。菜单和功能入口根据角色判断是否显示比如“系统管理”模块只有管理员能进。Service层可以通过Session里的用户角色来判断操作是否被允许不用做成复杂的RBAC权限表那样会拖慢开发进度。这里有个很容易踩的坑Session序列化问题。如果你把整个用户对象放进Session而实体类没有实现Serializable某些容器环境下部署会报错。解决办法很简单用户实体实现Serializable接口或者只往Session放一个用户ID和用户名这种轻量数据。4.2 销售结算购物车到订单的完整链路销售收银台是这个系统的门面流程大致是选择商品加入购物车购物车可以用ListCartItem放在Session里不用建表→ 结算页面显示购物车清单、计算合计 → 提交订单 → 生成销售主单、明细、扣库存、累加会员积分 → 清空购物车。购物车放Session是毕设里合理的简化方案因为收银台是单机操作不需要跨终端共享购物车。但提交订单的后端方法必须放在Service层加上Transactional这样才能保证四步操作的一致性。下面是一个简化版的核心代码逻辑Transactional(rollbackFor Exception.class) public SaleOrder createOrder(SaleOrderDTO dto) { // 1. 生成订单号 String orderNo generateOrderNo(); // 2. 计算金额遍历购物车明细累加原价总额 BigDecimal total BigDecimal.ZERO; for (CartItem item : dto.getItems()) { total total.add(item.getPrice().multiply(new BigDecimal(item.getQty()))); } // 3. 会员折扣如果有会员按折扣率计算实付金额 BigDecimal payAmount total; if (dto.getMemberId() ! null) { Member member memberMapper.selectById(dto.getMemberId()); payAmount total.multiply(member.getDiscountRate()).setScale(2, RoundingMode.HALF_UP); } // 4. 插入主单、明细 // 5. 扣减库存逐条执行带条件的 UPDATE库存不足则抛出异常触发回滚 return order; }商品价格这个问题也要注意结算时价格以哪里的为准应该以数据库中商品表的实时价格为准而不是用户加入购物车时页面上的价格。前端显示的价格只做展示后端在生成订单时重新从商品表查一遍价格这样可以防止“页面被抓包修改价格”这种问题。虽然毕设不涉及真实攻击但这个逻辑体现的是正确的前后端信任边界。订单生成后页面不要跳转到一个简单的“提交成功”而是跳到订单详情页显示订单号、实付金额、商品明细、找零信息如果演示支付方式是现金。这页做得好看演示录像会很出彩。4.3 报表统计靠几张SQL撑起来报表模块是吸引答辩老师注意力的地方。不用做得多复杂但要把“从数据里能看到业务”这个点体现出来。三个最经典的统计维度按日销售趋势查最近7天或30天每天的单数、销售额画成折线图。SELECT DATE(sale_time) AS sale_date, COUNT(*) AS order_count, SUM(pay_amount) AS sale_amount FROM sale_order WHERE sale_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(sale_time) ORDER BY sale_date;按品类销售占比关联分类表统计每个大类卖了多少金额、占比多少。按商品销售排行统计一段时间内卖出数量最多的Top10商品这个榜单一出来老板就知道哪些商品该补货、哪些该做活动。图表展示我推荐用ECharts。它支持折线图、柱状图、饼图后端只需要把SQL查出来的结果组装成JSON返回前端引入ECharts的CDN就能画图。不需要后端再引什么图表插件库。这里有一个实操细节ECharts要展示中文、加载数据需要等页面DOM渲染完成后初始化用th:inlinejavascript或者ajax从后端接口取数都行。我建议单独做一个/report/salesData接口返回JSON然后前端用fetch拉数据这样前后端数据格式清晰调试也方便。4.4 效期提醒与低库存预警两个细节功能撑起业务感这两个功能实现起来都很快但能显著提升系统完整度。低库存预警商品表里已经有warn_stock字段和stock_qty字段。库存管理页打开时查一遍所有stock_qty warn_stock且状态为上架的商品在顶部用红色警示条列出“以下商品库存不足”。MySQL的写法SELECT * FROM product WHERE status 1 AND stock_qty warn_stock;效期预警根据production_date和shelf_life_days算出到期日查到期日在未来90天内的商品。这里一定要在Java里算好日期边界再查询不要在SQL里做复杂的日期函数Java的LocalDate处理起来更直观也方便答辩时说清楚逻辑。LocalDate deadline LocalDate.now().plusDays(90); // 到期日 production_date shelf_life_days // 条件到期日在今天和 deadline 之间这两个功能在演示时只要提前插入几条测试数据在页面上就会看到“库存预警3条、临期商品2条”的提示。评委一看就会觉得“这个系统考虑得挺细”成本极低但收益很高强烈建议大家别跳过。5. 本机部署、演示录像与“白嫖源码”的正确用法5.1 环境版本与启动顺序最容易卡住新手的三关很多同学源码拿到了第一步就卡在“跑不起来”。这个项目涉及的环境大概是JDK 8或11、MySQL 5.7或8.0、Maven 3.6、IDEA或Eclipse。启动顺序是先启动MySQL并导入数据库脚本再修改Spring Boot的application.yml里的数据库账号密码然后运行启动类最后浏览器访问http://localhost:8080。这里有几个高频坑第一个是MySQL 8.0的驱动问题。application.yml里的驱动类要写com.mysql.cj.jdbc.DriverURL里要带serverTimezoneAsia/Shanghai否则会报时区错误。很多人卡在这里一整天其实就是一行配置的事。第二个是端口占用。8080被占用了改server.port换一个就行别硬着头皮杀进程容易把别的服务误杀掉。第三个是数据库脚本导入失败。要保证数据库的字符集是utf8mb4导入前先执行CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARSET utf8mb4;否则中文注释可能乱码或者导入报错。5.2 演示录像应该录什么录多长演示录像说白了就是“你给评委表演这个系统怎么用”的录像。有的人录了半小时全是鼠标点来点去效果反而不好。我建议录6到10分钟按下面的顺序开场10秒把系统标题、登录页面露出来自报家门说一句“这是防晒护肤品店销售管理平台”。登录环节演示管理员登录进入后台后先在系统管理里新建一个收银员账号然后退出用新账号登录。这30秒展示了账号管理功能和权限概念。商品环节新建一个分类“防晒”添加一支防晒霜SPF50、PA、50ml、售价198元再改一下库存和预警值。这一分钟展示了表单设计和字段专业度。销售环节把刚建的商品加入购物车故意多填数量触发库存不足提示再把数量改回正常。然后添加或者选择一个会员让会员享受95折最后结算生成订单。这是最核心的演示建议给两分钟把这个过程的每一步讲清楚。库存与报表环节演示库存预警列表和临期提醒然后去看销售日报、品类占比图、商品销量排行。最后回到销售记录页展示刚才那笔订单的明细和金额。录像时注意不要录代码编译过程不要录你怎么改配置把这些都提前弄好。录制时说话声音要清晰语速放慢每做一步就说一句“这一步做了什么、为什么做”。录像比现场演示最大的优势是你可以反复剪辑把最好的版本放出来。5.3 “白嫖源码”之后千万别直接交网上说“白嫖源码”听着很爽但我必须提醒你一句源码拿到手接下来几天的功课一点不能少。第一把源码完整跑通。不要只跑演示录像里那几个功能你要把每个菜单都点一遍搞清楚每个功能对应的Controller是哪个、Service做了什么事。第二把关键代码自己敲一遍。商品管理、销售订单、库存扣减这三段逻辑一定要能不看源码自己写个大概因为答辩时老师极大概率会问“库存是怎么扣的”“订单和明细是怎么保存的”。第三在项目里加上一点自己的东西。系统名改一改、主题色调改一改、把某个报表维度换成自己的理解这些“二次创作”能让你在查重和论文里更有底气。有个很现实的规律凡是直接在答辩时照着念源码的基本都会被追问到露馅凡是认真把代码走读一遍、能讲清楚设计逻辑的哪怕功能做得简单点分数也不会低。源码只是一个起点真正属于你的是你对它理解和改造的部分。6. 一个题目的多种做法Python、PHP、小程序与大数据方向6.1 其他技术栈怎么选怎么改这个销售的业务模型是可以平移到其他技术栈的。如果你不是Java方向拿到的是Python或者PHP版本核心思路不变只是实现工具换了。Python版如果用的是Flask或Django商品表、订单表、会员表的设计完全可以参考上面的SQL结构。Python这边的优势是写数据库脚本和生成报表方便Pandas处理统计数据非常顺手。PHP版用ThinkPHP框架的话数据库设计和模块划分也基本一致模板渲染用自带的模板引擎就行。关键是搞清楚你拿到的版本是什么框架、数据库脚本是哪个文件别用Java的思维去硬套Python的工程结构。6.2 小程序端能做什么怎么加如果你有Java后端基础在小程序上做一个“护肤会员中心”是不错的扩展方向。它可以实现三个功能会员登录手机号密码、查看积分和会员等级、浏览商品列表和商品详情含SPF值、肤质信息。小程序端通过HTTP请求访问后端接口遇到两个技术问题一是接口鉴权小程序登录后需要后端返回一个Token可以用简单的UUID或者JWT后续请求带在请求头里二是跨域后端要开启CORS配置否则浏览器调试时会拦截。这块内容加上去项目整体就从“管理系统”升级成了“后端管理平台 移动端会员服务”答辩时直接把小程序页面切出来演示说服力非常强。6.3 爬虫大数据方向得注意边界如果你收到的是“爬虫大数据”方向的衍生版本常见做法是采集公开的护肤品价格数据和用户评价做价格趋势分析和商品热度分析。比如爬取主流电商平台某几款防晒霜公开的价格历史数据或者采集社区评论做词频分析看“清爽”“不油腻”“敏感肌可用”这些关键词的出现频次。做这个方向有一个重要的边界必须守住只采集公开的、非个人隐私的数据遵守网站的robots协议不涉及用户个人信息、不绕过访问限制、不抓取非公开接口。毕设只是证明你掌握了数据采集、清洗、分析和可视化这一套流程不需要去碰灰色地带。强调一下合规永远是底线用公开合法的数据源同样能完成一套漂亮的数据分析报告。最后的几句心里话我见过太多人把毕设当成“过关任务”最后交上去一个自己都讲不清楚的系统。其实做一件能讲明白的小事远比做一个半吊子的“大系统”有价值。这个防晒护肤品店销售管理平台难度适中、业务真实、可扩展性强你把它吃透不仅答辩能过以后找工作面试聊项目时它也是一个能拿得出手的实战案例。给你留一个百试百灵的答辩小技巧提前准备一笔“演示数据”把库存设成低于预警值的状态把一支防晒霜的生产日期设成一年前这样演示库存预警和效期提醒时一进页面就有红色提示跳出来不用现场手忙脚乱地造数据。这种提前埋好的演示细节评委看了会觉得你是真的自己动手调过、用过这个系统而不是拿了源码就交差。