企业官网建设流程全解析

简介：这套毕业设计资源面向计算机相关专业毕业生及从事微信小程序开发的学习者，以 Java 为后端、微信小程序为前端，完整呈现精准扶贫数据收集平台的开发过程与交付物。系统围绕贫困对象精准画像、扶贫工作线上安排、帮扶政策与新闻在线展示等模块展开，适合用于毕业设计参考、项目复现或技术进阶练习。压缩包共 503 个文件，大小约 106.62MB，涵盖 Java 源码、class 编译文件、xml 配置、js/wxml/wxss 小程序页面代码、png/jpg 图片素材、SQL 数据库脚本及演示视频等，目录结构清晰，便于对照学习和部署调试。目前已有 229 人学习下载。资源内包含后端核心控制器、数据访问对象与 Excel 导出工具等实现，有助于理解接口设计、数据持久化、文件导入导出及业务分层思路。

1. 打开这份 Java 毕设压缩包之前，你得先想清楚一件事

每年毕业季，都会有人从网盘里拉下来一个“基于微信小程序的精准扶贫数据收集小程序平台”的压缩包，解压后看到后端、小程序、数据库三个文件夹，以为导入 IDE 就能跑。真实情况是：这一脚踩进去，后端启动即崩、小程序白屏、数据库连接报错，三件事通常会连着来。这个课题的本质是一套“微信小程序前端 + Java 后端 + MySQL 数据库”的三层结构，前端负责让扶贫干部在手机上录数据，后端负责查重、存储和统计，数据库负责把贫困户、走访记录、帮扶措施这些信息落盘。它适合两类人：一类是拿它当毕设底子、准备改造成自己题目的学生，另一类是已经在做“入户数据采集”类小程序、想借鉴表结构和接口设计的从业者。动手之前，先认清它不是什么黑匣子，而是一个可以按层拆开、逐层复现的常规 Web 工程。

2. 技术选型：为什么非要是“微信小程序 + Java”，以及怎么把这两层跑起来

2.1 选型理由：原生小程序和 Java 后端是怎么凑到一起的

微信小程序前端是这套系统唯一面向用户的界面，扶贫干部不需要装 App，微信里扫一扫就能打开，这解决了“要下乡、要入户、手机内存小”的痛点。而 Java 后端负责两件事：一是提供 HTTP 接口给小程序调，二是做业务校验，比如身份证号是否重复、走访时间是否合法。为什么不是 PHP 或 Node？因为高校软件工程类毕设的教学大纲普遍以 Java 为主线，且 Spring Boot 对新手最友好——一个main方法就能起服务，比写一大堆 SSH 配置要省事得多，也容易被答辩老师接受。

小程序端用原生语言（WXML + WXSS + JS）而不是 uni-app，原因很直接：这个毕设的演示视频里展示的是“微信开发者工具”的界面，用原生框架打开工程就能跑，不用再走 uni-app 的编译打包流程。如果你后续想同时出 Android 或 H5 版本，再迁移到 uni-app 也不迟，但毕设阶段原生版最少踩坑。

2.2 跑通后端最小配置：pom.xml 和 application.yml 里的六个必调参数

打开后端工程，先不要急着点运行，把pom.xml和application.yml过一遍。Spring Boot 版本建议用 2.7.x，搭配 MyBatis 和 MySQL 8.0，这个组合在网上的资料最全，遇到报错能搜到大量现成答案。下面是一份能直接抄的最小pom.xml：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

这段配置的逻辑是：spring-boot-starter-parent锁住依赖版本，web提供接口能力，MyBatis 负责把 SQL 和 Java 方法绑定，MySQL 驱动负责通信，Lombok 用来省掉 getter/setter。注意 MySQL 驱动坐标在 8.x 之后变成了mysql-connector-java，如果你拿到的源码里写的是com.mysql.jdbc.Driver，那是 5.x 时代的写法，必须改掉。

接下来看application.yml，这是最容易翻车的地方：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/poverty_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.poverty.entity configuration: map-underscore-to-camel-case: true

URL 里那串参数是血泪经验：characterEncoding=utf8保证中文不乱码，serverTimezone=Asia/Shanghai解决 MySQL 8.0 的时区报错，useSSL=false避免本地连接时出现 SSL 警告。map-underscore-to-camel-case设置为 true 后，数据库的user_name字段能自动映射成 Java 里的userName，这一步能省掉大量手写 ResultMap 的时间。

2.3 小程序端导入与 baseUrl 指向：让前端找到后端

后端能启动后，打开微信开发者工具，选择“导入项目”，目录指向压缩包里的小程序文件夹。AppID 选“测试号”就行，不需要注册正式的小程序账号——毕设演示场景下，测试号完全够用。导入成功后，第一件事是改utils/request.js里的请求地址：

const BASE_URL = 'http://127.0.0.1:8080' function request(path, method = 'GET', data = {}) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + path, method: method, data: data, header: { 'Content-Type': 'application/json' }, success: (res) => resolve(res.data), fail: (err) => reject(err) }) }) } module.exports = { request, BASE_URL }

这段代码把所有的网络请求收敛到一个文件里。以后要换后端服务器地址，只改BASE_URL一处即可，不用在几十个页面里逐个wx.request去翻。127.0.0.1表示本机回环地址，适用于“小程序开发者工具 + 本地 Java 服务”的组合。如果你用的是真机预览，这里必须改成电脑在局域网里的 IP，比如http://192.168.1.101:8080，否则手机会因为访问不到127.0.0.1而直接请求失败——这条规则不搞清楚，后面调接口时大概率会对着屏幕怀疑人生。

3. 数据库设计：精准扶贫系统的核心不是代码，是那几张表和它们的关系

3.1 三张核心表：贫困信息、走访记录、帮扶记录

数据收集平台的本质是“一次录入、多次查询、按月统计”。我最先建的表是poverty_info，也就是贫困户主表，字段包括户编号、姓名、身份证号、家庭住址、致贫原因、家庭人口数、是否享受低保、建档时间。身份证号这一列必须加唯一索引，因为它是判断“这个户是不是已经建档”的天然业务主键，数据库层面兜底，比在 Java 代码里select count再判断要可靠得多。

然后是visit_record走访记录表，字段有走访 ID、户编号、走访人、走访日期、走访内容、现场照片路径。这张表跟贫困信息表通过户编号关联，一个贫困户可以对应多条走访记录，是一对多关系。数据收集平台上“本月走访了多少户”的统计报表，就是group by这张表的走访日期算出来的。

最后是assist_record帮扶记录表，记录具体的帮扶措施，比如“申请低保”“发放种子化肥”“介绍务工岗位”，字段包括帮扶 ID、户编号、帮扶类型、帮扶内容、帮扶时间、帮扶人。这三张表相互独立又通过户编号串成一条线，设计答辩时画一个简单的 ER 图，把主外键关系讲清楚，老师基本不会在这块卡你。

3.2 字段设计里的类型陷阱：为什么你的时间字段统计总是不对

精准扶贫场景里最常踩的坑是时间字段的选型。走访日期和时间要用datetime，建档年份这种只需要到年的用varchar(4)存“2024”比用date更省事。手机号、身份证号这种看起来像数字的字段一律用varchar，不要用bigint，原因是身份证号有 18 位，超出部分在 Java 的长整型里虽然放得下，但在前端展示时会出现精度丢失——后两位变成 0，数据一错就再也找补不回来了。

另一个坑是“致贫原因”这类可选值字段。有人喜欢用int存 1、2、3，然后在 Java 里维护一份枚举映射，但实际使用中扶贫干部会现场录入“因学”“因病”“因灾”等混合原因，数字枚举根本不够用。我的习惯是存原始字符串，比如“因病、因学”，统计时用like '%因病%'去匹配，灵活度远高于数字枚举。代价是查询稍慢，但几千条数据的量级完全感觉不到差别。

3.3 SQL 落地：建表语句与初始化数据的一次性交付

把三张表串起来，建表脚本可以直接复用下面这份，字段命名保持下划线风格，配合 MyBatis 的自动驼峰映射能省很多事：

CREATE DATABASE IF NOT EXISTS poverty_db DEFAULT CHARSET utf8mb4; USE poverty_db; CREATE TABLE poverty_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, household_code VARCHAR(20) NOT NULL COMMENT '户编号', name VARCHAR(50) NOT NULL COMMENT '户主姓名', id_card VARCHAR(18) NOT NULL COMMENT '身份证号', address VARCHAR(200) COMMENT '家庭住址', poverty_reason VARCHAR(100) COMMENT '致贫原因', family_members INT DEFAULT 1 COMMENT '家庭人口数', is_low_income TINYINT DEFAULT 0 COMMENT '是否低保，0否1是', created_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_id_card (id_card), UNIQUE KEY uk_household_code (household_code) ) ENGINE=InnoDB COMMENT '贫困信息主表'; CREATE TABLE visit_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, household_code VARCHAR(20) NOT NULL, visitor VARCHAR(50) COMMENT '走访人', visit_date DATETIME COMMENT '走访日期', visit_content TEXT COMMENT '走访内容', photo_url VARCHAR(255) COMMENT '现场照片路径', KEY idx_household (household_code), CONSTRAINT fk_visit_poverty FOREIGN KEY (household_code) REFERENCES poverty_info (household_code) ) ENGINE=InnoDB COMMENT '走访记录表';

建表后顺手插入两条测试数据，方便后端接口联调时马上能看到返回结果。管理员账号一般存在sys_user表里，密码用 MD5 加盐存储——这里给个提示：如果拿到的源码里密码是明文存的，不是不能用，但答辩时如果被问到安全问题会比较尴尬，至少改成MD5(password + salt)的形式，十几行代码就能搞定，演示时也能多一个亮点。

4. Java 后端落地：从 Controller 到 MyBatis 的建档接口全流程

4.1 统一返回体设计：让小程序端不用再猜接口返回了什么

小程序端和后端交互的数据格式如果不统一，前端代码会写出一堆if (res.code === 1)之类的特殊判断，改起来非常痛苦。我的做法是定义一个通用的返回对象，所有接口都走它，前端统一处理：

@Data public class ApiResponse<T> { private Integer code; private String message; private T data; public static <T> ApiResponse<T> success(T data) { ApiResponse<T> res = new ApiResponse<>(); res.code = 200; res.message = "ok"; res.data = data; return res; } public static <T> ApiResponse<T> error(String message) { ApiResponse<T> res = new ApiResponse<>(); res.code = 500; res.message = message; return res; } }

success和error两个静态方法把常用的返回场景封装掉了，Controller 里一行代码就能返回标准格式。200 表示成功，500 表示业务失败，前端拿到非 200 的 code 直接弹出 message 给用户看，不需要每个页面各写一套错误兼容逻辑。

4.2 建档接口：Controller、Service、Mapper 三层各司其职

建档是“精准扶贫数据收集”里最高频的操作用例，核心逻辑是：前端把表单数据 POST 上来，后端先查身份证号是否已存在，不存在则插入新记录，存在则返回友好提示。Controller 层只做参数接收和结果返回：

@RestController @RequestMapping("/api/poverty") public class PovertyController { @Autowired private PovertyService povertyService; @PostMapping("/create") public ApiResponse<String> create(@RequestBody PovertyInfo info) { try { povertyService.createPoverty(info); return ApiResponse.success("建档成功"); } catch (Exception e) { return ApiResponse.error(e.getMessage()); } } }

Service 层负责业务判断。注意这里我用抛出异常的方式把错误信息传给 Controller 的 catch 分支，比返回boolean再在外层判断要清晰得多：

@Service public class PovertyService { @Autowired private PovertyMapper povertyMapper; public void createPoverty(PovertyInfo info) { if (info.getIdCard() == null || info.getIdCard().isEmpty()) { throw new RuntimeException("身份证号不能为空"); } int count = povertyMapper.countByIdCard(info.getIdCard()); if (count > 0) { throw new RuntimeException("该身份证号已建档，请勿重复录入"); } povertyMapper.insert(info); } }

Mapper 层用注解或者 XML 都行。对于单表插入，注解写起来最简洁；但对于联表查询、动态条件筛选这种复杂场景，XML 的可读性更好。下面用 XML 演示countByIdCard和insert两个操作：

<mapper namespace="com.example.poverty.mapper.PovertyMapper"> <select id="countByIdCard" resultType="int"> SELECT COUNT(*) FROM poverty_info WHERE id_card = #{idCard} </select> <insert id="insert" parameterType="com.example.poverty.entity.PovertyInfo"> INSERT INTO poverty_info (household_code, name, id_card, address, poverty_reason, family_members, is_low_income) VALUES (#{householdCode}, #{name}, #{idCard}, #{address}, #{povertyReason}, #{familyMembers}, #{isLowIncome}) </insert> </mapper>

#{idCard}用的是 MyBatis 的预编译占位符，能防 SQL 注入，这一点答辩时值得主动提一句。parameterType指定的是实体类全限定名，配合type-aliases-package配置后还能写成简写形式。如果拿到的源码里有mybatis-plus依赖，那countByIdCard可以直接用LambdaQueryWrapper，连 XML 都不用写——热词里有人搜 “mybatisplus根据java实体类生成创建表的sql语句”，说明不少同学已经在往这个方向走了，但毕设答辩时手写 SQL 更容易讲清楚字段含义，不建议为省事丢掉基本功。

4.3 小程序端提交建档：request 封装与表单页面

后端接口就绪后，小程序端需要一个表单页把数据送上去。核心代码就是调用之前封装好的request方法：

const { request } = require('../../utils/request') Page({ data: { povertyReasonOptions: ['因病', '因学', '因灾', '缺劳动力', '缺技术'] }, formSubmit(e) { const formData = e.detail.value if (!formData.idCard) { wx.showToast({ title: '身份证号不能为空', icon: 'none' }) return } request('/api/poverty/create', 'POST', formData).then(res => { if (res.code === 200) { wx.showToast({ title: res.message, icon: 'success' }) setTimeout(() => wx.navigateBack(), 1500) } else { wx.showToast({ title: res.message, icon: 'none' }) } }) } })

这段代码里的formSubmit绑定了表单的bindsubmit事件，e.detail.value会一次性把表单里所有name属性的值收集成一个对象。身份证号非空校验放在前端做了，后端 Service 层再做一遍，两层校验不是重复劳动，而是防止有人跳过小程序直接拿 Postman 调接口。res.code === 200判断和后端统一返回体严格对应，如果后端返回的是status或success，前端就要跟着改。

5. 真题实战避坑：从环境配置到接口联调的四个常见问题

5.1 最容易翻车的四个环境级问题

现象一：后端启动时报java.sql.SQLException: The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。原因很直接，MySQL 8.0 的时区设置跟 JDBC 驱动的默认时区对不上。解决方法是把application.yml里数据库 URL 加上serverTimezone=Asia/Shanghai，这行参数在第 2 章已经写在配置里了，如果你拿到的源码没带，补上即可。

现象二：小程序开发者工具里点“编译”，页面一直转圈，控制台提示request:fail。原因一般是请求地址写成了https://，或者用了localhost。解决方法是把BASE_URL改成http://127.0.0.1:8080，然后在开发者工具的“详情 — 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。

现象三：建档时身份证号码后面两位变成了 00。原因是在数据库里把身份证号建成了bigint类型，Java 端拿到的是 Long，前端 JS 的精度只有 16 位，18 位身份证号必然丢失精度。解决方法是把该字段改成varchar(18)，已经建错表的人也不要慌，ALTER TABLE poverty_info MODIFY COLUMN id_card VARCHAR(18)一条 SQL 就能修复。

现象四：MySQL 连不上，报Access denied for user 'root'@'localhost'。原因通常是本机 MySQL 密码跟application.yml里写的不一致。解决方法是先在本机命令行用mysql -uroot -p试出正确密码再改配置文件，而不是反过来改数据库密码。

5.2 把黑匣子变白盒：一套可以复用的排查顺序

接口联调阶段最忌讳东点一下西点一下。我的排查顺序是固定的：先看后端控制台有没有启动成功，再看数据库连接有没有建立，然后打开浏览器的开发者工具或微信开发者工具的 Network 面板看请求到底发出去没有，返回了什么状态码。如果后端压根没收到请求，问题百分百在BASE_URL；如果后端收到了但返回 500，就去翻控制台的堆栈第一行，那上面写的错误信息十有八九就是答案。

还有一个值得养成的习惯：联调时先把小程序端的request函数里的BASE_URL指向一个测试地址，用 Postman 替代前端先验证一遍接口。后端接口在 Postman 里通了，再去调小程序，这样能快速二分定位问题属于后端还是前端。如果 Postman 里也报错，那就回到application.yml和数据表结构上去查，不要在小程序代码里浪费时间。

6. 答辩前最值得做的三个具体改动

把项目跑通只是及格线，答辩时的印象分往往来自三个细节改动。第一个是给走访记录加一条“按走访日期倒序排序”的列表接口，让小程序端先用真机预览跑通一次完整的“登录—建档—走访录入—列表查看”闭环，这比任何口头描述都更有说服力。第二个是写一张接口自测表，把每个接口的 URL、请求参数、预期返回列成表格，答辩时主动递过去，老师能一眼看出你对系统的掌控度。第三个是给小程序端加一个“按乡镇筛选”的下拉筛选框，实现只需要在查询接口上动态拼一个WHERE town = ?，代码改动不到 20 行，但能展示你对业务场景的理解。

我最想叮嘱的养成习惯是：把压缩包里源码的目录结构仔仔细细看一遍，然后自己动手把poverty_info表加一个字段，走一遍“数据库加列 → 实体类加属性 → Mapper 的 insert 加参数 → 小程序表单加输入框”的完整链路。这个过程比背十道 java 面试题都有用，因为答辩老师最常问的就是“如果现在要加一个‘家庭年收入’字段，你要改哪些地方”。真到自己改过，回答这个问题就能从容不迫。

从我接手这类课程设计的经验看，十个学生里至少有四个栽在数据库编码或请求地址这些小问题上，而不是栽在业务逻辑上。把基础的环境链路先理顺，把每一层能改什么边界摸清楚，这个课题就能变成一套讲得清、改得动、演示不翻车的成熟方案。希望帮到你。

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