基于JSP的Java植物科普网站毕业设计：从需求到答辩完整指南

选择“基于JSP的Java植物科普网站”做毕业设计，说实话，是一个很稳妥的决定。

先把这个题目的底子说清楚：这是一套典型的Java Web课程设计/毕业设计项目，技术栈是JSP + Servlet + JavaBean + JDBC，搭配MySQL数据库，运行在Tomcat容器里。整个项目遵循经典的MVC分层思想，前端页面用JSP动态渲染，业务逻辑交给Servlet处理，数据操作通过JDBC完成。它解决的核心问题，是让植物爱好者能够在一个网站上完成植物信息浏览、按分类检索、关键词搜索、植物百科阅读、用户注册登录、评论互动，以及管理员后台对植物数据、分类、用户、评论的增删改查。

这个题目特别适合三类人：一是计算机相关专业、正在为毕业设计选题发愁的应届生；二是想巩固Java Web基础、准备面试或考研复试的项目党；三是需要一个可运行、可讲解、可扩展的完整Web项目作为作品集的技术学习者。为什么说它“稳妥”？因为麻雀虽小五脏俱全：它覆盖了Java Web开发的核心链路，又不会像Spring Boot全家桶那样让原理变成黑盒。

整个项目从需求分析、数据库设计、编码实现到部署答辩，我有几条实打实的心得，接下来按顺序聊，能帮你少走不少弯路。

1. 选这个题目之前，先把需求想清楚

1.1 植物科普网站到底要做哪些功能

很多同学拿到题目就直接建工程写代码，这是毕业设计第一大忌。植物科普网站听起来简单，但功能边界不划清楚，后面一定会做成“四不像”。我把常见需求拆成了两大端、五个模块。

前端（访客可见）：

• 首页：轮播图、热门植物推荐、最新收录植物、分类快捷入口
• 植物列表页：按分类（蕨类、裸子、被子、多肉、水生等）筛选，支持分页显示
• 植物详情页：展示植物学名、别名、科属、形态特征、生长习性、分布区域、栽培要点、高清图片，以及用户评论
• 搜索：支持按植物名称、别名、科属模糊搜索
• 用户中心：注册、登录、修改个人信息、查看自己的评论记录

后端（管理员可见）：

• 后台登录（独立于前台用户的权限控制）
• 植物信息管理：新增、编辑、删除、上下架
• 分类管理：维护植物分类树
• 评论管理：审核、删除违规评论
• 用户管理：禁用/启用用户账号

注意，我没有把“购物车”“订单”这类电商功能放进去，因为植物科普网站是内容型站点，不是商城。有些同学为了凑功能硬塞在线支付、秒杀，结果答辩时被老师一问三不知，反而扣分。功能匹配选题定位，比功能多更重要。

1.2 角色划分与权限模型

这个项目涉及两类角色：普通用户和管理员。

我的建议是建一张user表，用role字段（0-普通用户，1-管理员）区分，而不是建两张表。原因有三：一是毕业设计的数据量小，拆表增加无意义的关联复杂度；二是登录逻辑统一，只需查一张表；三是答辩时讲权限控制思路更清晰——后端Servlet在处理请求前先检查session里存的登录用户role是否为1，简单直接。

不过要注意：真正的权限控制不能只在前端页面隐藏“管理员入口”，那只是锦上添花。所有涉及写操作的后端Servlet，都必须做session角色校验。这个细节在答辩时主动讲出来，是明显的加分项。

1.3 项目目录结构与分层思路

我按标准IDEA Web项目结构组织代码，包名用com.plant.app作为根，下面再分层：

src/main/java/com/plant/app ├── entity // 实体类：User、Plant、Category、Comment ├── dao // 数据访问层：PlantDao、CategoryDao、UserDao、CommentDao ├── service // 业务层：PlantService、UserService（可选，但建议加） ├── servlet // 控制层：LoginServlet、RegisterServlet、PlantServlet等 ├── filter // 过滤器：EncodingFilter、LoginFilter ├── util // 工具类：DBUtil、PageUtil、VerifyCodeUtil src/main/webapp ├── index.jsp ├── plantList.jsp ├── plantDetail.jsp ├── login.jsp ├── register.jsp └── admin/ ├── plantManage.jsp ├── categoryManage.jsp └── commentManage.jsp

为什么要分这么多层？毕业设计的核心考察点之一就是“模块化设计思想”。如果你把所有代码堆在一个Servlet甚至一个JSP里，功能是能跑，但老师一眼就能看出你没有工程意识。分层之后，每个类的职责单一，测试也方便，答辩时可以直接说“我采用了经典的MVC三层架构，实现了页面、业务、数据的解耦”。

2. 技术选型拆解：JSP + Servlet是过时，还是经典

2.1 为什么不用Spring Boot做这个题目

这是选题阶段我被问得最多的问题。很多学生觉得JSP是“老古董”，想直接用Spring Boot + Thymeleaf/Vue前后端分离，觉得更有面子。我的看法是：如果你技术能力很强，用Spring Boot做当然可以，但前提是你能把原理讲透；如果只是为了完成任务，JSP + Servlet恰恰是性价比最高的选择。

原因很实际：

• 课程体系匹配：绝大多数高校Java Web课程教的就是JSP + Servlet + JDBC，毕业设计和课程无缝衔接
• 原理透明：JSP本质是Servlet，请求从浏览器到Servlet再到JSP的完整链路全部可见，没有Spring Boot那种“自动配置”魔法
• 代码量可控：一个毕业设计的核心代码量通常在3000-6000行之间，用Servlet手写完全在可维护范围内
• 答辩友好：老师问“请求是怎么处理的？”“JSP和Servlet什么关系？”这类基础问题，答起来底气足

Spring Boot当然好，但如果你对IOC容器、自动配置、内嵌Tomcat、Starter机制等底层原理一知半解，答辩时老师往深处一问，很容易翻车。技术选型不是越新越好，而是越能体现你的真实掌握程度越好。

2.2 JSP + Servlet + JDBC的请求处理链路

为了帮你理解整个项目最核心的运行机制，我画了一条逻辑链路，这是答辩必讲的：

浏览器发起HTTP请求 → Tomcat接收请求，根据web.xml中配置的映射规则找到对应Servlet → Servlet调用service层处理业务逻辑 → Service调用DAO层访问MySQL数据库 → 数据封装成实体对象返回 → Servlet将数据set到request域中 → RequestDispatcher转发到指定JSP页面 → JSP在服务器端解析，把动态数据嵌入HTML → 响应返回浏览器渲染展示。

这里有个关键点：JSP页面不是浏览器直接能识别的，它由Tomcat转译成Servlet源码，再编译成.class文件执行。所以JSP里的Java代码片段（<% %>）是在服务器端运行完，把结果拼进HTML后才发给浏览器的。这个概念搞清楚了，你就能理解为什么JSP适合做这种服务端渲染的网站，也理解为什么代码里不能像写Android那样在JS里直接new Java对象。

2.3 环境与版本搭配建议

我推荐一套稳妥到不能再稳妥的环境组合：

特别注意：Tomcat 10+的Servlet API包名从javax.servlet改成了jakarta.servlet，如果你照网上老教程写import javax.servlet.*，编译直接报错。所以毕业设计不要盲目追求新版本，把基础版本用熟比什么都强。

3. 数据库设计：植物科普的数据底座

3.1 核心表结构设计

数据库是毕业设计的大头，一个合理的关系模型，直接决定后期编码的顺畅程度。我按照功能需求设计了五张核心表，这里给出建表SQL，你可以直接参考：

CREATE DATABASE plant_db DEFAULT CHARACTER SET utf8mb4; USE plant_db; -- 植物分类表 CREATE TABLE category ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT '分类ID', name VARCHAR(50) NOT NULL UNIQUE COMMENT '分类名称，如蕨类植物', description VARCHAR(255) COMMENT '分类简介', sort INT DEFAULT 0 COMMENT '排序号' ) COMMENT '植物分类表'; -- 植物信息表 CREATE TABLE plant ( id INT AUTO_INCREMENT PRIMARY KEY COMMENT '植物ID', category_id INT NOT NULL COMMENT '分类ID，外键', name VARCHAR(100) NOT NULL COMMENT '植物名称', alias VARCHAR(100) COMMENT '别名', scientific_name VARCHAR(100) COMMENT '学名', family VARCHAR(100) COMMENT '科', genus VARCHAR(100) COMMENT '属', morphology TEXT COMMENT '形态特征', habit TEXT COMMENT '生长习性', distribution TEXT COMMENT '分布区域', cultivation TEXT COMMENT '栽培要点', image_url VARCHAR(255) COMMENT '图片URL', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '录入时间', status TINYINT DEFAULT 1 COMMENT '0下架 1上架', click_count INT DEFAULT 0 COMMENT '点击量', FULLTEXT KEY ft_name (name, alias) -- 可选全文索引 ) COMMENT '植物信息表';

-- 用户表 CREATE TABLE user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL COMMENT '建议MD5加密后的值', email VARCHAR(100), role TINYINT DEFAULT 0 COMMENT '0普通用户 1管理员', status TINYINT DEFAULT 1 COMMENT '0禁用 1正常', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT '用户表'; -- 评论表 CREATE TABLE comment ( id INT AUTO_INCREMENT PRIMARY KEY, plant_id INT NOT NULL COMMENT '植物ID', user_id INT NOT NULL COMMENT '评论用户ID', content VARCHAR(1000) NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, status TINYINT DEFAULT 1 COMMENT '0待审核/隐藏 1正常' ) COMMENT '评论表'; -- 留言表（可选） CREATE TABLE message ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT, content VARCHAR(1000), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) COMMENT '访客留言表';

这里有几个设计要点，答辩时会考到：

• 为什么用utf8mb4而不是utf8？因为utf8mb4是真正的四字节UTF-8，能存emoji表情，植物详情里可能会出现特殊符号，如果只设utf8在报错或者插入异常的时候排查起来麻烦。MySQL 8.0默认就是utf8mb4，但5.7需要显式指定。
• comment表为什么单独建，而不是在plant表里用字段存评论？因为评论是集合型数据，一个植物有多条评论，评论属于用户，如果全塞在一行里既不符合第一范式，也无法高效分页查询。
• 外键要不要建？我建议建。虽然实际项目中有些团队会为了性能放弃外键约束，但毕业设计建外键，能直观体现你懂关系型数据库的完整性约束。

3.2 登录密码加密与SQL注入预防

普通用户注册和登录模块是每个评委都会重点关注的安全点。我在项目里没做很复杂的安全方案，但有两个最基本的操作必须做到位：

第一，密码不能明文存储。最简单的做法是在注册的Service层用MD5加密后再入库。Java自带MessageDigest.getInstance("MD5")就能做，代码大概这样：

public static String md5(String input) { try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] bytes = md.digest(input.getBytes(StandardCharsets.UTF_8)); StringBuilder sb = new StringBuilder(); for (byte b : bytes) { String hex = Integer.toHexString(0xff & b); if (hex.length() == 1) { sb.append('0'); } sb.append(hex); } return sb.toString(); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } }

第二，DAO层防SQL注入。拼接字符串的写法绝对不能用：

// 错误示范，绝对不要这么写 String sql = "SELECT * FROM user WHERE username='" + username + "' AND password='" + password + "'";

正确写法是用PreparedStatement的占位符：

String sql = "SELECT * FROM user WHERE username=? AND password=?"; PreparedStatement ps = conn.prepareStatement(sql); ps.setString(1, username); ps.setString(2, md5Password); ResultSet rs = ps.executeQuery();

这两点写进论文、写进答辩稿，老师会认为你具备基本的安全素养。

3.3 模糊搜索与分页查询

植物网站最核心的交互是搜索和列表。搜索我用的是LIKE模糊匹配：

SELECT * FROM plant WHERE status = 1 AND (name LIKE ? OR alias LIKE ? OR scientific_name LIKE ?) ORDER BY create_time DESC LIMIT ?, ?;

分页我建议自己写一个PageUtil，不要在这个项目里引入MyBatis的分页插件（PageHelper），因为会破坏纯JDBC的统一性。PageUtil只需要三个字段：当前页码pageNo、每页条数pageSize、总记录数totalCount。计算出总页数：

int totalPages = (int) Math.ceil(totalCount * 1.0 / pageSize);

然后LIMIT参数的偏移量是(pageNo - 1) * pageSize。这个计算在答辩时也常被问到，因为这是最基础的物理分页概念。

4. 核心功能实现：从登录到后台管理一步步拆解

4.1 验证码：登录模块的体验细节

登录功能虽然简单，但有个容易被忽略的小组件——验证码。我用的是Java原生Graphics2D画图方案，没有引入第三方库。核心步骤就三步：

1. 生成4位随机字符串（建议去掉容易混淆的0/O、1/l）
2. 用BufferedImage创建120x40的图片，设置干扰线
3. 把随机字符串存入session，把图片通过response.getOutputStream()输出

// 验证码Servlet核心代码 int width = 120, height = 40; BufferedImage image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB); Graphics2D g = image.createGraphics(); g.setColor(new Color(245, 245, 245)); g.fillRect(0, 0, width, height); // 随机干扰线 for (int i = 0; i < 6; i++) { g.setColor(new Color(100 + (int)(Math.random() * 100), 100 + (int)(Math.random() * 100), 100 + (int)(Math.random() * 100))); g.drawLine(0, (int)(Math.random() * height), width, (int)(Math.random() * height)); } // 绘制字符 String code = ""; for (int i = 0; i < 4; i++) { char c = chars[(int)(Math.random() * chars.length)]; code += c; g.setFont(new Font("宋体", Font.BOLD, 24)); g.setColor(new Color(20 + (int)(Math.random() * 120), 20 + (int)(Math.random() * 120), 20 + (int)(Math.random() * 120))); g.drawString(String.valueOf(c), 20 + i * 24, 30); } session.setAttribute("verifyCode", code); // 输出图片 ImageIO.write(image, "jpg", response.getOutputStream());

登录Servlet里校验时，用equalsIgnoreCase比较，并且校验完无论成功失败都建议立即清除session中的验证码，防止同一验证码被重复利用。这个小细节也是加分项。

4.2 图片上传：植物图片的存储方案

植物科普网站必须有图片，图片上传是后台管理里最容易出问题的地方。两种方案供你选：

方案A（推荐给毕设）：把图片保存到服务器本地目录，数据库只存相对路径。

• Servlet接收Part文件（如果是Servlet 3.0及以上）
• 用UUID重命名文件，防止中文名乱码和重名
• 保存到webapp/upload/plant目录
• 数据库image_url字段存upload/plant/xxx.jpg

一个隐藏的坑是：Eclipse部署项目到Tomcat的webapps目录时，如果你直接在eclipse里的webapp目录下新建upload文件夹，可能因为IDE没有同步或者清理目录导致图片丢失。最稳的做法是在服务器启动时用代码检查目录是否存在，不存在就自动创建。

String savePath = getServletContext().getRealPath("/") + "upload/plant"; File dir = new File(savePath); if (!dir.exists()) { dir.mkdirs(); }

另一个常见的坑是文件大小上限。Tomcat默认对POST表单的最大长度有限制，通常在2MB左右。如果你上传大图报错413 Request Entity Too Large或SizeLimitExceededException，需要在web.xml里调整maxPostSize：

<multipart-config> <max-file-size>10485760</max-file-size> <max-request-size>20971520</max-request-size> <file-size-threshold>5242880</file-size-threshold> </multipart-config>

方案B：把图片上传到配置好的第三方图床，数据库存URL。好处是服务器负担小，但毕业设计不推荐，因为答辩时评委可能问“数据放在别人的服务器上，安全性怎么保证”，回答起来被动。

4.3 后台管理：统计仪表盘与CRUD

后台首页我建议放一个统计仪表盘，用几个SQL统计一下总数：

• 植物总数：SELECT COUNT(*) FROM plant
• 分类总数、评论总数、用户总数
• 今日新增植物数（或本月新增）

这样后台看起来就不只是一个光秃秃的表格，内容饱满，答辩演示时也有视觉冲击力。CRUD部分注意三点：

• 删除分类前检查该分类下是否还有植物，有就提示“该分类下存在植物，不可删除”，这是基于内容完整性考虑的合理设计
• 植物信息编辑要支持回显，点击编辑时得先从数据库把当前记录查出来set到request域，再跳转到编辑页面，页面表单的值用EL表达式${plant.name}填充
• 操作完成后用重定向而非转发，防止用户刷新页面导致表单重复提交。比如新增植物成功后response.sendRedirect("admin/plantManage?action=list")，而不是request.getRequestDispatcher(...).forward(...)

重复提交这个问题毕设里面很常见，重定向一次，刷新就不会再弹“是否重新提交表单”的提示窗口，整个体验干净很多。

4.4 评论与互动：提升科普网站的参与感

植物详情页有评论功能。评论的加载要注意N+1查询问题：如果我遍历植物列表，每一条植物去查一次评论，性能会很差。评论区我只推荐在详情页加载，列表页不显示评论条数（点击次数可以显示，那个在plant表里有字段）。

评论提交用AJAX异步提交体验更好，给用户一个“评论成功”的提示而不刷新整页。前端用jQuery发POST请求到CommentServlet，Servlet返回JSON，再渲染。这是前端JS + jQuery在JSP项目里最常见的用法：

$.post("commentServlet", { plantId: plantId, content: content }, function (resp) { if (resp.code === 200) { // 重新加载评论区域 loadComments(plantId); } else { alert(resp.msg); } }, "json");

后台评论管理要支持审核与删除。很多讲师喜欢看到评论管理里有“审核”功能，因为它体现了内容风控意识，虽然毕设里实现起来很简单（改一个status字段），但讲出来很有价值：未审核的评论前台不显示或显示为“审核中”。

5. 典型问题与排查技巧实录

5.1 中文乱码：JSP + Servlet乱码的重灾区

中文乱码是Java Web项目里的头号问题，而且不止一个环节会导致乱码：页面显示乱码、请求参数乱码、数据库存取乱码，三个地方要分开处理。

页面显示层：

• JSP页面头部的contentType="text/html; charset=UTF-8"和pageEncoding="UTF-8"要一致
• HTML的<meta charset="UTF-8">也要写
• 浏览器默认编码跟随页面设置

请求参数层：

• POST请求：在Servlet里request.setCharacterEncoding("UTF-8")必须放在读取任何参数之前，最好用Filter统一处理
• GET请求：Tomcat 8+之后的URIEncoding默认就是UTF-8，一般不用额外配；如果是老版本Tomcat 7，需要改conf/server.xml里的Connector配置URIEncoding="UTF-8"

数据库存取层：

• JDBC连接URL带参数useUnicode=true&characterEncoding=UTF-8
• 表字段和表本身是utf8mb4
• 注意：characterEncoding=UTF-8和serverTimezone=Asia/Shanghai是两个常见的坑。MySQL 8.0还要求指定serverTimezone，否则可能报The server time zone value错误

我的排查经验：一张表一张表查，先用浏览器F12看Network里的Response是否乱码，再用一个测试Servlet打印System.out.println看服务器收到的参数是否乱码，定位到乱码发生在哪个环节再动手，不要把三个环节的配置全改一遍，改乱了你都不知道是哪个配置生效的。

5.2 部署到Tomcat后404、500与内存不足

自己电脑上跑得好好的，部署到别的机器上就404，最常见的原因是项目名称不一致。访问路径是http://ip:8080/项目访问名/页面，项目访问名取决于你部署的WAR包名或IDEA/Eclipse里配置的Application context。

如果报404，先看：

• Tomcat的webapps目录下是否真的存在正确名字的war/文件夹
• 访问路径里的大小写是否和项目名一致
• 主页是否配置了<welcome-file-list>，我建议把index.jsp或indexServlet加进去

如果报500，看catalina.out或logs/localhost.log，最常见的是数据库连接失败、ClassNotFoundException（驱动包没放进WEB-INF/lib）、SQL语法错误。

还有一类隐藏问题：本地运行正常，一部署内存不足OutOfMemoryError。主要原因是Tomcat的默认JVM堆内存太小。翻看catalina.sh（Linux）或catalina.bat（Windows）里的CATALINA_OPTS，或者直接在启动脚本里加：

JAVA_OPTS="-Xms256m -Xmx512m -XX:MaxPermSize=128m"

对应Windows下的cmd文件也一样。我有一次在服务器上部署一个带大量图片的科普网站，就是不调堆内存，跑个几天就OOM，调整之后问题消失。这个经验在答辩时讲出来，老师会觉得你真的做过部署而不是只在本地点过运行。

5.3 前端常见坑：jQuery冲突、图片路径与浏览器差异

JSP项目里嵌入JS + jQuery很常见，但有几个坑：

第一，jQuery库和其他框架同时引入导致$冲突。页面里用了多个组件库，可能$被占用。解决方法是使用jQuery的noConflict模式：var jq = $.noConflict();，然后用jq代替$。这个不一定会遇到，但遇到要能快速定位。

第二，图片路径问题。浏览器地址栏访问的URL和JSP文件在服务器磁盘上的目录结构，容易让人混淆。在JSP中引用图片，建议尽量用<%=request.getContextPath()%>拼接上下文路径，或者用<c:url>标签生成完整路径，这样不管项目部署在哪个context下都不会写错。

第三，浏览器兼容。用getElementById、querySelectorAll没问题，但部分老接口如document.all在Chrome和Firefox下行为不同。还有一个比较经典的Chrome行为：a标签的download属性不能跨域触发下载，如果文件是走Servlet输出流下载的，download属性不生效，这时曲线方案是把文件流读取后通过JS Blob生成本地URL再触发下载。这块在毕设答辩前值得提前测一遍。

5.4 Java基础层面的常见报错速查

把项目开发过程中可能遇到的Java基础报错也整理了一份速查表：

一个比较隐蔽的坑：JSP里的Java代码如果跑了String.valueOf(request.getParameter("id"))，而id不是数字，在某些封装转换工具里会抛NumberFormatException。建议在Servlet层统一做参数校验，返回友好的错误提示。

6. 从编码到答辩：论文结构与演示脚本

6.1 毕业论文的章节安排建议

毕设论文和项目代码是相辅相成的，我建议论文按下面结构组织：

1. 绪论：研究背景、国内外现状、研究内容、论文结构
2. 相关技术介绍：JSP、Servlet、JavaScript/jQuery、MySQL、Tomcat，这一章要写基础原理，不要写成使用教程
3. 系统分析：可行性分析（技术、经济、操作）、需求分析（功能需求、数据需求、安全需求）、用例图数据流图
4. 系统设计：总体架构设计（B/S模式、MVC分层）、功能模块设计（前台、后台）、数据库设计（ER图、表结构）
5. 系统实现：按模块展示关键代码和截图，这里要配合测试数据和运行结果截图，代码不要全部贴，贴核心逻辑即可
6. 系统测试：功能测试用例表（测试编号、测试项、输入、预期结果、实际结果）、部分性能与兼容性测试
7. 总结与展望：总结做了什么、哪些不足、后续扩展方向

Word排版时注意：图和表格要有编号和题注，代码用等宽字体且不跨页断裂，目录自动生成，页眉页脚加上。这些细节点能直接拉高论文的整体印象分。

6.2 答辩前如何准备演示脚本

答辩时演示系统最容易翻车的是“现场出bug”。我的经验是：准备两条演示路径，一条是正常路径，一条是兜底路径。

正常路径演示流程（大概8-10分钟）：

1. 打开首页，先讲页面布局和导航结构
2. 演示按分类浏览植物（点一个蕨类植物分类）
3. 演示搜索（输入“银杏”或“仙人掌”）
4. 打开一个植物详情页，读一遍形态特征、生长习性的展示
5. 演示注册新用户（注意：提前测试不要和已有用户名冲突）
6. 登录后评论一条，后台审核，前台刷新看到评论
7. 展示管理员登录，进入后台做一次新增植物和一次删除评论
8. 展示数据库设计（打开Navicat或命令行show tables，讲表关系）

兜底路径：如果现场网络或数据库有问题，准备好几张关键页面截图和功能数据表截图放在演示PPT里，讲“实际效果如下”，不要因为环境问题卡死。

6.3 老师喜欢问的高频问题清单

归纳了这几年评委最爱问的一批问题，提前准备答案：

• 说说JSP和Servlet的区别与联系？
  • Servlet是Java类，适合处理业务逻辑；JSP侧重页面展示，本质是Servlet。JSP第一次请求时被转译为Servlet。
• 你们的MVC是怎么体现的？
  • JSP是View，Servlet是Controller，Service+DAO是Model，数据封装在JavaBean中。
• SQL注入怎么预防的？
  • 使用PreparedStatement预编译，占位符传参，不拼接字符串。
• 分页是怎么做的？为什么用物理分页不用内存分页？
  • 见前文，LIMIT ? OFFSET ?，物理分页每次只查当前页数据，内存分页一次性全查出来，大数据量下不可行。
• 如果用户量变大，这个架构怎么优化？
  • 加Redis缓存热点植物数据，加索引优化查询，用连接池，前端做静态资源CDN。这一题不难，但要能说出2-3个点。
• 密码为什么要加密存储？
  • 防止数据库泄露导致用户账号被撞库。

这些问题准备充分了，答辩整体状态会很稳。

最后分享几点真实体会

这些坑都是我自己踩过、帮学生改过，才慢慢总结出来的。打算做这个题目的朋友，有几点真心建议：

第一，不要从网上找那种“什么功能都有的万能代码包”，尤其是源码里带很多你看不懂的第三方库和隐藏后门的那种。毕业设计最核心的价值不是代码本身，而是你能不能讲清每一行代码为什么这么写。技术很新不如原理懂透，代码很多不如逻辑清晰。

第二，开发顺序要遵循“先通后优”：先把最简单的查询列表跑通，再把详情、分页、搜索跑通，再做登录注册，最后做后台管理和评论。每一步都有可运行成果，信心会越来越足，不会出现“开发两个月，最后集成时崩成一坨”的情况。

第三，写代码的过程中同步积累截图和笔记，这一步很多人忽略。论文里的每个功能模块截图、每个测试用例结果，都是日常开发时顺手截的，如果等到最后再照着做好的界面回头补，既费时间又会漏掉过程细节。

这个项目的扩展空间也很大。如果时间充裕，可以考虑把数据导入流程做成Excel批量上传，或者使用ECharts做植物分布的可视化图表，又或者把搜索改成带拼音首字母检索。这些扩展在答辩里讲出来都是“亮点”。不管后续怎么发展，把JSP + Servlet这套经典链路吃透，你做Spring Boot甚至微服务时都会比别人更清楚底层发生了什么。