企业官网建设流程全解析

简介：这份资源是一篇基于微信小程序的智慧农业系统毕业设计论文，面向计算机相关专业学生及需要完成类似课题的开发者，帮助解决传统农业管理中效率低、安全性差、信息传输不准确等问题。压缩包内共1个docx文档，约3.61MB，即论文正文，涵盖摘要、系统设计、功能实现与总结等完整章节。论文采用Uni-weixin与Spring Boot框架，前端以微信小程序页面呈现，后台使用Java语言开发，MySQL数据库存储数据，详细设计了用户注册登录、个人信息修改、知识科普、土壤信息管理、水质信息管理及购物商城等功能模块。目前已有108人学习下载，适合作为毕业设计选题参考、论文写作模板或智慧农业类小程序开发的技术方案借鉴，读者可从中获取完整的系统架构思路、功能模块划分与实现方法，为自身课题提供可复用的参考路径。

1. 从一份毕设文档到能跑的小程序：这套智慧农业源码到底值不值得拆

如果你正在找一份能直接跑起来的微信小程序毕业设计，又恰好对农业信息化这个方向有点兴趣，那这份基于 Uni-weixin + Spring Boot 的智慧农业小程序文档值得花时间拆一拆。它不是那种只有几张截图的空壳论文，而是把用户端、管理端、数据库表结构、E-R 图、测试用例都写全了的完整交付物。用户端覆盖知识科普、土壤信息、水质信息、购物商城、论坛交流、天气查询，管理端则把这些模块的增删改查全包了。适合两类人：一是需要快速搭出毕设骨架的在校生，二是想拿一个前后端分离的小程序项目练手 Spring Boot 接口开发的初级开发者。文档里最值钱的部分其实是第 4 章的数据表设计，token 表、评论表、关于我们表都给了字段类型和长度，照着建库能省掉大量试错时间。

2. 技术选型拆解：为什么是 Uni-weixin + Spring Boot 而不是别的

2.1 前端选 Uni-weixin 的实际考量

Uni-weixin 这个说法在毕设文档里经常出现，本质上就是基于微信小程序原生开发规范来写页面。为什么不用 uni-app 做跨端？因为毕设场景下，评审老师要看的是你对微信小程序生命周期、WXML 模板语法、WXSS 样式隔离的理解，而不是跨端兼容性。用原生方式写，Page对象的onLoad、onShow、onPullDownRefresh这些钩子函数在论文里能写出明确的调用时机说明，答辩时也好讲。

从文档第 2 章的描述看，前端页面结构大致是这样的：首页做功能入口聚合，知识科普和土壤信息、水质信息走列表加详情页的模式，购物商城需要处理商品列表、详情、下单、订单列表这条链路，论坛交流则涉及发帖、回帖、我的帖子。天气模块通常是调第三方接口拿数据渲染，文档里没展开，但常见做法是接一个免费天气 API，在小程序端做请求转发。

这里有个容易被忽略的点：微信小程序对request合法域名有白名单限制。开发阶段可以在开发者工具里勾选“不校验合法域名”，但真机预览和上线必须配置。很多毕设项目在本地跑得好好的，一上真机就请求失败，根因就在这。

2.2 后端 Spring Boot 的分层逻辑

文档明确写了用 Java 语言和 Spring Boot 框架，数据库是 MySQL。这套组合在毕设里属于稳妥牌，资料多、报错好搜、答辩时老师也熟悉。从功能模块反推，后端至少需要这几层：

• Controller 层：接收小程序端的 HTTP 请求，处理参数校验和路由分发。比如/knowledge/list、/soil/detail、/cart/add这类接口。
• Service 层：写业务逻辑，比如下单时扣库存、发帖时敏感词过滤、收藏时去重判断。
• Mapper/DAO 层：用 MyBatis 或 MyBatis-Plus 操作数据库。文档里给了 token 表和评论表的字段，说明登录态是用 token 维持的，评论功能是挂在知识科普、土壤信息、水质信息、购物商城四个实体下的。
• Entity 层：和数据库表一一对应的实体类。

一个典型的接口调用链路是这样的：小程序端wx.request发请求 → Spring Boot Controller 接收 → Service 处理业务 → Mapper 查库 → 返回 JSON → 小程序setData渲染。

2.3 MySQL 表结构设计的可复用点

文档第 4 章的数据表设计是整份材料里最实在的部分。以 token 表为例：

这张表的设计思路是：用户登录成功后生成一个 token，同时记录这个 token 属于哪张表（tablename）、哪个角色（role），后续请求带着 token 来，后端校验 token 是否存在且未过期。expiratedtime默认值给CURRENT_TIMESTAMP其实不太合理，正常应该在插入时由代码计算一个未来时间，比如当前时间加 2 小时。这个坑后面会细说。

评论表的设计也值得注意。知识科普评论表、土壤信息评论表、水质信息评论表、购物商城评论表这四张表结构完全一致，都是id、addtime、refid、userid、avatarurl、nickname、content、reply。这种设计的好处是简单直接，坏处是四张表冗余。如果让我重构，会合并成一张comment表，加一个type字段区分评论对象。但毕设场景下，分开建表反而方便在论文里画 E-R 图，每个实体对应一张评论表，逻辑清晰。

3. 从零把项目跑起来：环境、建库、接口联调三步走

3.1 开发环境搭建与依赖版本对齐

文档给的硬件环境是 i5-7400 + 8GB 内存，软件环境是 Windows 10 64 位 + Eclipse。这个配置跑 Spring Boot + MySQL + 微信开发者工具是够的，但 Eclipse 对 Spring Boot 的支持不如 IntelliJ IDEA 顺手。如果你不排斥换工具，建议用 IDEA 社区版，对 Maven 依赖管理和 Spring Boot 启动类的识别更友好。

环境搭建的步骤：

1. 安装 JDK 8 或 JDK 11。Spring Boot 2.x 对这两个版本支持最好，JDK 17 以上有些老依赖会报模块化错误。
2. 安装 MySQL 5.7 或 8.0。5.7 和 8.0 在驱动类名上有区别，5.7 用com.mysql.jdbc.Driver，8.0 用com.mysql.cj.jdbc.Driver，连接 URL 也要加时区参数。
3. 安装 Maven，配置阿里云镜像加速依赖下载。
4. 安装微信开发者工具，用微信扫码登录。
5. 安装 Node.js（如果前端有 npm 构建步骤，原生小程序一般不需要，但有些模板会用到）。

提示：JDK 版本、MySQL 版本、Spring Boot 版本三者要对齐。常见翻车场景是 JDK 17 + Spring Boot 2.3 + MySQL 5.7 驱动，启动时报NoClassDefFoundError，换 JDK 8 或升 Spring Boot 到 2.7 就能解决。

3.2 数据库建表与初始数据导入

拿到源码后，第一件事是找 SQL 文件。通常在src/main/resources目录下会有schema.sql或init.sql。如果没有，就照着文档第 4 章的表结构手动建。

以 token 表为例，建表语句：

CREATE TABLE `token` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `userid` bigint(20) NOT NULL COMMENT '用户id', `username` varchar(100) DEFAULT NULL COMMENT '用户名', `tablename` varchar(100) DEFAULT NULL COMMENT '表名', `role` varchar(100) DEFAULT NULL COMMENT '角色', `token` varchar(200) DEFAULT NULL COMMENT '密码', `addtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '新增时间', `expiratedtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '过期时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='token表';

逻辑说明：id自增主键，userid关联用户表，token存登录凭证，expiratedtime存过期时间。参数上，varchar(200)对 token 来说够用，JWT 一般也就 150 字符左右。utf8mb4字符集支持 emoji，评论内容里如果有表情不会乱码。

评论表建表语句（以知识科普评论表为例）：

CREATE TABLE `knowledge_comment` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `addtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `refid` bigint(20) NOT NULL COMMENT '关联表id', `userid` bigint(20) NOT NULL COMMENT '用户id', `avatarurl` longtext COMMENT '头像', `nickname` varchar(200) DEFAULT NULL COMMENT '用户名', `content` longtext COMMENT '评论内容', `reply` longtext COMMENT '回复内容', PRIMARY KEY (`id`), KEY `idx_refid` (`refid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='知识科普评论表';

逻辑说明：refid指向知识科普文章的主键，加索引是为了按文章查评论时走索引扫描。avatarurl用longtext存头像地址，实际生产环境应该用varchar(500)就够了，longtext有点浪费，但毕设无所谓。

建完表后，需要插入一条管理员账号和几条测试数据。管理员密码通常用 MD5 加密存储，如果源码里没给初始密码，可以自己用 MD5 工具生成一个，比如admin123的 MD5 是0192023a7bbd73250516f069df18b500。

3.3 后端启动与接口联调

后端启动流程：

1. 修改application.yml或application.properties里的数据库连接配置：

spring: datasource: url: jdbc:mysql://localhost:3306/smart_agriculture?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

参数说明：serverTimezone=Asia/Shanghai解决 MySQL 8.0 时区报错，characterEncoding=utf-8防止中文乱码，useUnicode=true配合使用。

2. 找到启动类，通常是Application.java或XxxApplication.java，右键 Run As → Java Application。
3. 控制台看到Started Application in x.x seconds说明启动成功。
4. 用 Postman 或浏览器访问http://localhost:8080/knowledge/list，看是否返回 JSON 数据。

前端联调：

1. 微信开发者工具导入小程序项目目录。
2. 修改app.js或config.js里的baseUrl，指向http://localhost:8080。
3. 在开发者工具右上角详情 → 本地设置 → 勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。
4. 点击编译，看首页是否正常渲染。

注意：如果后端接口返回 401 或 403，检查 token 校验逻辑。常见做法是在拦截器里判断请求头有没有 token，没有就返回未登录。调试阶段可以先在拦截器里放行所有请求，等前端跑通再打开校验。

4. 避坑与排查：这五个问题我踩过三次以上

4.1 小程序请求本地接口报“不在以下 request 合法域名列表中”

现象：开发者工具里请求http://localhost:8080成功，真机预览时所有接口失败，控制台报域名不合法。

原因：微信小程序对网络请求有域名白名单限制，localhost和 IP 地址不在白名单内，只有 HTTPS 域名才能配置。

解决：开发阶段在开发者工具里勾选“不校验合法域名”，真机调试时打开调试模式。上线前需要把后端部署到有 HTTPS 证书的服务器，在微信公众平台配置 request 合法域名。

4.2 token 过期时间默认值导致登录态永远有效

现象：用户登录后，token 一直有效，退出登录再进来还是已登录状态。

原因：token 表的expiratedtime字段默认值是CURRENT_TIMESTAMP，插入时如果代码没有显式设置过期时间，就会用当前时间。但校验逻辑如果只判断 token 是否存在、不判断是否过期，就会导致 token 永不过期。

解决：在登录接口里，生成 token 后手动设置expiratedtime为当前时间加 2 小时。校验时加一个条件：expiratedtime > NOW()。

4.3 MySQL 8.0 连接报“Public Key Retrieval is not allowed”

现象：后端启动时连数据库失败，报com.mysql.cj.exceptions.CJException: Public Key Retrieval is not allowed。

原因：MySQL 8.0 默认使用caching_sha2_password认证插件，JDBC 连接需要显式允许公钥检索。

解决：在连接 URL 后加allowPublicKeyRetrieval=true，或者把 MySQL 用户认证插件改成mysql_native_password。

4.4 评论功能插入数据时 avatarurl 字段超长报错

现象：用户头像 URL 较长时，插入评论表报Data too long for column 'avatarurl'。

原因：文档里avatarurl用的是longtext，理论上不会超长。但如果实际建表时误用了varchar(100)，微信头像 URL 通常超过 100 字符，就会报错。

解决：检查表结构，把avatarurl改成varchar(500)或longtext。微信头像 URL 一般 120 到 200 字符，varchar(500)足够。

4.5 购物商城下单后库存没扣减

现象：用户下单成功，订单表有记录，但商品表库存没变，导致超卖。

原因：下单接口只写了插入订单逻辑，没写扣库存逻辑。或者扣库存和插订单不在同一个事务里，插订单成功、扣库存失败。

解决：在 Service 层的下单方法上加@Transactional注解，先查库存是否充足，再扣库存，最后插订单。任何一步失败都回滚。

5. 进阶用法：把毕设项目改造成能写进简历的实战项目

5.1 用 JWT 替换原生 token 表

文档里的 token 方案是存库校验，每次请求都要查一次 token 表。用户量上来后，token 表会成为性能瓶颈。进阶做法是用 JWT（JSON Web Token），把用户 id、角色、过期时间编码进 token 字符串，后端验签即可，不用查库。

改造步骤：

1. 引入jjwt依赖。
2. 写一个JwtUtil工具类，包含生成 token 和解析 token 两个方法。
3. 登录成功后返回 JWT，前端存到wx.setStorageSync。
4. 拦截器里解析请求头中的 JWT，验签通过则放行。

public class JwtUtil { private static final String SECRET = "your-secret-key"; private static final long EXPIRATION = 7200_000; // 2小时 public static String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

逻辑说明：generateToken把用户 id 作为 subject，角色作为自定义 claim，设置签发时间和过期时间，用 HS256 算法签名。parseToken验签并返回 Claims，如果 token 过期或签名不对会抛异常。参数上，SECRET要足够复杂，生产环境应该放在配置中心或环境变量里，不要硬编码。

5.2 给土壤信息和水质信息加数据可视化

文档里的土壤信息字段有土壤容重、土壤含水量、田间持水量、酸碱度、质地名称、地形地势。这些数据如果只以文字列表展示，用户感知不强。进阶做法是用 ECharts 或 uCharts 在小程序端画折线图、柱状图。

以 uCharts 为例，在土壤详情页加一个含水量趋势图：

// 在 Page 的 data 里定义图表配置 data: { chartData: { categories: ['1月', '2月', '3月', '4月', '5月', '6月'], series: [ { name: '含水量', data: [22, 25, 28, 30, 27, 24] } ] } }

逻辑说明：categories是 X 轴标签，series是数据系列。实际项目中，这些数据应该从后端接口按时间范围查询返回，前端只负责渲染。参数上，uCharts 的type可以设为line、column、area等，按需选择。

5.3 用定时任务做天气数据缓存

天气模块如果每次用户打开都调第三方 API，一是慢，二是可能触发限流。进阶做法是用 Spring Boot 的@Scheduled注解，每小时拉一次天气数据存到 Redis 或本地缓存，用户请求时直接读缓存。

@Component public class WeatherTask { @Autowired private WeatherService weatherService; @Scheduled(cron = "0 0 * * * ?") public void fetchWeather() { weatherService.updateWeatherCache(); } }

逻辑说明：@Scheduled的 cron 表达式0 0 * * * ?表示每小时整点执行一次。fetchWeather方法调 Service 层更新缓存。参数上，cron 表达式可以根据实际需求调整，比如每 30 分钟执行一次就改成0 0/30 * * * ?。

5.4 验证改造是否成功的三个检查点

改造完成后，怎么确认没改坏？我一般会走这三步：

1. 接口回归：用 Postman 把登录、知识科普列表、土壤详情、购物车添加、下单、评论这六个核心接口跑一遍，看返回码和数据结构是否正常。
2. 登录态测试：登录后等 2 小时，再请求需要登录的接口，看是否返回 401。如果还能访问，说明 JWT 过期时间没生效。
3. 并发下单测试：用 JMeter 或 Apache Bench 模拟 10 个并发请求同时下单同一商品，看库存是否扣到负数。如果扣成负数，说明事务或锁没加对。

从那以后我每次拿到一个毕设项目，都会先跑通登录和列表接口，再动其他模块。先把主链路走通，再补细节，比一上来就改架构稳得多。希望帮到你。

本文还有配套的精品资源，点击获取