简介《精准扶贫数据收集》微信小程序毕业设计项目面向计算机相关专业毕业生或需要开发同类信息管理系统的开发者完整覆盖从需求分析到前后端编码、数据库设计、部署演示的毕业设计全流程。项目采用微信小程序与Java MySQL的B/S架构前端实现帮扶对象、扶贫收入、帮扶措施、扶贫统计等模块帮扶工作人员可查看维护帮扶对象信息并记录收入情况后台支持贫困人员信息管理、帮扶责任人管理、文章管理管理员可发布新闻政策与分配责任人员功能贴合实际业务场景。资料包共342个文件压缩后约92.82MB主要包含Java源码与class文件、小程序前端wxml/wxss/js页面、MySQL数据库脚本sql、XML配置及说明文档txt、properties、演示视频等目录按后端、前端、数据库和文档分类便于按需检索。已有325人浏览学习适合需要快速搭建毕业设计项目或理解精准扶贫业务场景的读者可通过源码、数据库和演示视频快速掌握项目运行与开发要点也可以在此基础上扩展二次开发。1. 微信小程序毕设做“精准扶贫数据收集”先想清楚收集的是什么拿到这个标题很多同学第一反应是去找免费源码模板改个列表页加个新增表单就准备交差。但“数据收集”这四个字的重点不在增删改查而在一条数据从走访现场到数据库、再到审核与统计的完整链路。真拿去答辩评审问“数据怎么保证不重复、图片存在哪、提交后能不能驳回重填”只做了列表页的人往往会卡壳。下面我就按这条线路来拆小程序原生做采集端后端提供接口MySQL 存数据覆盖建档录入、拍照上传、位置采集、状态流转、按乡镇汇总统计。这套方案适合正在做毕设、又不想只交一个“假系统”的同学也适合想把这套思路改造成其他行业报表收集场景的开发者。后端按 Python Flask 写核心逻辑换 Java Spring Boot 照搬接口设计即可前端不带框架原生微信小程序就能跑评审最容易认可的就是这种结构清晰、每一行都能解释清楚的版本。2. 先立架子技术选型、角色拆分与一条数据的完整流转动手写代码之前先把用户、页面、数据状态想清楚。数据收集类项目最容易翻车的地方不是某个组件不会用而是表结构没设计好、角色权限不做区分导致后期所有页面都在围着错误的数据模型打补丁。2.1 页面与角色拆分收集端、审核端、展示端各管什么“精准扶贫数据收集”至少牵扯三类角色做入户走访的人负责收集管理员负责审核和驳回看汇总数据的人只需要统计结果。如果只做一个谁都能增删改的页面权限就是空的答辩时被问“怎么防止走访人员篡改已审核数据”就直接暴露了。我一般会拆成六个页面登录页、工作台首页、贫困户信息录入页、走访记录页、待审核列表页、数据统计页。首页作为 tabBar 入口展示待办数量比如“本周待走访 4 户、待审核 3 条”统计页放按乡镇分组的汇总表。这样一个最小闭环就有三件事可以演示收数据、审数据、看数据。权限上不必做得很重用户表里用 role 字段区分 admin 和 worker 即可。worker 只能新增和编辑自己提交的数据admin 能审核、驳回和查看全部页面按钮按 role 做条件渲染后端接口再做一次校验。注意不要只在页面藏按钮接口层不校验等于没权限我用 postman 直接调接口就能越权这是最常见的低级漏洞。2.2 数据流与选型理由为什么原生小程序加 MySQL 是毕设最稳的组合做微信小程序毕业设计最常见的有两条路原生小程序和 uni-app 打包。uni-app 的优势是一次写三端但这个题目只需要微信小程序原生 wxml/wxss/js 不引入额外框架评审问起来每一行都是自己写的这种“诚实感”在答辩现场很值钱。后端不用纠结Flask 或 Spring Boot 都可以数据库统一 MySQL理由只有一个资料最多、报错最好查、换环境成本最低。一条数据从现场到数据库完整链路是这样走访人员在小程序里填表单、拍照图片先通过 wx.uploadFile 传到服务器服务器回图片 URL表单字段和图片 URL 一起以 JSON 提交给后端后端校验通过后写入 MySQL状态置为待审核管理员在待审核列表看详情通过或驳回驳回时填理由走访人员看到驳回原因修改重提统计页再从库里聚合出乡镇数据。前端提交的数据结构建议固定成这样{ name: 张三, idCard: 110101199003071234, povertyType: 返贫监测户, annualIncome: 12345.67, householdSize: 3, address: 某区-某镇-某村, lng: 116.397128, lat: 39.916527, imageUrls: [ http://server/upload/2024/06/abc.jpg ] }这个 JSON 就是前后端约定的接口契约。字段名用驼峰数据库列名用下划线服务层负责映射这是微信小程序前后端联调最常见的约定。图片字段设计成数组而不是逗号拼接字符串是为了后续做轮播图时不用再 split。经纬度单独存字段而不是塞进 address因为按区域统计时经纬度可以做地理围栏字符串地址只能靠文本模糊匹配。2.3 用状态字段建模“收集”的进度而不是只有一张表很多毕设的败笔在于数据库只有一张表没有任何状态字段。数据收集系统天然有生命周期录入一半是草稿提交后等待审核审核通过成为有效数据审核不通过需要返工。如果只用一个布尔字段 is_deleted就无法回答“哪条是有效数据、哪条还没审核完”。状态机建议这样设计draft草稿到 pending待审核再到 approved已通过或 rejected已驳回rejected 可以由走访人员修改后重新提交。每个状态转换记录时间create_time 记录建档时间audit_time 记录审核时间audit_reason 记录驳回理由。一张表就能支撑三个页面走访人员看 draft 和 rejected管理员看 pending统计口径只看 approved。状态字段用 ENUM 而不是 INT好处是数据库层面就限定了取值范围后端忘校验时不会落进脏数据。索引至少要建 status 和 address 两个后面按乡镇统计会用到 address 前缀status 索引保证待审核列表在数据量上来之后不慢。数据收集的常见通病是只考虑写入不考虑审核和统计把状态字段想明白这个题就解掉一半。3. 采集端落地请求封装、动态表单、图片上传与状态机架子定了这章把小程序端的四个关键点写完每一段代码都可以直接复制到 pages 目录下改一下接口地址就能跑通。3.1 封装 request.js把 token、超时和错误码收敛到一处写小程序最忌讳每个页面各自调一遍 wx.request后面要改域名或统一加 token 时几十个页面挨个改纯属给自己挖坑。我一般会把请求封装成一个 Promise 函数页面里只用 async/await 调用。// utils/request.js const BASE_URL http://127.0.0.1:8080/api; // 开发用本机真机改成电脑局域网 IP function request(path, { method GET, data {}, header {} } {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL path, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || , ...header, }, timeout: 10000, success(res) { if (res.statusCode 200 res.statusCode 300) { resolve(res.data); } else if (res.statusCode 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/index }); reject(new Error(登录过期)); } else { reject(new Error(res.data.message || 请求失败 ${res.statusCode})); } }, fail(err) { reject(err); }, }); }); } module.exports { request, BASE_URL };这段封装里有三个关键参数。BASE_URL 开发时用 127.0.0.1 加端口真机调试换成电脑局域网 IPtimeout 设 10 秒图片上传接口单独走 uploadFile 不走这个超时Authorization 从 storage 取后端用它区分管理员和走访人员。状态码 401 统一清 token 跳登录页这是小程序最常见的会话失效场景放在公共层处理比每个页面写一遍靠谱。这里有个容易被忽视的细节wx.request 的 success 回调只代表请求发出不代表业务成功。业务失败分两种HTTP 非 2xx 和返回码非 0上面把非 2xx 统一抛成 Promise reject页面 catch 里统一 toast就不会出现“接口明明报错但页面提示提交成功”的黑色十分钟。3.2 贫困户录入表单picker、多字段校验与草稿暂存录入页是小程序端的核心。字段不要全堆成 text input类型选对能省一半校验。povertyType 用 picker 下拉annualIncome 用 digit 类型输入householdSize 用 number。身份证号做正则校验是基本操作不仅要验位数还要允许末尾 X 并统一转大写。// pages/record/edit.js const { request } require(../../utils/request); Page({ data: { form: { name: , idCard: , povertyType: , annualIncome: , householdSize: 1, address: , remark: , }, povertyTypes: [未脱贫, 已脱贫, 返贫监测户], }, onInput(e) { const field e.currentTarget.dataset.field; this.setData({ [form.${field}]: e.detail.value }); }, validate() { const f this.data.form; if (!f.name.trim()) return 户主姓名不能为空; if (!/^\d{17}[\dXx]$/.test(f.idCard)) return 身份证号格式不正确; if (!f.address.trim()) return 地址必须填写; if (f.annualIncome ! isNaN(Number(f.annualIncome))) return 年收入必须是数字; return ; }, async submit() { const errMsg this.validate(); if (errMsg) { wx.showToast({ title: errMsg, icon: none }); return; } const form { ...this.data.form, idCard: this.data.form.idCard.toUpperCase() }; wx.showLoading({ title: 提交中 }); try { await request(/poverty/create, { method: POST, data: form }); wx.hideLoading(); wx.showToast({ title: 已提交待审核 }); wx.navigateBack(); } catch (e) { wx.hideLoading(); wx.showToast({ title: e.message, icon: none }); } }, });这段代码有三个习惯值得保留。一是 setData 用模板路径form.${field}一个 onInput 管所有文本字段新增字段不需要重复写监听二是校验规则集中在一个函数里返回错误串而不是每个 if 里单独 toast字段多时好维护三是提交前把身份证转大写避免后端查重时大小写不一致误判。放在 dataset 里的 field 名必须和 data.form 的键完全一致拼错一个就静默失效这是小程序很常见的翻车点。3.3 图片上传与定位采集临时路径、name 与调用频率入户采集必然要拍住房照片和收入佐证材料。新版基础库建议用 wx.chooseMedia 替代 wx.chooseImage前者支持一次选多张并返回 tempFiles 数组sourceType 放开 camera 和 album因为现场拍照和补传旧照片两种情况都会遇到。// pages/record/edit.js 片段 const { BASE_URL } require(../../utils/request); chooseAndUpload() { wx.chooseMedia({ count: 4, mediaType: [image], sourceType: [camera, album], success: (res) { const tasks res.tempFiles.map((f) new Promise((resolve, reject) { wx.uploadFile({ url: BASE_URL /upload/image, filePath: f.tempFilePath, name: file, formData: { scene: poverty }, success: (r) { try { const data JSON.parse(r.data); resolve(data.url); } catch (e) { reject(e); } }, fail: reject, }); })); Promise.all(tasks).then((urls) { this.setData({ form.imageUrls: urls }); }).catch(() { wx.showToast({ title: 图片上传失败, icon: none }); }); }, }); }上传时有三个参数容易踩坑。formData 里传 scene 字段后端可以按场景分目录存文件不传也能跑但所有图片混在一个目录里后期清理很麻烦。name 必须是后端接收文件用的字段名后端写 multipart 的 file 就填 file写成 image 会直接 400。Promise.all 并发上传四张图后端连接池太小会超时这在第 5 章专门讲。上传完成后数据库存的是服务器返回的 URL不是 chooseMedia 给的本地临时路径临时路径在小程序重启后就失效了。定位用 wx.getLocationtype 用 gcj02这是国内坐标系。记得在 app.json 的 permission 里声明 scope.userLocation 的用途说明。我的习惯是在表单提交那一刻才取经纬度而不是进页面就取——进页面就取用户停留两小时提交的是两小时前的位置对入户采集场景来说不准确。getLocation 是回调风格用 Promise 包一层再放到 submit 流程里 await能少写一层嵌套。3.4 提交后的状态流转从草稿到驳回重填录入页提交成功后数据状态是 pending但用户编辑到一半退出怎么办我的做法是把本地 storage 当草稿箱form 字段变化时防抖写入 wx.setStorageSync(draft_poverty)提交成功或驳回后清除。这样不需要为草稿单独建表又能在误退出时找回数据答辩时还能讲一句“做了防数据丢失处理”。列表页按状态分区展示走访人员看到的列表分“草稿 / 审核中 / 已驳回”三个区域管理员看到的列表只显示 pending。驳回记录要在详情页带上 audit_reason用醒目的提示条展示走访人员才知道往哪个字段补。所有状态变更只能由后端接口触发这是数据收集系统与普通表单工具的边界前端只能展示和提交裁决权在后端。4. 服务端与数据库从一张贫困户表到可验收的接口小程序端写完接下来是支撑它的服务端。数据库设计是整个毕设最容易被评审翻出来问的部分字段类型、唯一约束、索引都要能讲出为什么。4.1 建库建表用户表、贫困户表、走访记录表与字典表我按最常见的拆法给你四张表sys_user 存用户poverty_info 存贫困户主数据visit_record 存每次走访动态dict_item 存贫困类型等字典。第三张表很多人不知道为什么要建——走访是持续发生的同一户这月了解收入、下月回访看变化不建子表就只能改主表改了历史就没有了。CREATE DATABASE IF NOT EXISTS poverty_db DEFAULT CHARACTER SET utf8mb4; USE poverty_db; CREATE TABLE sys_user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role ENUM(admin,worker) NOT NULL DEFAULT worker, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB; CREATE TABLE poverty_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, customer_name VARCHAR(50) NOT NULL, id_card VARCHAR(18) NOT NULL UNIQUE, poverty_type VARCHAR(20) NOT NULL, annual_income DECIMAL(10,2) DEFAULT 0, household_size INT DEFAULT 1, address VARCHAR(200) NOT NULL, image_urls JSON COMMENT 图片url列表, longitude DECIMAL(10,6), latitude DECIMAL(10,6), status ENUM(draft,pending,approved,rejected) DEFAULT draft, audit_reason VARCHAR(200), created_by INT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, audit_time DATETIME, KEY idx_status (status), KEY idx_address (address) ) ENGINEInnoDB; CREATE TABLE visit_record ( id BIGINT AUTO_INCREMENT PRIMARY KEY, poverty_id BIGINT NOT NULL, visit_time DATETIME NOT NULL, content TEXT, visitor VARCHAR(50), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_poverty (poverty_id) ) ENGINEInnoDB;字段设计上有几个关键点。id_card 的唯一约束是第一道防重身份证重复建档会直接违反唯一索引这比后端 if exists 判断更硬。annual_income 用 DECIMAL(10,2) 不用 FLOAT浮点存钱是新手常犯的错统计时会差几分钱。image_urls 用 JSON 类型存数组MySQL 5.7 以上原生支持比逗号拼接字符串规范得多。经纬度用 DECIMAL(10,6)精度到 0.1 米入户采集完全够用。status 用 ENUM 并建索引前面第 2 章讲过建表时直接落下去别等慢查询了再补。4.2 后端 submit 接口幂等校验加数据库唯一约束双保险接口层要做的事很简单接收 JSON、校验、落库。但真正生产环境要考虑网络重放问题用户双击提交、小程序端 loading 没拦住、网络抖动后重试都可能导致同一条数据被插两次。所以服务端必须做幂等校验。# app.py 核心片段 from flask import Flask, request, jsonify from flask_sqlalchemy import SQLAlchemy app Flask(__name__) app.config[SQLALCHEMY_DATABASE_URI] mysqlpymysql://root:passwordlocalhost/poverty_db?charsetutf8mb4 db SQLAlchemy(app) class PovertyInfo(db.Model): __tablename__ poverty_info id db.Column(db.BigInteger, primary_keyTrue) customer_name db.Column(db.String(50), nullableFalse) id_card db.Column(db.String(18), uniqueTrue, nullableFalse) poverty_type db.Column(db.String(20)) annual_income db.Column(db.Numeric(10, 2)) status db.Column(db.String(20), defaultdraft) audit_reason db.Column(db.String(200)) app.route(/poverty/create, methods[POST]) def create_poverty(): data request.get_json(forceTrue) exists PovertyInfo.query.filter( PovertyInfo.id_card data.get(idCard), PovertyInfo.status.in_([pending, approved]) ).first() if exists: return jsonify({message: 该身份证已存在待审核或已通过数据}), 400 p PovertyInfo( customer_namedata.get(name), id_carddata.get(idCard), poverty_typedata.get(povertyType), annual_incomedata.get(annualIncome), statuspending ) db.session.add(p) db.session.commit() return jsonify({id: p.id, status: p.status})这段逻辑的核心在 exists 查询同一个身份证只要存在 pending 或 approved 状态的数据就拒绝再次提交。即使小程序端加了 loading 防重网络层仍可能重放请求这个校验必须放在服务端。审核接口同理驳回时 audit_reason 字段必须非空否则前端没有内容可展示。前端驼峰字段到数据库下划线字段的映射在 Flask 里直接在查询和赋值时转换就行用 Java 写就在实体类上加映射注解思路完全一样。4.3 统计与汇总按乡镇分组的 SQL 写法与排序取值数据收集的最后一站是统计页。毕设的统计需求通常是“按乡镇看贫困户数、已通过数、平均收入”一条 SQL 就能完成。SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(address, -, 2), -, -1) AS town, COUNT(*) AS total, SUM(status approved) AS approved_count, ROUND(AVG(CASE WHEN status approved AND annual_income 0 THEN annual_income END), 0) AS avg_income FROM poverty_info GROUP BY town ORDER BY total DESC;这里有个前提address 录入规则必须是“区县-乡镇-村”三段用两级 SUBSTRING_INDEX 提取中间那段作为乡镇。如果项目里已经有独立的 town 字段直接 group by town 更好不需要学这个取法。采用这种存储是为了让录入表单保持简单一个文本输入框解决地址统计时再解析。AVG 在遇到全 NULL 时会返回 NULL前端图表库展示会直接报错所以用 CASE 过滤未通过和收入为 0 的数据再包 ROUND 控制小数位。ORDER BY total DESC 让数据最多的乡镇排最前列表页默认也按 create_time DESC数据收集场景里新的永远比旧的重要。5. 接入调试避坑合法域名、图片上传、空值与慢 SQL 的排查顺序这套系统跑起来不难但接入调试阶段有一批问题几乎每个人都会撞上。下面按现象、原因、解决的顺序写这些都是我实际踩过的坑。5.1 小程序 request 的合法域名为什么开发者工具没事真机预览就挂现象开发者工具里编译一切正常一扫码预览所有 request 都报 url not in domain list。原因小程序真机运行时强制校验域名白名单开发者工具默认帮你关掉了校验所以本地开发感觉不到。解决开发调试阶段在微信开发者工具右上角“详情-本地设置”里勾选“不校验合法域名”要发布体验版后端必须上 HTTPS 域名并在小程序后台配置白名单。如果用本地 IP 调试还要注意 iOS 对明文 HTTP 有限制真机连不上时优先排查这个我当时配了三天才意识到是 ATS 拦截。另外用 IP 调试时后端接口要允许跨域否则真机报跨域而开发者工具正常典型的黑匣子问题。5.2 图片上传失败本地临时路径与服务器路径别混用现象一图片选完在页面能显示刷新后裂掉。原因是把 chooseMedia 返回的 tempFilePath 直接存进了数据库临时路径在小程序重启后就不能访问必须存上传接口返回的 URL。现象二上传报 413 payload too large原因是后端限制了请求体大小Flask 要调 MAX_CONTENT_LENGTHNginx 要调 client_max_body_size只改一个还是报错。我一般限单张 5MB、每次最多 4 张既满足佐证材料的清晰度要求又不至于把服务器带宽吃满。上传接口成功回调里记得 JSON.parse(r.data)r.data 是字符串不是对象漏了这行后面取 data.url 全是 undefined。5.3 空值与时区查询结果不对往往是编码和时区问题现象写入时间比本地时间少 8 小时统计平均收入结果为空。原因数据库连接串没有指定时区驱动默认取系统 UTCAVG 遇到全 NULL 返回 NULL 而不是 0。解决Java 的 JDBC 连接串加 serverTimezoneAsia/ShanghaiPython 用 PyMySQL 时通过 init_command 设置会话时区SQL 里用 CASE 加 COALESCE 对收入字段兜底。编码问题也常翻车中文写入乱码十有八九是连接串漏了 charsetutf8mb4或者建表用了 latin1。建库时一条 DEFAULT CHARACTER SET utf8mb4 就够了不要等入库后才发现那个后悔药可不好吃。5.4 连接池太小并发上传四张图接口排队排到超时现象网络正常但上传多张图时偶发超时看后端日志总有 Connection pool exhausted。原因 SQLAlchemy 默认连接池只有 5 个小程序上传 4 张图并发调用 4 个 upload 接口加上登录和 submit 请求连接池被打满。解决显式配置连接池大小并加回收时间。from sqlalchemy import create_engine engine create_engine( mysqlpymysql://root:passwordlocalhost/poverty_db?charsetutf8mb4, pool_size10, max_overflow10, pool_recycle3600, connect_args{init_command: SET time_zone 08:00} )参数说明pool_size 是常驻连接数max_overflow 是峰值可扩连接数加起来 20对毕设规模完全够pool_recycle 防止 MySQL 的 wait_timeout 把连接断开后客户端还在用init_command 顺手把时区问题也解决了。这里还要控制小程序端的并发数wx.uploadFile 用 Promise.all 时最多一次传 4 张不要一次传 20 张把服务端打死。另外数据收集类系统要考虑弱网离线填、信号恢复后批量同步的场景这种批量同步更吃连接池设计接口时预留批量提交入口很有必要。6. 验收与答辩演示视频怎么录数据怎么证明系统能跑毕设标题里带着演示视频意味着交付时除了代码还要有一个能让人看懂的系统演示。我的习惯是分段录制不要一镜到底。第一段展示登录和整体页面结构第二段用真实手机录录入流程填写、拍照、定位、提交第三段切换管理员账号打开待审核列表通过一条、驳回一条并填写理由最后切回走访人员账号看到驳回提示后修改重提再回统计页看数字变化。这三段能覆盖标题里的数据收集、数据库、小程序全部关键词。录制前先把模拟数据造好不同乡镇至少 6 条、不同贫困类型 3 种统计页才有分组效果也不怕现场演示时网络拖后腿。视频拍完不等于系统能跑我建议用一张清单自测。验收维度怎么做通过标准数据完整性走访人员录入 10 条数据列表逐条可见字段无丢失状态流转提交、驳回、重提、通过每个状态变化有时间与理由防重同一身份证二次提交接口返回 400 且提示明确统计正确手工数 3 个乡镇的数据统计页数字与库中 COUNT 一致权限控制worker 调用审核接口返回 403 拒绝访问答辩追问一般集中在四个点为什么身份证做唯一约束为什么状态用 ENUM图片为什么存 JSON 字段数据量变大怎么办。前三问的答案在这篇文章第 4 章里都有第四问答“建索引、按乡镇分区查询、列表加翻页”然后坦诚说当前规模下这套设计够用比硬吹分布式更让评审舒服。一个血泪教训是演示录像里别把数据库表结构全展开用 ER 图说明关系评审更喜欢抽象后的模型但真被问到字段时又能背出来这才是控场。希望这几点能帮你把微信小程序毕业设计从能跑做到能讲把数据收集从一张表做成一条完整链路后面再做类似的走访、巡检类小程序这套状态机和接口设计可以原样搬希望能帮到你。本文还有配套的精品资源点击获取
