又到一年毕设季后台私信里“电商分析”“Spring Boot”这类词扎堆出现。前两年大家问的是“社区团购系统”“在线商城设计”今年风向明显变了——很多人在问同一个组合电商销售分析加上大语言模型用Spring Boot做后端能不能作为毕设以及这条路到底怎么走。我的看法是这个方向不但能做而且做的好了相当出彩。传统电商数据分析项目十个人里九个都是Spring Boot MySQL ECharts图表一拉报表一摆了事。你在这个成熟框架上引入大语言模型做一个“能对话的销售分析系统”工作量扎实、技术点新颖、演示效果好答辩老师也很难轻易挑出毛病。这篇文章我就把这个项目的里里外外拆开讲一遍包括技术选型的理由、数据库怎么设计、大模型怎么接、部署要注意什么、答辩会问什么全程按真实可行的实操思路来讲。1. 先把这个毕设看透它到底在做什么1.1 一句话说清项目定位这个系统可以理解为一个面向电商运营场景的数据分析后台加上一个“会聊天”的智能分析助手。传统的销售分析系统用户要看数据得自己选时间、选品类、看图表该看什么都是定死的。这个项目在传统功能基础上加了一个大语言模型驱动的对话分析模块用户直接在页面上输入自然语言问题比如“上个月华东区的销售额环比变化如何”系统先理解这句话背后的分析意图再查询数据库最后把结果用图表和自然语言总结呈现出来。整个系统包含完整的电商后台闭环商品管理、订单管理、用户管理、销售指标统计、趋势图表、热门商品排行、地域分布分析然后是作为亮点的LLM对话分析模块。你要交付的是一套能跑的源码、一份设计文档、部署说明和演示视频这也正是毕设要求的完整内容。1.2 适合谁做能解决什么问题如果你是准备做毕设的计算机相关专业学生尤其对Spring Boot有一定基础但又不想走老套的增删改查路线这个题目是个很好的“守正出奇”选择。守正是因为电商销售分析这个业务场景非常成熟网上资料多、逻辑清晰你不会陷入“不知道做什么功能”的困境出奇是因为大语言模型的引入让项目的技术含量提升一档从“工具人项目”变成“有思考亮点项目”。对于想通过项目学习Spring Boot和大模型整合方式的人来说这个题目也能帮你打通一条完整的实践链路。你会在一个真实业务场景里同时用到数据库设计、接口开发、前端可视化、外部API集成、异步处理、安全校验这些技术做完之后对整个开发的系统性理解会上一个台阶。2. 技术选型深度拆解为什么是Spring Boot加LLM2.1 为什么电商分析项目扎堆选Spring BootSpring Boot能在毕设和工业界双线通吃核心原因是它刚好踩在开发效率和工程规范的平衡点上。对比两代技术栈传统Spring框架光配置就要写一大堆XML而Spring Boot通过自动配置把大量样板代码消掉了几行配置就能起一个Web应用。对毕设来说这意味着你能把时间花在业务功能上而不是配置地狱里。再看生态Spring Boot集成了太多常用组件Spring Data JPA、MyBatis、Redis、Security几乎你能想到的企业级中间件都有对应整合方案。数据库连接池、事务管理、日志框架、定时任务这些东西默认就帮你接好了。如果你是一个大四学生学的是Java方向选Spring Boot肯定是阻力最小、收益最高的方案。还有一个容易被忽略的现实原因答辩方便。Spring Boot是国内绝大多数Java业务系统的主流选择当老师问“这套系统要上生产环境你觉得缺什么”这类问题时你能顺着企业真实技术栈讲下去比如走Nginx部署、加Redis缓存、用消息队列削峰。这种延伸讨论会让答辩内容丰富很多。2.2 大语言模型在这套系统里扮演什么角色很多人一开始听到“加了大语言模型的电商系统”第一反应是做个智能客服或者让它生成营销文案。这些想法不是不能做但作为毕设技术亮点不够聚焦。我实际做下来觉得最有价值也最适合毕设的功能是让大模型把用户的自然语言问题转换为系统中的数据查询再对结果做智能解读。这里我对比过三种实现方案把优缺点列出来语法直转方案让大模型根据数据表结构直接生成SQL后端执行。这种方案效果很“炸”用户随口一句“上月最赚钱的五款产品”模型就能拼出一条复杂SQL。但缺点同样明显安全性难控。模型一旦有自由发挥空间可能生成全表查询甚至输出带威胁的语句。毕设可以做但必须在外层加严格的白名单校验、关键词过滤、行数限制。意图路由器方案大模型不碰SQL只负责把用户的话翻译成预先定义好的分析意图。比如用户说“哪个品类退款多”模型识别出这是“品类退款分析”意图并抽取时间参数后端根据意图调用写好的统计Service。这个方案安全、稳代码可控也好讲清楚。结论解读方案后端先用普通统计代码算出结果比如算出来“7月销售额82万环比下降5%”然后把数字交给大模型让它写成一段通俗流畅的业务总结。本质是把大模型当“高级文案”。我的建议是毕设采用意图路由加结论解读的组合意图识别和参数抽取走模型数据查询走预定义接口最后的总结也交给模型。这样流程完整同时每一步都具备可解释性和可控性。2.3 单体还是微服务别给自己挖坑毕设这个体量微服务纯粹是自找麻烦。销售分析系统的用户量不大业务边界就那几个模块单体应用加合理的包结构完全够用。你不需要Eureka、OpenFeign、Gateway这些组件硬拆微服务只会让自己陷入服务间调用、分布式事务、配置中心这些无底洞反而把核心功能冲淡了。单体不代表代码可以乱摊。包结构建议按业务域划分controller 层接收前端请求处理参数service 层业务逻辑mapper 层数据库操作对接MyBatisentity 层数据库实体dto 层接口请求和响应对象common 包工具类、统一返回结果、异常处理llm 包大语言模型调用相关代码独立成一个模块config 包跨域配置、拦截器、Web配置把LLM相关代码单独放在一个包里是我特别想强调的一个细节。你答辩的时候可以说“大模型调用是一个独立模块不侵入原有业务代码后续替换模型服务商或者本地化部署只要改这一个模块就行”。这句话技术深度不高但展示了一种很重要的工程意识——模块化接耦老师对这点很有好感。3. 从零开始开发的核心功能模块3.1 数据层先解决有没有数据的问题一个电商分析系统如果没有数据就是空中楼阁。我见过不少同学把项目代码写完了数据库里只有测试用的三条记录结果图表拉出来空空荡荡销售趋势就是一条直线演示效果大打折扣。所以我强烈建议项目一开始就把“造数”这个环节做好。我常用的方案是写一个独立的数据生成器语言随意Java或Python都可以。核心工作就是随机生成近一年的订单数据字段要完整订单号、用户ID、商品ID、购买数量、订单金额、支付渠道、订单状态、下单时间、收货省份、城市。数据量建议控制在1万到5万条之间少了没有统计感多了查询会很慢影响现场演示的通畅程度。还有一个很关键的点造数不能纯随机要考虑业务规律。比如周末的订单量要比工作日高大促前后会出现高峰夏季的饮料类销量高、冬季的热饮销量高数码产品的价格高但销量少日用品的价格低但销量大。你把这些规则写进数据生成逻辑里生成的图表才有“真实感”演示的时候被问到数据来源你也可以说“这是根据电商平台运营规律模拟生成的业务数据”比说“我随便填的”强太多。3.2 销售分析模块指标体系和可视化怎么搭这个系统的核心指标体系基本围绕电商运营的常用维度设计销售总览GMV、订单总量、客单价、支付转化率、退款率趋势分析按日、周、月维度的销售额和订单量趋势品类分析各品类销售额占比、销量排行商品分析热销商品TOP10、滞销商品、高退货率商品地域分析各省份销售额分布、城市排行图表部分用ECharts就能覆盖这是目前生态最好、文档最全的前端图表库之一。折线图放趋势、饼图放品类占比、柱状图放对比、地图放地域分布各司其职。这里想提醒一句图表千万不用做得花里胡哨什么3D动态、特效动画不仅容易出bug还会显得失真。你答辩时能把一个折线图的横轴单位、纵轴指标、图例含义讲清楚比做十个炫技动画都更能体现理解深度。3.3 对话分析模块从“能聊天”到“能查数”这个模块是实现上最有意思也是提问最多的地方。我按流程把它拆成三步每一步你都要能在答辩时讲清楚里面发生了什么。第一步是意图识别。用户输入的问题是一串自然语言计算机不理解“最近卖的怎么样”这种表达。你需要把用户问题传给大语言模型同时给它一段“意图说明书”里面列出系统支持的所有分析类型比如销售额查询、销量排行、品类占比、退货分析、地域分布、趋势对比。模型的任务非常明确判断这句话对应哪个意图抽出时间参数、地域参数、品类参数返回一个结构化的JSON结果。这一步模型是思想中心负责理解。第二步是查询执行。后端拿到JSON后根据意图类型去调用对应的Service方法。比如意图是“品类占比”就调品类统计方法查数据库返回结果集。这个过程没有大模型参与响应快、结果准不会出现幻觉。第三步是结论生成。把查询结果拼成一段数据上下文连同用户原始问题一起再次发给大模型请求它生成一段自然语言总结。比如数据是“7月销售额82万环比下降5%数码类下降明显”模型的输出可能是“7月整体销售额为82万元较上月下降约5%主要受数码类商品销量下滑影响建议关注新品发布节奏和促销力度”。这个三步走方案的意义在于大模型不是一股脑包办所有事而是被放进了整个数据链路中承担它擅长的工作。这和企业实际落地LLM应用的方式是一致的既能完成智能对话又不会丢失查询的准确性和安全性。你在论文里完全可以把这个流程画成时序图专业度一下就上来了。3.4 用户权限和后台管理模块虽然销售分析是系统的主角但一个完整的系统还是要有后台管理功能否则显得太单薄。最基础的角色设计就是管理员和普通运营账号。管理员可以管理商品和用户查看全部数据运营账号只能看分析和对话模块不能修改基础数据。权限这块用拦截器就能解决不必Spring Security大动干戈。写一个拦截器定义好需要登录才能访问的路径校验Session或Token就行。前后端联调时跨域问题要在开发早期就处理好常见做法是后端配置全局CORS或者前端开代理转发。很多项目就是拖到联调当天才发现跨域报错慌慌张张排查半天这种低级问题会拉低整体进度。4. 数据库设计与核心接口规范4.1 表结构怎么设计核心表建议按下面的方式设计用户表用户ID、账号、密码、昵称、角色分类表分类ID、分类名称、父分类ID商品表商品ID、分类ID、商品名称、价格、库存、状态、上架时间订单表订单ID、订单号、用户ID、订单金额、支付渠道、订单状态、下单时间、支付时间订单明细表明细ID、订单ID、商品ID、商品名称、单价、数量、小计金额对话记录表记录ID、用户ID、用户问题、系统回复、识别意图、耗时、创建时间这里想重点说一下索引。很多同学设计表时不建索引数据量小的时候没什么感觉但一旦数据量上到几万条查询性能就拉胯了。当前业务下查询基本都是时间范围驱动所以订单表的下单时间字段必须建索引订单明细表经常根据订单ID和商品ID做关联统计建议建联合索引。你答辩时说“表结构设计时考虑了查询性能优化”并用索引说明这是加分细节。4.2 接口设计规范接口推荐走RESTful风格下面是我在实际项目里用的接口列表功能请求方式接口路径用户登录POST/api/auth/login销售总览GET/api/analysis/overview销售趋势GET/api/analysis/trend品类分析GET/api/analysis/category商品排行GET/api/analysis/hot-products地域分析GET/api/analysis/region对话分析POST/api/chat/query对话记录GET/api/chat/history所有接口的返回格式建议统一用Result包装类包含code、message、data三个字段。一开始偷懒返回裸数据后面对接大模块的时候再想统一错误处理就很痛苦。定义好统一结构以后前端的Axios拦截器也更好处理整个代码风格会规范很多。销售趋势接口通常要接收startTime、endTime、granularity三个参数granularity用来区分按日、按周还是按月聚合这个设计能看出你对业务功能的理解深度。4.3 异常处理与全局响应Spring Boot项目一定要处理全局异常否则每写一个接口都要写一套try-catch代码重复不说还容易漏。定义一个全局异常处理器把业务异常、参数校验异常、未知异常统一捕获在校验错误时把参数的错误信息返回给前端。再定义一个业务异常类在Service层直接抛出这个异常并附带错误信息代码里就不会到处是if-return null了。注意日志至少要打在Service层方便出问题时定位。4.4 大模型查询的安全风险这块是整个项目里要不要花心思的重点。如果你选择的是让大模型直接生成SQL的方案那安全措施必须到位。我给出三条硬性建议第一模型生成的SQL必须经过关键词黑名单校验禁止DELETE、DROP、UPDATE、ALTER这类破坏性语句禁止注释符。第二所有查询必须强制加行数限制默认只查前100条后面另外分页。宁可查询不全也不能让它放开查一张表。第三数据库账号权限必须分离给应用用的账号只开SELECT权限不允许有任何对生产数据的写操作权限。就算你用的是意图路由方案也要防范参数层面的风险。比如用户问“销售额”前端可能传一整年的数据查询范围后端必须限制时间跨度的范围比如最长查一年。这些安全策略写进设计文档的安全性分析章节论文内容也顺便充实了。5. 实操部署与演示准备5.1 环境要求与本地启动这个项目硬件要求不高普通开发机就能跑。软件环境基本这这样JDK 1.8以上、Maven、MySQL 5.7或8.0、前端用Node.js里npmRedis可加可不加看你是否做了缓存处理。大模型部分准备一个API key就行国内主流大模型服务商都有对外开放的接口申请流程很简单毕设用的免费额度基本够用。如果你不想用公共API也可以本地部署一些开源模型但我个人建议毕设场景优先选择公共API原因很现实速度快、稳定不用受限于本机显卡性能答辩现场也不会因为推理速度慢而陷入尴尬。所有调用逻辑封装在模块里以后想换成本地的也方便。启动流程一句话说建库导入SQL脚本改配置文件里的数据库连接和API key启动Spring Bootnpm install加npm run dev把前端跑起来浏览器访问登录。具体就这些。5.2 大语言模型接入的完整实现过程接入过程是开发中代码量比较集中的部分我按实际操作顺序拆解一下。申请API key后你首先需要一个HTTP客户端。用Hutool的HttpUtil或者Spring的RestTemplate都行核心功能是发送POST请求带上请求头、请求体和超时设置。然后定义请求体和响应体的Java结构请求体一般包含模型名称、消息列表、采样温度等参数响应体里提取文本内容字段。这两个结构体把API的输入输出映射成Java对象代码可读性会好很多。接下来写一个专门的llmService里面封装三个方法一个负责组装请求上下文、一个负责调用API、一个负责解析结果。控制器收到用户问题后调用这个ServiceService里按前面说的三步流程组织逻辑先调用意图识别方法拿到JSON再根据JSON调用数据查询Service最后把结果交给文本总结方法返回完整的回复。这样控制器的代码很干净业务也不和大模型API直接耦合。有一个很实际的经验调用大模型API时超时时间一定要显式设置。不同模型的响应速度差异很大有的接口简单问题也要十几秒如果不设超时体验极其折磨。建议连接超时3秒读取超时30秒。同时要做好前端loading态界面至少告诉用户“正在分析中”别让人干等着。5.3 演示视频怎么录才加分既然项目包含了演示视频那它就是老师和其他看资料的人对你的第一印象。我说几个录制时的建议页面先收拾干净中文标签写齐全别把开发时的默认文本留着。录制按真实使用顺序来登录页面输入账号进入总览先看关键指标切到折线图讲趋势点开品类分析看一眼饼图再进入对话分析模块输入准备好的问题。比如“这个季度退货率最高的品类是什么”展示系统如何理解意图如何输出图表和文字结论。每一个环节停留三五秒把核心信息展示清楚但不要等漫长的数据加载。整个视频控制在5到8分钟干净利落。事前可以在茶点时间多测几轮排除掉意料之外的超时或者异常报错。提前把操作步骤写一页脚本边操作边按步骤念效果最稳定。6. 常见问题与答辩经验分享6.1 开发过程中一定会踩的坑我用自己实际开发过程中的经验整理了一张问题速查表建议直接收着比对排查。常见现象可能原因解决办法对话接口请求超时大模型响应慢前端同步等待后端设置显式超时前端加loading超时返回兜底文案大模型返回JSON解析失败输出被截断或返回了多余文字限制输出长度解析前清洗截取最靠后的完整JSON片段图表区域空白时间参数传错或数据库无数据统一前端后端的时间工具类先检查数据库SQL能否查出数数据库连接失败服务未启动或账号密码不对写一个启动检查脚本先确认MySQL能连跨域请求被拦截前后端端口不同后端加全局CORS配置或前端起代理大模型消耗过快每次请求把系统全部上下文传入控制发送token量只传必要数据精简Prompt对话超时是我遇到最多的一个坑。大模型接口的响应时间真的不可控有时候一两秒有时候二十秒。如果前端不做处理用户会以为页面死了。比较讲究的方案是后端把对话请求放到线程池里异步执行先用一个“处理中”状态返回得到结果再主动通知。毕设里做简化版就采用同步接口加一个较长的超时但前端loading必须展示好。6.2 答辩老师最可能问的四个问题第一个问题几乎是必问的数据从哪来你的回答一定要干脆口径统一“销售数据是根据电商业务规律编写的模拟数据数量约几万条包含订单、商品、用户、地域等维度主要保障分析功能有充足的样本。”千万不要含糊其辞或者说“我老师给的”这种话这会瞬间拉低可信度。第二个问题很容易被问到大语言模型在这个项目里的作用是什么普通系统能不能做到你要强调核心差异传统BI系统只能看固定维度报表而本系统里用户可以用自然语言自由提问系统拆解意图并返回个性化分析结果。这就说明白了大模型的不可替代性。第三个问题也很常见模型答错了怎么处理最佳回答思路是承认误差存在强调系统通过限制分析范围和预定义意图把错误控制在有限范围内同时记录了完整对话日志方便以后用真实的会话数据做微调优化。诚实且有补救方案很加分。第四个问题考验你的综合理解调用大模型有成本如果生产环境用怎么办你可以提到每次请求的token数、成本估算、缓存常见查询、控制调用频率等优化策略。能说出这些说明你真的考虑过落地问题不是停留在“调用了API”表面。6.3 交代码前过一遍的自查清单最后一个实用建议在最终提交之前照着下面几条逐项检查前端接口地址不要写死要读取环境配置路由守卫要生效退出登录后要清除登录状态并跳转登录页静态资源打包装好能部署到服务器。后端统一异常处理生效日志打印覆盖Service层关键业务方法密码不能用明文存要做加密对话模块的超时和重试逻辑保证不炸配置文件里的API key不要提交到代码仓库。数据库索引是否已经建完整SQL是否符合分页要求数据初始化脚本是否能在全新的库直接跑通。演示环境换一台干净机器从头开始按部署文档走一遍确认文档里没有遗漏步骤。这条特别重要你自己电脑能跑不算部署成功文档能指导一台新电脑跑起来才算。说一点个人的体会。这个项目最大的难点从来不是某个单独的技术点而是所有环节串起来的整合能力。很多同学单独写接口很溜一到系统集成阶段就卡住——跨域、时间格式、字段命名不一致、依赖冲突各种奇奇怪怪的问题冒出来。应对方法就是老老实实从最小闭环开始搭先保证登录、查看列表、看图表、发一条对话、拿到回复这条主线能跑通然后再往上加细节。主线通了你心里就有底剩下的都是锦上添花。最后再分享一个能让你的项目明显加分的小技巧做对话功能时不要只用一两个标准问法测试。多准备一些口语化、容易让模型混乱的问法比如“上个月和这个月哪个赚得多”“XX商品现在卖得咋样”“帮我看看哪个地区最不爱买东西”。每更新一次意图识别Prompt就用这批用例回归一遍把测试结果整理成表格放在项目目录里。毕设设计文档里附上“对话功能测试用例表”这个细节多数项目都没有做过的基本都能留下好印象。如果后续还有精力可以给意图识别加一个本地规则兜底——大模型接口异常时自动切到简单关键词匹配方案演示时就不用担心意外状况了。