1. 先拆掉"农业信息学习平台"这七个字：它到底是个什么系统
做了这么多年毕设辅导相关的技术工作，我见过太多同学拿到题目后第一反应就是打开搜索引擎找现成代码。但"基于 Java+SpringBoot+HTML5 的农业信息学习平台"这种题目，如果你只是把它理解成"做个网站"，那后面写论文、画架构图、做答辩准备的时候一定会很痛苦。我建议先花半小时把题目拆干净，搞清楚这个系统本质上要解决什么问题。
1.1 三个关键词背后隐藏的三层需求
拆开看，"农业信息"是业务领域，"学习平台"是核心功能，"分享"是交互形态。也就是说，这个系统不能只做一个单向的知识展示站，比如后台录入几篇文章、前端列表展示那种，而是要形成"有人学、有人教、有人互动"的闭环。农业信息的学习有很强的实操属性，农民或农业从业者遇到病虫害、施肥、选种问题，往往不是靠看一篇百科就能解决的，他们需要看到实际案例、需要有人解答疑问、需要跟有经验的人交流。
所以对比市面上那些纯内容展示的毕设项目，这个题目的差异化点在于：它要求你同时处理好内容管理（知识文章、课程）和社区互动（发布经验、评论、点赞、收藏）两条业务线。这也是答辩时老师最容易追问的地方——"你的平台和普通博客系统有什么区别？"如果你能回答出"我针对农业知识碎片化、实操性强、需要互动验证这些特点做了功能设计"，那这道题一下就稳了。
1.2 这个平台给谁用、解决什么具体问题
目标用户我建议分成三类：农业生产者（种养殖户）、农业相关专业学生或基层农技人员、平台管理员。三类角色的诉求完全不同。
- 农业生产者：学习成本低的操作知识，遇到问题能快速搜索答案，能在社区里向有经验的人请教；
- 农技人员和专业学生：希望系统地浏览分类知识（比如按作物种类、按养殖品类划分），也愿意把自己的一线经验写成文章分享出去，提升影响力；
- 管理员：需要审核内容，确保平台上的农业知识专业、可靠、不误导人，同时要能统计用户活跃度和内容热度。
在功能设计上，这三类诉求对应到三个核心业务模块：用户与角色管理、学习内容模块、分享互动模块。开发的时候不要零散地做功能，而是先画出业务链路图：用户登录→浏览分类知识→阅读文章/观看视频课程→产生疑问→社区提问或评论→得到解答→点赞收藏→自己也发布经验。这条链路走通了，系统的完整性就有了。
1.3 为什么说这个选题是毕设的"安全牌"
从毕设角度评估，这个题目综合性价比很高。第一，业务场景不复杂，不需要对接硬件设备、不需要解决高并发、不需要处理复杂的支付流程，核心就是标准的信息管理系统加上一点社区交互，工作量容易控制。第二，技术栈覆盖面恰好是教学大纲里最常见的组合：Java 语言、SpringBoot 框架、MySQL 数据库、HTML5 前端，每一项都是课堂上反复练过的，答辩时不会出现"用了一个老师完全没听过的技术"这种尴尬局面。第三，可扩展性想象空间大，如果你学有余力，可以在学习模块里接入视频播放统计、在分享模块里加入点赞数热度排序、在管理后台里加入简单的数据可视化图表，这些都是论文里可以写的好素材。
2. 技术选型的完整推演：为什么偏偏是 Java+SpringBoot+HTML5
很多同学拿到题目就开始写代码，技术选型这部分跳过去了。我强调一下：毕设项目的技术选型是你论文第二章的核心内容，也是答辩时老师判断你有没有"设计思路"的重要依据。你不仅要会用这些技术，还要能说出为什么选它们。
2.1 SpringBoot：解决了传统 Java Web 开发的哪些痛点
先回忆一下 Java Web 开发的历史演进。早些年用 Servlet + JSP 写项目，你要手动配置 web.xml、要处理大量模板代码、要自己管理对象创建和依赖关系，一个简单的注册登录功能能写出一堆重复代码。后来有了 Spring 框架的 IoC 和 AOP，对象管理和切面逻辑得到简化，但 XML 配置依然繁琐。SpringBoot 的出现把"配置"这件事压缩到了极致——通过自动配置机制，你只需要在 pom.xml 引入相关依赖，SpringBoot 就会根据 classpath 下的 jar 包自动帮你装配好默认配置。
对于农业信息学习平台这种典型的信息管理系统，SpringBoot 带来的直接好处有三个。第一个是开发效率，一个空的 SpringBoot Web 项目从新建到跑通 Hello World 只需要几分钟，省下来的时间可以放在业务逻辑上。第二个是生态整合，它跟 MyBatis Plus、Spring Security、JWT 这些常用组件的配合都非常顺手，资料多、坑少。第三个是部署简单，项目打成 jar 包后一条java -jar命令就能在服务器上跑起来，对毕设演示环境非常友好。
server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/agri_platform?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password servlet: multipart: max-file-size: 20MB max-request-size: 50MB jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这段application.yml是最小可用配置，实际开发时可以直接抄。注意字符集和时区这两个配置，很多同学项目一启动中文乱码、时间差8小时，往往就是这两个参数没写。
2.2 前端技术：HTML5 在这个项目里的真实定位
这个题目特别强调 HTML5，很多人会困惑："HTML5 不是十多年前的标准吗？现在前端不都用 Vue、React 了吗？"这里其实涉及一个认知误区。毕设题目里写"基于 HTML5"，并不意味着你要用一套过时的方法写前端，而是指你使用 HTML5 的语义化标签和原生 API 来构建页面。
用纯 HTML5 + CSS3 + JavaScript 的好处非常明显：项目结构简单，不需要引入 Node.js 工具链，不需要配置打包器，打开页面就能看到效果。对毕设展示来说，你不需要跟老师解释"为什么要在项目里引入一个额外的前端框架"，因为题目本身已经框定了技术方向。但这不代表你的前端页面要做得很粗糙——相反，HTML5 提供的能力完全够用：video标签可以嵌入农业技术视频，canvas可以画温度、湿度统计图表，localStorage可以实现记住用户名，语义化标签配合 CSS 布局能做出相当专业的界面。
我在指导这类项目的时候，通常建议前端采用一套轻量、自适应的构思：页面整体使用语义化标签搭建结构（header、nav、main、article、section、footer），列表页用 flex 布局实现卡片式展示，详情页注重图文排版，整个项目保持 PC 端优先、同时兼容移动端浏览器。这样既贴合题目要求，又能在答辩时展示你在前端语义化和响应式布局上的理解，而不是只会套模板。
2.3 为什么不建议直接上微服务、Redis、Vue 全家桶
给同学们泼个冷水。如果你的课题只是农业信息学习平台，不是"基于微服务的高并发农业知识分发系统"，那我真心不建议你在里面强行塞微服务架构、Redis 集群、分布式事务这类技术栈。原因有三点：
- 业务规模不匹配。一个学习平台的核心操作无非就是增删改查 + 复杂一点的联表查询，单机部署完全够用，引入微服务只会让代码结构变得混乱，调试难度翻倍；
- 论文答辩风险高。你用了 Redis 缓存文章浏览次数，那老师大概率会问缓存与数据库一致性怎么保证、缓存穿透怎么办，这些问题在真实生产环境都很棘手，学生阶段很难答得深入；
- 调查成本高。SpringCloud 全家桶的环境搭建、服务注册发现、网关配置这些环节，每一个都可能让你卡上好几天，而这些时间本可以花在把业务功能和页面细节打磨到极致上。
毕设的本质是"证明你系统掌握了一个方向的核心知识和技能"，不是"越复杂越好"。技术栈选对、选稳、能自圆其说，比盲目追求高大上重要得多。
3. 核心功能模块拆解：从"学习"到"分享"的业务闭环怎么落地
想清楚整体设计之后，就该把功能模块一个个落地了。农业信息学习平台的核心主干我建议拆成四个部分：用户体系、学习模块、分享互动模块、后台管理模块。这四个模块不是孤立的，而是通过数据关系彼此咬合。
3.1 用户体系：三类角色、统一认证、差异化权限
用户表是系统的基础，设计时建议把角色区分直接放进去。我见过有的毕设把用户和角色分成两张表中间再去放关联表，这在权限复杂的企业级系统里是标准做法，但对农业平台这种规模来说过于繁琐。直接用一个role字段区分三类角色就够用，用 0、1、2 对应的整数存储，代码里用枚举映射。
- 普通用户（role=0）：浏览文章课程、提问、评论、点赞收藏、发布分享内容；
- 创作者（role=1）：在普通用户权限基础上，拥有内容管理增强权限，比如对自己发布的文章进行编辑、查看自己内容的浏览数据；
- 管理员（role=2）：进入独立后台，对所有内容进行审核下架、对用户进行禁用管理、查看统计报表。
注册登录这块推荐用 JWT（JSON Web Token）做无状态认证。它在毕设里的好处是不需要像 Session 一样依赖服务器内存，前端把 token 存到localStorage，每次请求带上Authorization头即可。要注意的是，密码存储必须用 BCrypt 加密，明文存储密码这个问题一旦论文查重或者代码审查被发现，基本就是答辩的硬伤。
@PostMapping("/login") public Result login(@RequestBody LoginDTO dto) { User user = userService.lambdaQuery() .eq(User::getUsername, dto.getUsername()) .one(); if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } Map<String, Object> claims = new HashMap<>(); claims.put("userId", user.getId()); claims.put("role", user.getRole()); String token = JwtUtil.createToken(claims); return Result.success(token); }3.2 学习模块：分类、文章、课程，让知识找到需要的人
学习功能是平台的基本盘。农业知识太庞大了，如果没有良好的分类体系，用户进来会感觉像掉进了一个杂乱的图书馆。分类建议设计成两级：一级分类按产业方向分，比如大田作物、蔬菜园艺、果树栽培、畜禽养殖、水产养殖、农业机械；二级分类按具体技术主题分，比如"果树栽培"下可以再分"施肥管理""病虫害防治""修剪整形"。
内容展示方面要区分"图文文章"和"视频课程"两种形式。图文文章适合技术详解、经验总结，用 HTML 富文本编辑并存储到数据库；视频课程适合实操演示，前端通过 HTML5 的video标签播放。两种形式的数据模型可以做在一个content表里，通过content_type字段区分。检索功能也很关键，用 MySQL 的LIKE '%关键词%'配合分类过滤，基本能满足这个规模的需求，不需要引入 ElasticSearch 这种重方案。
3.3 分享与互动模块：提问、回答、点赞、收藏的细节设计
分享模块是体现平台社区属性的阵眼。最核心的功能包括：用户发布自己的农业经验文章、用户提问、回答别人的问题、点赞和收藏内容、关注创作者。
这里我想多说几句实现细节。发布功能要注意cover_image封面上传的处理，文章内容建议用textarea或者轻盈的富文本编辑器来实现，不要把整个富文本编辑器说得太重，选一个能用、好接入的就行；提问功能建议设计成独立的问答表，每个问题可以关联多个回答，但要设定答采纳状态；收藏功能用一张收藏表存user_id和content_id的关联即可；点赞功能建议做在内容表上加一个like_count字段，每次点击直接更新，不用单独建表，虽然不能用真实生产环境里最严格的数据一致性标准来衡量，但在毕设场景和这个并发规模下完全没问题。同时，互动之后用户会看到内容热度提升，这种反馈是社区活跃起来的重要推手。
3.4 后台管理模块：内容审核、数据概览，缺一不可
后台是展示项目管理能力的地方，也是很多同学容易忽略的部分。农业信息平台的运营特殊性在于：内容必须可管可控。一个普通用户在平台上发布了一篇"使用某种高浓度农药能根治病虫害"的帖子，如果平台不加审核直接放出去，可能误导大量农户。所以后台必须要有一个简单的审核流程。
我的建议是：前台用户发布或编辑的内容先进入待审核状态，管理员在后台看到待审核列表，点开内容详情后可以选择通过、驳回、删除。驳回的时候填一下原因，前端用户能够看到驳回反馈。然后在首页或后台右上角放几个统计数字：用户总数、内容总数、今日访问量、待审核数量。这些统计用简单的 SQLCOUNT就能实现，一点技术难度都没有，但视觉上会让你的系统显得特别完整。
4. 数据库设计落地：七张核心表撑起整个业务
功能规划完之后，数据库表结构设计是整个项目里最见功力的部分。很多毕设的数据库表设计得很"野"——想到一个功能就建一张表，字段命名混乱，没有关联约束，结果后面代码越写越乱，改需求时牵一发动全身。
4.1 表结构设计的"边界思维"：做到刚刚够就好
设计数据库表时最忌讳"过度设计"。比如用户表，不需要把身份证号、邮箱、密码问题、密保答案这些字段全塞进去；再比如文章表，把浏览量、点赞量这些需要频繁更新的统计数据直接放在文章表里，而不必单独建统计表。凡事以"当前业务模式是否真正需要"为准。
但反过来"不够"也不行。有一个很常见的坑是漏掉逻辑删除字段。用户删除了自己发布的文章，如果数据库里直接DELETE FROM物理删除，那这个用户点赞的关联数据、评论数据都会变成孤儿数据或报错。正确的做法是加上一个deleted字段，默认值 0，删除操作改成UPDATE ... SET deleted=1，也就是逻辑删除。MyBatis Plus 内置的逻辑删除配置就在前面展示的application.yml中，开启之后所有查询都会自动过滤掉已逻辑删除的数据。
4.2 核心表结构定义
以下是要优先建立起来的七张核心表，字段尽量精简到足够支撑主要功能即可。
user 用户表
CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像地址', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `role` tinyint(4) NOT NULL DEFAULT '0' COMMENT '角色：0普通用户，1创作者，2管理员', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1正常，0禁用', `deleted` tinyint(4) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';category 分类表
CREATE TABLE `category` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `parent_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '父分类id，0为顶级分类', `name` varchar(50) NOT NULL, `sort` int(11) DEFAULT '0' COMMENT '排序权重', `deleted` tinyint(4) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分类表';content 内容表（文章和视频课程统一在这张表里）
CREATE TABLE `content` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '作者id', `category_id` bigint(20) NOT NULL COMMENT '分类id', `title` varchar(200) NOT NULL COMMENT '标题', `summary` varchar(500) DEFAULT NULL COMMENT '摘要', `cover` varchar(255) DEFAULT NULL COMMENT '封面图', `body` longtext COMMENT '图文内容', `video_url` varchar(255) DEFAULT NULL COMMENT '视频地址', `content_type` tinyint(4) NOT NULL DEFAULT '0' COMMENT '类型：0文章，1视频课程', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '审核状态：0待审核，1已发布，2驳回，3下架', `view_count` int(11) NOT NULL DEFAULT '0', `like_count` int(11) NOT NULL DEFAULT '0', `favorite_count` int(11) NOT NULL DEFAULT '0', `deleted` tinyint(4) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category_id` (`category_id`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='内容表';comment 评论表
CREATE TABLE `comment` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `content_id` bigint(20) NOT NULL COMMENT '内容id', `user_id` bigint(20) NOT NULL COMMENT '评论人id', `parent_id` bigint(20) DEFAULT NULL COMMENT '父评论id，为NULL表示顶级评论', `content` varchar(500) NOT NULL, `deleted` tinyint(4) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';question 问答表
CREATE TABLE `question` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `title` varchar(200) NOT NULL, `content` text, `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0未解决，1已解决', `answer_count` int(11) NOT NULL DEFAULT '0', `deleted` tinyint(4) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='问答表';answer 回答表
CREATE TABLE `answer` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `question_id` bigint(20) NOT NULL, `user_id` bigint(20) NOT NULL, `content` text NOT NULL, `accepted` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否被采纳：1是，0否', `deleted` tinyint(4) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='回答表';favorite 收藏表
CREATE TABLE `favorite` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL, `content_id` bigint(20) NOT NULL, `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_content` (`user_id`, `content_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='收藏表';4.3 表关联逻辑与查询路径设计
设计表时先想清楚查询路径，再确认索引。以"查询某位用户收藏过的所有文章列表"为例，要经过的路径是：favorite表按user_id查出一批content_id，再通过content表的主键IN查询拿回文章的具体信息。这条路径在表设计里就要能走通。
有一个地方特别容易踩坑：查询列表时文章作者信息。在前端列表页需要同时显示文章的标题、封面、作者昵称、发布时间，而作者昵称在user表里。常规做法是把content表和user表联表查询，在content表的查询里LEFT JOIN user一起查出作者信息。但作者信息是经常变化的，且列表里往往需要分页，联表查询加上分页如果性能不佳，就很容易出问题。更稳妥的方法是设计一个"内容展示信息重构"的封装层，在 Service 层先查内容列表，再根据内容里的user_id批量查询用户昵称，然后组装成前端需要的 VO（视图对象）。这个操作看起来多了一步，但避免了大分页联表的隐患，代码逻辑也更清晰。
5. 前端页面背后的 HTML5 关键实践：语义化、响应式、多媒体
前端部分是很多同学的薄弱环节，也是拉开项目完成度差距的地方。题目明确写了"基于 HTML5"，这部分反而可以成为你的亮点。
5.1 语义化标签：页面结构首先是一张"知识地图"
HTML5 最直观的变化就是引入了一批语义化标签。在农业信息学习平台里，我建议这样组织页面结构：页面顶部用header放置站点 logo 和导航栏，导航用nav包裹；中部主体用main承载页面核心内容；侧边栏或者附加信息用aside；按逻辑块划分使用section；独立成篇的内容，比如某篇农业技术文章的详情，用article包裹；页脚版权信息用footer承载。
这样写的好处不只是"规范"，更重要的是可读性和可维护性。你想想看，当你要在论文里画前端页面结构图时，语义化标签天然就是一张层次分明的结构树，你几乎不用费劲去解释每个标签是干什么的。这也省了你很多事。
5.2 响应式布局：用 Flex 布局实现卡片自适应
页面要适配电脑和手机端的访问，这个在农业信息场景里尤其重要——很多用户就是在田间地头用手机翻资料的。通过 CSS3 媒体查询和 Flex 布局的组合，可以用最朴素的方式实现响应式。
页面中的内容卡片列表使用 Flex 布局时，核心思路是让卡片在容器里自动换行，并根据屏幕宽度调整卡片宽度：
.card-list { display: flex; flex-wrap: wrap; gap: 20px; } .card-list .card { flex: 1 1 300px; max-width: 360px; background: #fff; border-radius: 10px; box-shadow: 0 2px 8px rgba(0, 0, 0, 0.08); padding: 16px; } @media (max-width: 768px) { .card-list .card { flex-basis: 100%; max-width: 100%; } }在电脑上，三张卡片一行排列；在手机上，卡片自动变成一列。布局从"灵活多列"过渡到"单列堆叠"，用户阅读体验就好很多。
5.3 多媒体能力：视频课程与图表展示
农业技术教学视频是学习平台里最有价值的内容载体。HTML5 的video标签自带控件、支持进度条、音量调节、全屏播放，不需要任何插件。你只需要在数据库里存好视频文件的访问 URL，前端渲染时动态拼接到video标签的src属性上即可。这里有一个建议：视频文件不要直接放在项目内嵌的静态资源文件夹里，而是放在一个可配置的上传目录，然后通过一个映射路径对外访问，这样在后续改配置、移动服务器文件的时候，就不会把数据全搞丢了。
数据可视化也好用。如果要展示平台内容的浏览趋势或者分类统计，可以在后台图表页面使用canvas配合原生 JavaScript 画一个简单的柱状图，不引入第三方图表库。这个演示效果在答辩现场会很加分，因为老师能一眼看出你是真的理解页面的渲染逻辑，而不是只会调用别人封装好的组件。
5.4 前端与后端交互：Fetch 接口调用的工程化习惯
前后端交互采用标准的fetch或axios发送 JSON 请求即可。这里重点是培养一个"统一封装"的习惯，把请求逻辑抽成一个公共方法，统一处理 token 携带、错误提示、返回结构解析。这样后端的接口路径即使有调整，前端的修改成本也很小，每个页面都直接调用管理 API 的模块，就不会出现改一个接口名要翻十几个页面找代码的情况。
const api = { get: async function (url) { const res = await fetch(url, { headers: { 'Authorization': localStorage.getItem('token') || '' } }); return res.json(); }, post: async function (url, data) { const res = await fetch(url, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': localStorage.getItem('token') || '' }, body: JSON.stringify(data) }); return res.json(); } };这里我强调了在农业信息学习平台里的落地场景：文章列表加载用api.get('/api/content/list?categoryId=' + categoryId)，收藏操作调用api.post('/api/favorite/add', { contentId: id })。让代码逻辑一目了然。
6. 从零到答辩：开发顺序、经典技术坑、演示准备清单
最后这部分是最实战的环节。这个项目做下来，最有价值的部分往往不是功能清单，而是整个研发过程里积累的经验教训。
6.1 推荐的四阶段开发节奏
毕设开发周期一般是三到四个月，建议按四个里程碑推进：
- 第一阶段（约2周）：完成项目骨架搭建、数据库建表、SpringBoot 启动、用户登录注册与 JWT 认证打通；
- 第二阶段（约3周）：完成学习模块，包括分类管理、内容发布、列表分页、详情页展示、富文本图片上传；
- 第三阶段（约3周）：完成分享互动模块，包括评论、收藏、点赞、问答、个人中心；
- 第四阶段（约2周）：完成后台管理端、页面美化、整体功能测试、演示数据准备与论文撰写。
如果基础比较薄弱，第一阶段的周期可以适当拉长，因为后续所有功能都要在认证体系之上做，登录拉胯了，后续接口测试都会很麻烦。
6.2 五个翻车概率最高的坑
第一，数据库连接乱码问题。如果建库时字符集不是utf8mb4，前端提交的中文内容存进数据库再读出来就是一片问号。建库时一定要执行CREATE DATABASE agri_platform DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci。
第二，跨域问题。开发阶段前端跑在 8081 端口，后端跑在 8080 端口，前后端端口不一致就会触发浏览器跨域拦截。解决方式是在后端写一个实现WebMvcConfigurer的配置类，加addCorsMappings放行所有来源和请求头。如果部署时前后端放同一个服务下（前端静态文件打包进 SpringBoot 的static目录，或直接放服务器上），自然就不会有跨域了。
第三，文件上传与图片访问路径不一致。这个坑出现的频率极高：你先用本地绝对路径存了图片，数据库里也存了D://upload//xxx.jpg，结果把项目打包部署到别的电脑上时，所有图片都变成 404。解决的办法是不要把绝对路径存进数据库，只存相对路径，例如/upload/2024/05/01/xxx.jpg，然后在本地开发时配置一个本地目录映射，部署时再映射到服务器目录，这样代码和数据就都能携带走了。
第四，分页插件配置漏掉。MyBatis Plus 的分页功能需要显式配置PaginationInnerInterceptor，不配置的话，调用page方法时其实只是查询了所有数据再在内存里分页，一旦数据量上百就卡顿。配置一下就几行代码的事，千万别漏。
第五，JWT 过期时间和拦截器白名单的问题。有的同学登录取到 token，但未配置拦截器放行登录、注册、主页文章列表这些接口，结果前端刷新列表页时请求被拦截器拦下来了，弹出一堆"未登录"的错误提示。记住一个原则：所有用户未登录也能访问的接口，都要在拦截器排除列表里放行。
6.3 答辩演示前一定要准备的三样东西
第一样是充足的演示数据。我见过不少项目代码写得很完整，但数据库里空荡荡的，演示时列表页只有两条数据，点赞数都是 0，整个系统看起来像一个半成品。建议提前录好 30 篇以上文章、10 个以上问题、20 条以上评论，尽量覆盖到每个分类，数据里要有图片封面、有视频链接。这种"饱和式"的演示数据在视觉上能立刻让系统显得有血有肉。
第二样是一套排错的备用方案。演示之前要预演至少三遍完整流程，特别是要从用户的视角走通：登录→浏览文章→评论→提问→发布内容→管理员审核→前台看到审核结果。如果中途发现某个环节有 bug，及时修复并再次验证。实在无法修复的地方，也一定要准备好"如果老师问到这个功能，我怎么回答它是可扩展预留的"，而不是当场手忙脚乱地调试。
第三样是核心代码的讲解词。答辩时老师让你展示代码，你要能快速找到这几个关键位置并讲清楚：JWT 认证拦截器的实现、分页查询的写法、文章审核状态流转逻辑、表结构里外键或逻辑关联的设计理由。这部分的语言组织，比你背一百页论文效果都好。
我在实际跟同学们一起做这类项目的过程中最大的感触是：这个题目像一块标准画布——它本身没有特别刁钻的地方，但是最终出来的画面精不精致、细节完不完整，完全取决于你的工程习惯。把业务功能先梳理成可落地的数据表和接口，再一层一层把页面填充上去，一步一个脚印走完，你的毕业设计自然就能成为一个真正经得起推敲且经得起问询的完整作品。
