企业官网建设流程全解析

做Java毕设选型的时候，我见过太多同学卡在同一个地方：电商管理系统觉得太老套，搞人工智能又怕hold不住，最后纠结到开题前两天才定方向。基于Spring Boot的大语言模型电商销售情况分析系统，恰好是这两者之间的一个平衡点——后端技术栈是成熟稳定的Spring Boot生态，创新点则由大语言模型来完成，既保证了毕设该有的工作量，又让答辩时有东西可讲。这个系统要解决的核心问题其实很实际：把电商后台的商品、订单、用户数据管起来，通过聚合统计算出销售趋势和经营指标，再让大语言模型充当一个"会看数据的智能助手"，用自然语言问答的方式帮运营人员快速获取数据分析结论。无论你是刚学完SSM框架的本科生，还是想给简历加亮点的研究生，这套系统的拆解过程都值得完整过一遍。

1. 选题拆解：三个关键词背后的真实需求

1.1 毕设项目的隐藏验收标准

先别急着看代码，做毕设和做公司项目的最大区别在于，毕设有一套隐形的验收标准。导师和评委不会真的把你部署到生产环境跑压测，他们看的是三件事：系统功能是否完整闭环、技术难度是否达到要求、答辩时你能不能把设计思路讲清楚。"基于Spring Boot的大语言模型电商销售分析系统"这个题目，正好把三件事都占了。

功能闭环方面，它不是一个单纯的CRUD后台，而是具备"数据输入—数据管理—数据分析—智能问答"的完整链路。商品、订单、用户数据进来之后，系统要做趋势统计、排行分析、类目占比，然后大语言模型基于统计数据回答"这个月哪个品类增长最快""库存低于安全线的商品有哪些"这类问题。技术难度方面，Spring Boot是主流Java框架，MyBatis-Plus、Redis、JWT这些组件覆盖了企业级开发常用技能点，而大语言模型集成又给系统加了一个"智能化"标签。答辩方面，每一个模块都有明确的"为什么这么做"可以讲，尤其是大语言模型的接入方式、Prompt设计、上下文管理，这些都是评委感兴趣的点。

1.2 功能边界：它到底需要做哪些页面

很多同学拿到题目后喜欢先画一个巨大的功能脑图，结果做三个月还没做完。我建议把功能边界砍到"够用且能演示"的程度。这套系统按角色划分，核心页面就这么几个：

• 管理员端：登录页、数据看板、商品管理、订单管理、用户管理、分类管理、销售分析报表、智能问答助手、公告管理。
• 普通用户端（可选）：商品浏览、下单、订单查看、个人中心。

如果你做的是前后端分离版本，管理员端的重点放在数据看板和智能问答两个页面；如果是服务端渲染版本，用Thymeleaf也能完成同样的功能，只是交互体验弱一些。关键要记住：毕设评审时，演示路径一般是"登录→看数据看板→查一个报表→打开智能问答问几个问题"，把这条主链路做顺，比堆砌十几个页面有用得多。

1.3 技术栈选择：为什么是Spring Boot打底

这里有一个很常见的误区，就是觉得题目里带"大语言模型"就一定要上Python。实际上，Java后端调用大语言模型能力毫无障碍，Spring Boot作为项目主框架反而更符合多数院校毕设的技术要求。我的建议技术栈是：

• 后端框架：Spring Boot 2.7.x，稳定、资料多、遇到问题好搜。
• ORM框架：MyBatis-Plus，单表CRUD基本不用写SQL，聚合查询自己写XML就行。
• 数据库：MySQL 5.7或8.0，存储业务数据；Redis，缓存登录Token和热点统计数据。
• 权限方案：Spring Security + JWT，或者简化用拦截器 + JWT，看你对Spring Security的熟悉程度。
• 前端：Vue 3 + Element Plus + ECharts，数据可视化和后台管理页面都靠它。
• 大语言模型：通过开放平台API接入，或本地部署开源模型后走HTTP接口，详见第三部分。

这套组合的优点是每一层都有海量教程，适合一个人独立开发。缺点是前后端分离版本的工作量会大一些，如果时间紧，可以在前端用现成的Admin模板，把精力留给后端分析逻辑和智能问答模块。

2. 数据库与指标口径：先把"分析"的底子打好

2.1 核心表结构：七张表足够支撑演示

电商销售分析系统的数据库设计，不需要模仿淘宝那样上百张表的复杂度，但订单明细和商品分类必须拆清楚，否则统计口径会乱。我常用的表结构如下：

订单表和明细表分开，是电商系统的常规做法。统计GMV时用订单主表，统计商品销量排行时必须走明细表，两张表通过order_id关联。为了演示效果好，可以在orders表加一个status字段，记录待支付、已支付、已发货、已完成、已取消五种状态，订单分析模块里可以做状态分布统计。

2.2 销售指标的计算口径：这些坑必须提前定清楚

"销售情况分析"具体分析什么？答辩时最怕的就是你说不清楚指标含义。建议系统里至少实现五个指标：

• GMV（成交总额）：统计时间范围内status为已完成或已支付的订单金额合计。注意，如果要做趋势图，按天分组统计时，要排除已取消订单。
• 订单量：时间段内的有效订单数，口径和GMV保持一致，别一个看取消一个不看取消。
• 客单价：GMV除以订单量，代表每单的平均消费金额。
• 商品销量Top10：从order_item表按product_id分组，sum(quantity)排序。
• 类目销售占比：先按product关联category_id，再按类目聚合GMV，用饼图展示。

计算口径一旦定了，就必须在接口层统一。我见过有同学数据库里存了decimal的金额，Java端却用double做运算，结果报表出现0.00002这样的脏数据。金额计算一律用BigDecimal，聚合SQL里用SUM和ROUND，后端不轻易做浮点运算。

2.3 模拟数据：决定报表好不好看的关键一步

真实电商平台的数据你是拿不到的，毕设系统的报表要好看，就得靠模拟数据。这一步很多人不重视，随手写几行INSERT，结果趋势图是一条水平线，评委看一眼就失去兴趣了。

模拟数据生成有几个要点。第一，订单时间要覆盖至少连续90天，最好是近半年，这样趋势图才能看出起伏。第二，每天的数据量要有随机波动，比如设定一个基准值，用随机数在0.7到1.3倍之间浮动，再叠加周末效应，这样折线图自然有峰有谷。第三，商品价格和成本要有差异，别所有商品都卖99元。我建议写一个Java工具类，启动时用循环生成订单和明细，用Random控制数量和金额，一次性生成几千条数据，既能支撑分页查询，也不会让数据库膨胀。

3. 把大语言模型"接"进Spring Boot：两条可行路线

3.1 路线A：调用国内开放平台API，开发最快

我接过的毕设里，大多数同学选的是开放平台API这条路。国内主流的云厂商和大模型团队都提供HTTP接口，你只需要在Spring Boot里用RestTemplate或WebClient发起请求即可。这里有一个关键点：把模型的配置信息放到application.yml里，不要硬编码到代码中。

ai: api-key: your-api-key model: chat-model-name base-url: https://api.example.com/v1/chat/completions timeout: 60

调用层封装一个ChatService，核心方法就两个：发送单条消息、发送带上下文的会话消息。用RestTemplate的时候，一定要设置连接超时和读取超时，我建议读取超时至少给60秒，因为大模型生成长文本确实慢，默认的5秒几乎必超时。还有一个容易被忽略的点：大模型API的返回结构在不同厂商之间略有差异，封装时先定义一个统一的返回对象，解析出content字段，别让Controller层直接操作JSON字符串。

3.2 路线B：本地部署开源模型，零成本但吃配置

如果学校不允许外接网络API，或者你想在答辩中强调"本地部署"，那就在自己电脑上跑一个开源模型。做法是先用推理框架（比如带Web界面和HTTP接口的本地推理工具）加载一个量化后的模型，它默认提供一个兼容的HTTP接口，Spring Boot只要把base-url指向本地端口就行。

本地部署的优点是数据不出内网、演示更可控，缺点是相当吃内存和CPU。以7B量级的量化模型为例，至少要16G内存才能流畅跑，4G显存的显卡基本只能跑小参数模型，生成速度在CPU上可能会到几十秒。我的建议是：演示时提前把模型加载好，并预热一次；如果在答辩现场等一分钟模型才吐出第一句话，气氛会比较尴尬。所以如果你的机型配置普通，优先选路线A。

3.3 Prompt设计与上下文管理：决定"智能感"的关键

大语言模型接入系统以后，能不能答出有价值的话，完全取决于Prompt设计和上下文组织。很多同学把用户的问题直接丢给模型，然后拿那句"我是一个AI模型"的通用回答展示给评委，这肯定不行。

对于电商分析场景，我建议设计一个系统级Prompt，结构大致是：

你是一个电商业务分析助手。你会收到用户的自然语言问题，以及系统查询到的统计数据。 请基于统计数据分析问题，给出结论和建议。 回答要求： 1. 先用一句话直接回答核心问题。 2. 再列出关键数据作为依据。 3. 最后给出1-2条可执行的运营建议。 4. 如果问题不在已知数据范围内，明确说明无法回答，不编造数据。

真正调用模型时，把统计数据拼进user消息里。比如用户问"这个季度的销售趋势怎么样"，系统先执行SQL查出各月GMV和订单量，拼成一条文本："2025年第二季度各月GMV分别为：4月23.6万，5月28.1万，6月19.4万，订单量分别为..."，再让模型基于这些数据作答。这样模型就不会脱离你说的数据瞎编，回答看起来就像"系统自己分析出来"的。

会话历史存在chat_message表里，每次请求模型时取最近几轮。注意控制token数量，一般保留最近4到6轮即可，否则带着大量历史会让响应变慢，而且容易超出上下文限制。

3.4 避免"每次都问模型"的过度设计

一个常见的设计误区：把统计查询也交给大语言模型做，让模型直接生成SQL去执行。说实话，这个部署在毕设里性价比很低。模型生成SQL可能出错，出错后你还要二次校验，安全性也不好控制。更务实的方案是"先规则查询，后大模型总结"，也就是后端先用SQL把统计数据算好，模型只负责把数据翻译成人类友好的回答。

我建议把智能问答模块的流程做成这样：用户提问→请求到达Controller→先用正则或关键词做意图分类（比如"趋势""排行""类目"）→命中规则就查数据库，用真实数据回答问题→未命中的开放性问题，转给大模型自由回答。这个流程既保证了核心演示不出错，又让系统有了"智能问答"的能力，而且在答辩时能解释得很清楚：规则引擎保准确，大模型补泛化，两者结合。

4. 核心功能落地：登录、CRUD、统计报表与对话

4.1 登录认证：JWT + 拦截器，最省心的权限方案

如果你的Spring Security功底一般，我建议用"JWT + 拦截器"做一个轻量级方案，够用且容易讲清楚。用户登录成功后，后端生成JWT返回前端，前端把Token存到localStorage，每次请求放在Authorization头里；后端拦截器统一拦截需要认证的接口，解析Token并校验过期时间。

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行登录接口 // 从header取token，校验并解析用户信息放到request属性 // 校验失败时返回401，并写入统一响应结构 } }

这里有一个细节很多人踩坑：跨域请求时自定义请求头会触发OPTIONS预检请求，拦截器必须放行OPTIONS，否则前端会莫名其妙401。处理方式是在拦截器里加一个判断，如果请求方法是OPTIONS，直接返回true。

4.2 商品与订单模块：用MyBatis-Plus快速完成

商品管理和订单管理本质上是分页查询加状态修改，用MyBatis-Plus的IService自带方法就能解决。分页查询记得配置PaginationInnerInterceptor插件，然后通过Page对象接参。订单查询建议提供多条件组合筛选：订单号模糊查询、用户ID精确匹配、状态下拉选择、时间区间筛选，这些在Controller层用LambdaQueryWrapper就能拼出来。

订单状态流转稍微注意一下：普通用户下单后订单状态是"待支付"，管理员在后台可以修改为"已支付""已发货""已完成"，取消订单则要加一个校验，已完成和已取消的订单不允许再改状态。状态流转逻辑建议单独写一个OrderStatusService，用switch做状态机校验，而不是在Controller里散落一堆if判断。

4.3 统计报表接口：聚合SQL怎么设计

数据看板是整套系统的门面，这个页面的接口设计直接决定演示效果。我的做法是提供五个接口：

• /api/analysis/overview：返回今日GMV、今日订单量、总用户数、总商品数，左上角卡片展示。
• /api/analysis/trend?days=30：返回近30天的GMV和订单量趋势，ECharts折线图。
• /api/analysis/category-ratio：返回类目销售占比，饼图。
• /api/analysis/product-top?limit=10：商品销量Top10，横向条形图。
• /api/analysis/order-status：订单状态分布，环形图。

趋势接口是核心，SQL写法如下，按日期分组聚合：

<select id="selectTrend" resultType="map"> SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS ymd, SUM(total_amount) AS gmv, COUNT(*) AS order_count FROM orders WHERE create_time BETWEEN #{start} AND #{end} AND status IN ('paid', 'shipped', 'completed') GROUP BY ymd ORDER BY ymd </select>

如果查询区间有60天或90天，前端折线图点太多会密集，可以给接口增加一个granularity参数，按day返回日粒度，按month返回月粒度，后端用GROUP BY DATE_FORMAT(create_time, '%Y-%m')就行。写代码时还要注意：无订单的日期不会出现在聚合结果里，前端做图时最好在前端补全日期，或者用一条SQL动态生成日期序列，否则折线图会断点。

4.4 智能问答模块的接口设计

智能问答的前后端交互，我建议设计成流式效果，但实现时为了稳定，可以先做非流式。接口长这样：

POST /api/chat/send 请求体：{ "sessionId": 123, "message": "本月哪个品类卖得最好？" } 响应体：{ "reply": "...", "suggestions": [] }

后端逻辑分四步：先按sessionId查询会话是否存在，不存在则创建；再保存用户消息到chat_message；接着走意图分类和统计数据查询；最后把统计数据拼入Prompt调用大模型服务，保存模型回复并返回给前端。会话恢复功能别忘：前端打开历史会话时，后端返回该会话的完整消息列表，按时间排序渲染成气泡。

每次调用大模型API时，后端延迟会长一些，前端按钮要防重复点击，loading状态下禁止再次发送。如果后端做了异步处理，用WebSocket推送结果，那交互体验会好很多，但工作量明显增加，毕设阶段我建议先用同步方案，把稳定性放在第一位。

5. 部署、调试与文档：让毕设"拿得出手"

5.1 从零到一跑起来的最小环境

一个给评委演示用的系统，不能依赖你自己电脑上装了一堆软件的环境。我在帮同学调试时，第一步就是列一个最小依赖清单：

• JDK 1.8或11
• Maven 3.6+
• MySQL 5.7+，导入初始化SQL脚本
• Redis 5+
• Node.js 16+（仅前后端分离时需要）
• 大模型API密钥或本地模型服务

初始化脚本要注意，库里一定要包含库表创建语句和模拟数据，这样任何人拿到源码都能一键跑起来。写数据库连接配置时，不要把密码藏在代码里，用application.yml加环境变量的方式，默认值适合本地开发，部署到答辩电脑时再修改，这样演示时不会因为配置问题手忙脚乱。

5.2 高频报错的排查经验：能救命的几个点

毕设调试阶段的报错，反复出现的就那么几类，我直接列一张排查表：

这里重点说全局异常处理。我用@RestControllerAdvice统一捕获异常，返回结构设计为{code, message, data}，这样任何未预期的异常都能变成友好的响应。演示时最怕的就是页面突然抛一个红色堆栈错误，有了全局包装，即使真的出错，前端也能提示"系统繁忙"而不是贴一堆英文异常。

5.3 文档结构和答辩演示的节奏

源码加文档是毕设标配，很多同学把文档写成"操作手册"，这是不行的。标准的结构应该是需求分析、总体设计、详细设计、系统实现、系统测试、总结展望。你在文档里需要重点画好数据流图：从用户请求到Controller、到Service、到Mapper、到大模型接口，这能体现你对系统整体架构的理解。

答辩演示的顺序我建议固定成一条链路：先登录进系统，打开数据看板，展示今日概览和趋势图；然后进入商品/订单管理页，演示分页查询和状态修改；接着打开销售分析报表，切换几个图表；最后打开智能问答，依次问"本季度GMV趋势如何""销量最高的商品有哪些"，问完让模型给出运营建议。这样十分钟左右就能完整展示系统的全部能力，节奏紧凑，评委也没机会挑冷门功能。

6. 这套系统下一步能怎么改：我的几条个人建议

6.1 给数据看板加一个"导出Excel"

很多评委看完图表后会问"数据能不能导出"，如果你现场点出一个导出按钮，把当前报表变成Excel下载，印象分会上涨不少。实现上用Apache POI或者EasyExcel，在分析模块加一个导出接口，把趋势数据和商品排行数据写入Excel工作簿，通过HttpServletResponse输出xlsx文件。这个功能工作量不大，却能让系统看起来更像一个真正的企业应用。

6.2 把大语言模型的回答和数据图表联动起来

我在调试智能问答时发现一个有趣的优化方向：当用户问"最近30天的销售趋势如何"时，系统可以带着一个前端指令返回结构化结果，前端自动定位到趋势页并把日期范围设为最近30天，同时模型用文字给出分析结论。这种"文字回答+图表跳转"的联动体验，会让评委觉得系统是真的在"分析"，而不只是一个套壳对话窗口。

实现思路是给对话接口的返回体加一个payload字段，模型按约定输出JSON格式的图表配置，比如{chartType: "line", dateRange: "30"}，后端解析后传给前端，前端据此联动刷新ECharts。这一步做得好，演示的"科技感"会明显提升。

6.3 关于前后端分离的一点点经验

如果你选择Vue做前端，一定要把后端接口的URL前缀统一好，比如都用/api开头，然后在后端的application.yml配置好上下文路径。前端用axios封装请求时，设置baseURL为'/api'，再加上拦截器统一处理Token。这样的话可以避免在五十个页面里各写一份请求地址，后期改端口只需要改前端代理配置。

生产环境跑演示时，直接把前端打包后的dist目录交给后端托管也行，把Vue的静态资源放进Spring Boot的src/main/resources/static下，后端一个端口全搞定。但我不太推荐毕设答辩时这么做，因为一旦后端要重新打包，前端修改起来很麻烦。分离部署（后端8080、前端5173）虽然多一步跨域配置，调试迭代的速度却是最快的。

最后再分享一条我在辅导毕设时一直强调的体会：别贪多，把一条主链路打磨到极致，比堆十个半成品页面更能赢得认可。这套基于Spring Boot的大语言模型电商销售分析系统，真正的核心竞争力就在于"数据+大模型"的结合方式——用传统SQL保障分析结果可靠，用大模型提升分析结果的表达力。你自己动手把登录、数据管理、统计报表、智能问答四个环节走通之后，会发现Spring Boot没那么神秘，大语言模型接入也没那么玄乎，剩下的就是反复调试、写文档、准备答辩。如果你打算在这个题目基础上做定制扩展，我上面提到的导出Excel、图表联动、多轮会话管理，都是很好的加分方向。祝答辩顺利。