阿猴HOSEA最近帮一个学弟把美妆消费辅助决策网站这个毕设项目完整走了一遍，从需求分析到数据库设计，从核心代码到部署上线，整个过程踩了不少坑，也积累了一些真实可复用的经验。今天这篇就把整个项目的设计思路、核心实现和避坑点全部摊开来讲，项目本身的技术栈是JavaWeb方向的经典组合：JSP + Servlet + MySQL + Tomcat，适合正在做JavaWeb毕设、或者想找一个完整案例练手的朋友参考。项目我已经完整跑通，源码也整理好了，下面讲的内容全部来自实际操作，不是那种只贴截图不给代码的纸面教程。
1. 项目整体设计与技术选型逻辑
1.1 美妆消费决策这个场景到底在解决什么问题
先说需求背景。美妆护肤行业的商品信息严重不对称，同一个用户在不同平台看到的同一款精华液，价格能差出一倍，成分表里的各种化学名称普通人根本看不懂，小红书和淘宝评论区里的真实反馈又被水军和广告稀释得非常厉害。消费者在面对"该不该买""买哪个版本""什么价位合适"这些问题时，往往只能靠猜。
这个毕设项目的核心目标，就是把"消费决策"这个模糊的需求，拆解成几个可以量化的功能模块。我当时和学弟一起做需求梳理的时候，确定下来五个核心功能点：第一是美妆商品的分类展示与多维检索，让用户能快速从数千款商品中找到目标；第二是商品的详细档案，包括成分表、功效标签、适用肤质、价格区间等信息；第三是用户评价体系，允许注册用户对商品进行评分和文字评价；第四是消费辅助决策工具，这是项目的灵魂，通过成分安全度、性价比、口碑指数等多个维度给商品打分，输出"推荐指数"；第五是用户的收藏与购买清单管理，方便后续复购和比价。
这个定位在毕设答辩里非常讨巧，因为每个功能点都能对应到一个明确的技术实现，又不至于复杂到超出本科毕设的合理范围。
1.2 为什么选JavaWeb传统技术栈而不是Spring Boot
现在打开各大毕设网站，满屏都是Spring Boot + Vue的前后端分离项目，学弟当时也问我，要不要直接用Spring Boot，代码写起来更舒服，简历上也好看。我给他的建议是：如果你的题目明确写了"JavaWeb"，那就老老实实用JSP + Servlet + JDBCTemplate这套传统方案。
原因有三。第一，毕设题目是评审老师定的，题目里的"JavaWeb"在大多数老师的理解里就是JSP + Servlet这套东西，你交一个Spring Boot项目上去，技术对不上题目，答辩的时候很难自圆其说。第二，JSP + Servlet方案虽然老，但它把HTTP请求处理、页面渲染、会话管理这些Web开发最底层的逻辑暴露得非常清楚，写一遍下来你对JavaWeb整个运行机制的理解会比直接上框架深刻得多，这对于应对答辩提问非常关键，老师最喜欢问的"Servlet生命周期""Session和Cookie区别"这些问题，自己手写过一遍的人张口就能答。第三，从工作量角度，这套方案代码量适中，用Maven管理依赖，数据库用MySQL，前端页面用JSP + Bootstrap + ECharts，一个人两周左右能写完核心功能，时间成本可控。
当然，如果你的学校明确允许Spring Boot，那也可以用，架构上把Spring Boot理解成Servlet的封装升级就行，业务逻辑代码是可以平移的。这个后面会提一句怎么迁移。
1.3 技术栈清单与项目结构规划
项目最终采用的技术组合如下：
- JDK 8，这个版本兼容性最好，Tomcat 8.5/9.0都能跑，不推荐一上来就上JDK 17，有些老旧依赖会出问题。
- Tomcat 8.5，作为Servlet容器，部署简单，本地开发用IDEA嵌入式运行也行。
- MySQL 5.7，最稳定的版本，8.0的密码加密方式在JDBC连接时偶尔会多一个配置项，新手容易卡住，用5.7省心。
- JSP + JSTL + EL表达式做页面渲染，不引入额外的模板引擎。
- Servlet 3.0注解方式配置，不用web.xml写一大堆映射。
- JDBCTemplate + Druid连接池，数据库操作简洁且能避免频繁创建连接的性能问题。JDBCTemplate是Spring框架里的一个模块，这里单独引入spring-jdbc依赖即可，并不需要完整的Spring容器。
- Bootstrap 4 + jQuery + ECharts，负责前端布局、异步交互和数据可视化。
- Maven 3.6，管理依赖和打包。
项目结构上，我习惯按Maven的标准目录来组织，包名用com.example.beauty，下面划分controller、service、dao、entity、filter、util这几个包。webapp目录下放JSP页面和静态资源，admin和user分别放管理端和用户端页面，common放公共组件如头部导航栏、分页标签。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据库设计与数据模型构建
2.1 核心表结构设计思路
数据库是整个项目的底盘，表设计得好不好直接决定后面写业务代码是顺滑还是天天改SQL。我当时帮学弟建了六张核心表，外加一张管理员表，总共七张。
用户表的设计相对常规，字段包括用户ID、用户名、密码（MD5加密存储）、昵称、性别、邮箱、手机号、头像URL、注册时间、状态。这里有个小细节：密码存储一定不能明文，MD5加密成本最低，但一定要加盐，盐值直接用用户的注册时间戳就行，这样即使两个用户密码相同，加密后的密文也不同，能有效防止彩虹表攻击。
商品表是信息核心，字段比较多，我重点说几个设计要点。category_id外键关联分类表，brand字段单独拿出来而不是关联品牌表，因为初期品牌数据量不大，一个字符串字段扛得住；capacity表示规格容量，比如"30ml""50g"，这个字段要设计成varchar而不是数字，因为美妆产品的规格单位不统一，有的是毫升有的是克；price和market_price分别表示实际售价和市场价，用来计算折扣力度；sales_volume记录销量，用于排序；ingredient是成分表文本，用text类型存储，格式化成JSON字符串或者用分号分隔的成分列表。功效标签用tags字段，存储形式是逗号分隔的字符串，比如"补水,保湿,修复"，查询时用LIKE匹配即可。这种反范式设计在毕设场景下完全够用，不需要为了第三范式去拆一堆中间表出来。
2.2 决策辅助维度：评分模型的表字段支撑
评分模型是消费决策网站最有技术含量的部分，需要在表结构上提前预留好计算所需的原始数据。我当时在商品表里设置了六个评分相关字段：safety_score代表成分安全度，满分10分，这个分数可以基于成分表里是否有高风险成分做规则计算，比如包含酒精、香精、某些防腐剂就按比例扣分；effect_score代表功效评分，来自用户评价的平均分；price_score代表性价比评分，通过同品类价格对比算出来；brand_score代表品牌信任度，可以用品牌关注量或者平台权重模拟；sales_score代表市场热度，直接和销量正相关；favorite_score代表用户收藏偏好。这六个分数通过加权公式合成最终的综合推荐指数。
这里要重点说一个设计原则：原始数据字段和计算结果字段要分离。六个维度分数字段存的是原始数据，综合推荐指数在展示时通过service层实时计算，不落库。这样做的原因有两个，一是如果将来调整权重公式，不需要改历史数据，只改代码里的计算逻辑就行；二是展示的时候可以灵活组合，比如用户只想看"成分安全+性价比"两个维度，动态调整权重即可。
用户评价表是口碑模块的数据支撑，字段包括评价ID、用户ID、商品ID、评分（1到5的整数）、评价内容、购买渠道、是否匿名、创建时间。这里需要建立用户ID和商品ID的联合唯一索引，防止一个用户对同一商品重复评价，这个在代码层也要做二次校验，数据库约束和业务校验双保险。
收藏表相对简单，用户ID、商品ID、创建时间，同样做联合唯一索引。
购物车表和下单表如果要做，就要考虑订单状态流转，那会引入比较多的业务逻辑，比如待付款、已付款、已发货、已完成这些状态，还要管理库存扣减。考虑到毕设周期和答辩重点，我当时建议学弟把购物车做成"待购清单"的形式，不涉及库存和订单状态流转，只记录用户想买的东西，这样既满足"决策辅助"的定位，又不会让项目失控变成一个交易系统。
2.3 SQL初始化脚本的几个注意事项
数据库初始化脚本要放在项目根目录的sql文件夹下，在文档里写清楚"使用source命令或Navicat直接运行"。
字符集统一utf8mb4，排序规则用utf8mb4_general_ci，能正确存储表情符号和特殊字符。之前踩过一个坑，默认的utf8字符集存emoji表情会报错，后来全部改成utf8mb4就解决了。
时间字段用datetime类型，不要用timestamp，因为timestamp有2038年问题，而且在MySQL 5.7里两个timestamp字段的默认值设置比较麻烦。默认值用DEFAULT CURRENT_TIMESTAMP即可。
外键约束只保留了必要的部分，商品表到分类表的外键保留了，评价表到用户表和商品表的外键也保留了，但收藏表不建外键，原因是有外键约束后删除关联数据时容易报错，在毕设演示阶段操作不友好。这是个权衡，如果你追求逻辑严谨就都加上，如果图操作方便，程序层自己保证引用完整性就够了。
3. 核心业务逻辑与关键代码实现
3.1 用户模块：注册登录与会话管理
用户模块是任何Web项目的门面，美妆消费决策网站也不例外。注册流程上，除了常规的用户名、密码、确认密码、邮箱之外，我加了一个"护肤偏好"的多选字段，选项包括"油皮亲妈""干皮救星""敏感肌可用""成分党""平价党""贵妇线"等标签。这些标签收集之后会存到user_profile表的skin_type字段和preference_tags字段，后续在推荐商品和生成决策建议时，会按照用户的偏好标签对推荐指数做微调，比如偏好"平价党"的用户，性价比维度在加权公式里的权重会更高。这个设计在答辩时是一个很好的加分点，体现了"辅助决策"的个性化思路。
注册接口的服务端校验要覆盖以下内容：用户名不能为空、长度4到20位、只能包含字母数字和下划线；密码不能为空、长度6到20位、必须同时包含字母和数字；用户名唯一性校验，这要用数据库查询来验证，不能用前端校验代替；两次密码是否一致。全部通过后，用户密码加盐MD5存储，然后跳转到登录页面。
登录业务的处理分为两步：第一步是认证，根据用户名查库，比对密码；第二步是授权，登录成功后把用户ID、用户名、昵称、偏好标签存入Session，设置Session的有效期为30分钟。这里我用了一个过滤器AuthFilter做登录拦截，所有访问/user/*路径的请求都要先检查Session里是否有登录用户，没有就重定向到登录页。这个逻辑在web.xml里配置过滤器映射即可。
关于密码加密，我再补充一点。很多同学图省事直接MD5加密，但MD5本身是不可逆的，同时也非常容易被暴力破解。我的做法是MD5(密码 + 用户注册时间戳)以及循环两次加密，这种方式虽然算不上顶级安全，但在毕设场景下已经能挡住绝大多数安全质疑了。答辩时如果老师问"密码怎么加密存储的"，你把盐值的设计逻辑讲清楚，老师基本不会再追问。
3.2 商品模块：检索、分页与详情展示
商品列表是用户打开网站后最先接触的页面，这个模块的体验好坏直接影响对整个项目的第一印象。我在商品检索模块设计了三个维度的筛选条件：分类筛选，从分类表加载一级和二级分类，使用下拉框或者侧边栏展示；价格区间筛选，提供"0-100""100-300""300-500""500以上"四个档位；排序方式，包括综合推荐（推荐指数倒序）、销量倒序、价格从低到高、价格从高到低、最新上架。
对应的Service层查询方法需要动态拼接SQL。这里的实现技巧是使用JDBCTemplate的NamedParameterJdbcTemplate，通过Map参数来传值，避免字符串拼接SQL带来的SQL注入风险。排序字段不能直接拼接到SQL里，要用白名单方式校验，只允许传入预定义的几个字段名和排序方向，确保安全性。
分页是我认为这个项目里最值得认真写的一部分。JDBCTemplate没有内置的分页方言，需要手动拼LIMIT子句。封装一个PageBean对象，包含当前页码、每页大小、总记录数、总页数、数据列表这五个属性。查询时先执行count查询拿总数，再执行limit查询拿当前页数据。前端JSP页面上用JSTL的c:forEach遍历数据，用c:if控制分页按钮的显示和禁用状态。这里有个小细节容易被忽略：分页时一定要把当前的查询条件参数也拼接到分页链接里，否则点第二页的时候筛选条件就丢了，这是新手最常见的bug之一。
商品详情页展示的信息分三个区块：基本信息区放商品名、品牌、规格、价格、销量、主图；成分与功效区放成分表、功效标签、适用肤质；决策辅助区放六个评分维度的雷达图、综合推荐指数和推荐理由。详情页的数据来源是商品基础信息表，名称、价格、销量等查一次；决策辅助数据从六个评分字段计算后交给前端ECharts渲染雷达图。
3.3 决策辅助模块：综合推荐指数的计算公式
这是整个项目的核心模块，也是我认为最值得花时间写清楚的部分。综合推荐指数的计算逻辑不是简单的平均分，而是加权求和，权重可以由管理员在后台动态配置，也可以根据用户偏好自动调整。
基础公式长这样：
综合推荐指数 = safety_score0.25 + effect_score0.2 + price_score0.2 + brand_score0.15 + sales_score0.1 + favorite_score0.1
这个默认权重是我和学弟一起调出来的，安全维度权重最高，因为美妆消费相比普通商品更看重安全性和成分，功效和性价比次之，品牌和热度属于锦上添花。具体权重可以存在数据库的config表里，也可以用常量定义在代码中。
封装一个DecisionScoreCalculator工具类，输入是商品维度的六个分数，输出是综合推荐指数和决策建议文本。建议文本根据分数区间生成不同文案，比如综合推荐指数在8.5以上输出"成分安全、功效口碑优秀，综合表现顶级，值得入手"；7.5到8.5之间输出"综合表现优秀，可结合自身肤质和预算考虑"；6.0到7.5之间输出"存在一定短板，建议进一步查看成分和用户评价"；6.0以下输出"综合表现一般，非刚需建议谨慎入手"。
这里要说一个容易被评审老师追问的技术点：component_score这些六维分数从哪里来。答案是半自动采集加人工模拟。成分安全度safety_score建议通过一个成分风险数据库的规则表来计算，运维人员或管理员录入商品成分时，系统自动匹配高风险成分关键词列表（酒精、香精、甲基异噻唑啉酮等），命中的按权重扣分，最终输出安全度分数。功效、性价比等分数可以由管理员后台录入，或者用销量、价格等客观数据通过规则计算。这个逻辑在答辩时可以讲清楚"这是一个可扩展的规则引擎"，比直接说"我造的数据"要好得多。
3.4 评价模块：好评判断与口碑聚合
用户评价模块的技术难点在于"聚合"而不是"录入"。录入评价就是一个常规的Insert操作，加上用户ID和商品ID的重复性校验，逻辑非常简单。
口碑聚合的展示逻辑更有意思。在商品详情页里，评价模块要显示四个统计数字：总评价数、平均评分、好评率、评分分布直方图。评分分布是把所有评价按1到5分分组统计数量，然后在页面上渲染成柱状图，这样用户一眼就能看出这个商品的口碑分布是"两极分化"还是"稳定好评"。
评价列表默认按时间倒序排列，提供"只看有图评价"的筛选开关。每条评价显示用户名（支持匿名隐藏部分字符）、评分（用星标展示）、内容、购买渠道、评价时间。管理员在后台可以对评价进行删除操作，把广告和恶意评论清理掉。
这个模块有一个很实用的隐藏功能：情感倾向判断。我用了最简单的关键词匹配方案，整理一份正向词汇表（好用、不错、惊艳、回购、水润、温和等）和负向词汇表（过敏、闷痘、刺鼻、难用、搓泥等），对评价内容做分词匹配，正向词多判定为好评，负向词多判定为差评，然后计算一条"口碑倾向指数"。这个算法非常简单，准确率可能只有70%，但用在毕设里作为展示亮点足够了。答辩的时候可以先说明关键词匹配的局限性，再提一句"如果使用LSTM或BERT这类深度学习模型效果会更好，但由于数据量和算力限制暂未采用"，显得你既有实践又有思考。
4. 前端交互与数据可视化实现
4.1 JSP页面布局与公共组件复用
JSP的布局管理一直被人诟病，但用好了其实很方便。我的做法是在webapp/common目录下创建header.jsp和footer.jsp两个公共文件，分别承载顶部导航栏和页脚版权信息。每个页面通过JSP的include指令引入这两个文件。顶部导航栏包括logo、导航菜单（首页、商品分类、口碑榜、决策工具、个人中心）、搜索框，以及登录状态显示。
登录状态用Session里的user对象判断，用c:if标签区分展示"登录/注册"按钮还是"欢迎xxx + 退出登录"链接。这里需要提前处理一个问题：JSP页面里访问Session对象，如果用纯Java代码片段，需要在代码中获取；如果用EL表达式，直接用${sessionScope.user.nickname}即可，写法更简洁且不产生Java代码。
页面风格上用了Bootstrap 4的栅格系统做响应式布局，没有自己写太多CSS。商品卡片使用Bootstrap的card组件，展示商品图片、名称、价格和推荐指数标签。列表页使用row + col-md-4的组合实现三列自适应网格，在窄屏设备上会自动变成两列或单列，这个响应式体验在答辩演示时如果评委用的是笔记本，效果非常直观。
搜索框是商品检索的入口，提交到商品列表页并带上keyword参数。搜索支持模糊匹配，匹配范围包括商品名称、品牌、功效标签。SQL用LIKE '%keyword%'实现，这里因为值是参数化传入的，所以不存在SQL注入风险。
4.2 ECharts雷达图与口碑分布图
ECharts的引入采用CDN方式，在商品详情页的footer.jsp之后单独引入。注意JSP页面的执行顺序是自上而下，所以ECharts的初始化脚本要放在DOM元素渲染完成之后，避免出现"container is not defined"的报错。
雷达图的配置是这个项目可视化部分的核心。雷达图的指标是六个维度：安全度、功效、性价比、品牌、热度、口碑。每个商品的六维数据从后端传递，前端用ECharts的radar坐标系渲染。为了对比效果更好，我加了两个系列：当前商品和同品类平均分，这样用户能直观看到这个商品在哪些维度上跑赢了平均值、哪些维度拖了后腿。这个"同品类平均"的数据在SQL上是一个GROUP BY category_id的聚合查询，在Service层封装好之后传给页面。
口碑分布直方图用ECharts的bar类型实现，x轴是1到5星，y轴是评价数量，配合tooltip悬浮提示能显示具体数字。ECharts的init方法里我最想提醒的一个点是：容器的宽度和高度必须在渲染时已经确定，如果容器display:none或者宽度为0，图表会渲染失败或显示错乱。解决方法是确保图表容器是可见状态再调用init方法，或者在初始化前先给容器设置明确的宽高。
4.3 Ajax异步交互：收藏、评价与价格区间筛选
页面无刷新交互是现代Web应用的标配，这个项目里我实现了三个Ajax交互点：一键收藏按钮、评价分页加载、商品列表的价格区间无刷新筛选。
一键收藏的实现逻辑是：用户点击收藏按钮，jQuery通过$.post方法向后台发送商品ID和用户ID，后台Servlet判断如果该用户没有收藏过这个商品就执行插入，如果已经收藏过就执行删除（切换收藏状态），返回JSON给前端，前端根据返回结果切换按钮的样式。这里要注意返回的数据格式统一为{code: 200/500, message: "xxx", isCollected: true/false}，前端用JSON.parse解析之后做状态更新。这个模块能体现前后端交互的完整闭环，是答辩时容易引起老师兴趣的一个演示点。
评价分页加载：列表区域初始加载第一页，用户点击"加载更多"按钮，前端发送当前页码和商品ID到后台，后台返回下一页评价数据（HTML片段或JSON数据）。我当时的做法是返回JSON数据后用jQuery拼接HTML，这样前端代码逻辑清晰。这种"点击加载更多"比传统分页更有交互感，而且实现难度并不高。核心是后端分页查询的参数pageNum +1，前端将返回的数据用模板字符串拼接后append到列表容器。
5. 部署运行与常见问题排查
5.1 环境准备与项目运行步骤
项目运行的前置环境要求：JDK 8、Maven 3.6+、Tomcat 8.5+、MySQL 5.7+、IDEA（IntelliJ IDEA Ultimate版或社区版均可，社区版需要自己配置Tomcat插件，这里我建议直接用IDEA Ultimate，学校一般有教育授权）。
运行步骤可以按以下顺序操作：
- 在MySQL中创建数据库beauty_decision，设置字符集utf8mb4，然后导入项目sql目录下的init.sql脚本。
- 修改src/main/resources/db.properties文件中的数据库连接信息，包括URL、用户名、密码。URL要特别注意加上useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai这些参数，否则中文会乱码，SSL警告会一直刷。
- 确保Maven的settings.xml配置了阿里云镜像，因为首次构建要下载大量依赖，默认的中央仓库在国内速度极慢，容易让人误以为卡住了。配置方式是在settings.xml的mirrors节点里加入阿里云公共仓库地址。
- 在IDEA中配置Tomcat，选择本地安装的Tomcat路径，然后添加Artifact（war exploded）并设置Application context为/。
- 启动Tomcat，浏览器访问http://localhost:8080/ 即可看到首页。
初始化管理员账号：admin / admin123，用户账号可以用注册功能自己创建。
5.2 高频异常与解决方案速查
我帮学弟调试的过程中，遇到过的问题五花八门，这里挑几个最高频的整理出来，方便大家照方抓药。
第一个是启动时数据源初始化失败，报错信息是Access denied for user 'root'@'localhost'或者Communications link failure。前者是密码写错或者MySQL用户名不对，检查db.properties；后者是MySQL服务没启动、端口被占用或URL写错，在命令行执行netstat -ano | findstr 3306查看端口监听情况，如果没输出说明MySQL没启动，到服务里手动启动即可。
第二个是页面中文乱码。这个问题的根源是编码不一致，可能出现在四个环节：数据库表字符集不是utf8mb4、JDBC连接URL没加useUnicode=true&characterEncoding=utf8、JSP页面没有设置pageEncoding、Tomcat的server.xml的Connector没配置URIEncoding="UTF-8"。排查顺序也按这个顺序来，先查库，再查URL，最后查Tomcat配置。还有一个很隐蔽的点：如果使用Servlet 3.0的注解配置，Servlet里setCharacterEncoding要在getParameter之前调用才有效，否则取到的还是乱码。这个可以用过滤器统一处理，写一个EncodingFilter，对所有请求先request.setCharacterEncoding("UTF-8")再放行。
第三个是访问页面404。多半是Artifact的部署结构问题，IDEA里Artifact默认的output directory和Tomcat的webapps目录不一致。解决方案是运行配置里设置Deployment的Application context为/，然后确保Artifact的类型是war exploded而不是war，前者不压缩直接加载类文件和页面，调试更方便。
第四个是JSTL标签不生效，页面白屏或者报The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved。这个是依赖缺失问题，需要在pom.xml里引入jstl和standard两个依赖，或者使用Tomcat自带的jasper-jstl包。在Maven中引入jstl 1.2版本的依赖即可解决。
第五个是SQL查询报Unknown column，通常是实体类字段和数据库表字段命名不一致。数据库字段习惯用下划线命名，Java属性习惯用驼峰命名，比如数据库的create_time对应Java的createTime，如果手写RowMapper时没做对应的映射转换，就会报Unknown column错误。解决方案是写一个通用的RowMapper工具类，或者用spring-jdbc的BeanPropertyRowMapper，它默认支持下划线到驼峰的自动映射，前提是列名和属性名能对应上，如果对不上还是在SQL里用AS别名处理更稳妥。
5.3 部署上线实操：从war包到云服务器
本地跑通了不算完，很多毕设要求在答辩时能现场演示，所以最好把项目部署到一台云服务器上，这样只需要一个浏览器就能访问，不需要现场打开IDEA和调试工具。
打包命令很简单，在项目根目录执行mvn clean package，成功后target目录下会生成beauty_decision.war文件。把这个war包拷贝到服务器的Tomcat的webapps目录下，启动Tomcat就会自动解压部署。如果公司或者学校不允许用服务器，退而求其次，直接在本地Tomcat里运行也可以，答辩现场带上电脑就行。
为了演示体验更好，我建议在服务器上做三件事：把Tomcat默认端口从8080改成80，这样访问URL就不用带端口号了；在conf/server.xml的Host节点下配置Context的path为空，让项目作为根路径应用直接访问；关闭Tomcat的manager页面和文档站点，避免安全上的麻烦，也显得项目交付更正规。不过这之前还是得确认好，80端口没有被防火墙屏蔽。
如果想把MySQL数据库也部署到服务器上，安装MySQL 5.7后注意初始化一个和本地一样的数据库名和账号密码，导入init.sql。服务器上的MySQL默认只允许localhost连接，如果本地程序要连，得修改bind-address并开放3306端口，但毕设项目不建议这么做，直接把数据和程序都放服务器上更合理。
6. 这个项目还可以怎么延伸
毕设项目不求大而全，但求一个完整的纵向闭环。当前版本的代码已经把"浏览商品 -> 查看详情 -> 查看评价和决策建议 -> 收藏 -> 待购清单"这条主链路打通了，技术上覆盖了JavaWeb全流程，从Servlet处理请求、JDBC操作数据库、JSP渲染页面、Ajax交互到ECharts可视化，每一环都是手写的、可控的。从答辩的角度，这已经是一个完整且能自圆其说的体系。
如果你学有余力，想在项目上继续做有价值的扩展，我建议优先考虑以下两个方向。
第一个是引入协同过滤推荐算法。当前用户进入商品详情页时，侧边栏的"猜你喜欢"是简单的同分类随机推荐，实现方式是SELECT ... WHERE category_id = ? ORDER BY RAND() LIMIT 3。如果你想升级，可以用基于用户的协同过滤：查询"和你收藏了相同商品的用户还收藏了什么"，SQL上用两个子查询加JOIN实现。这个逻辑不复杂，核心SQL二十行以内能写完，但介绍时的含金量完全不一样。更进阶的基于商品的协同过滤，需要计算商品之间的相似度矩阵，可以用余弦相似度，这部分就有点算法研究的味道了。
第二个是增加一个商品对比功能。用户勾选两到三款商品，系统用表格并排展示它们的六维评分、价格、容量、成分对比，配合雷达图可视化差异。这个功能对"消费决策"的场景贴合度极高，实现在技术上不难，核心是传入多个商品ID，查询多次后组装成对比数据结构。做好之后，这个功能在答辩演示环节的视觉效果非常好，评委能看到项目不是简单的CRUD，而是真正围绕"决策"在做产品设计。
我在实际带学弟做这个项目时比较深的体会是，JavaWeb毕设的技术栈虽然不新，但恰恰因为不新，你有机会把从HTTP请求到数据库落盘再到页面渲染的每一个环节都弄明白，这种完整感是Spring Boot秒建项目给不了的。现在网上很多源码下载下来就能跑，但跑通了和弄懂了之间差了无数个debug的夜晚。如果你正在做这个题目的毕设，建议你有意识地在关键模块上多读几遍自己写的代码，把上面提到的几个答辩提问点准备扎实，拿一个不错的成绩应该是水到渠成的事。
写到这里，项目的核心内容基本聊完了。最后再分享一个小技巧：做毕设演示的时候，不要只演示正常流程，提前准备几个"小意外"反而更显功力。比如演示完正常登录后，故意输错一次密码，弹窗提示"用户名或密码错误"，再恢复正常登录；演示完搜索后，搜索一个不存在的关键词，展示友好的空状态提示。这些细节在评审老师眼里，比多写一个功能模块更体现工程素养。