企业官网建设流程全解析

简介：本资源为微信小程序方向的精准扶贫数据收集系统毕业设计全套资料，面向计算机相关专业需要完成课程设计或毕业设计的学生，以及希望学习小程序与Java后端联调的开发者。项目采用微信小程序开发工具、MySQL与Java，基于B/S架构实现，前端涵盖帮扶对象信息查看与管理、扶贫收入查询、帮扶措施制定、扶贫统计等模块，后台支持贫困人员信息、帮扶责任人及文章内容的管理，功能贴近真实扶贫业务场景。压缩包共342个文件，约92.82MB，包含36个java源文件、36个class、30个xml、29个js、15个wxml与wxss页面文件，以及jar依赖、png与jpg界面截图、sql数据库脚本和说明文档，覆盖从源码到部署的完整链路。目前已有325人学习下载，适合作为赛题方案参考、功能拆解与排错思路借鉴，帮助读者快速理解小程序与后台管理系统的整体结构。

1. 精准扶贫数据收集小程序：从“填表两小时”到“入户十分钟”的落地拆解

做过基层数据采集的人都有一个共同感受：纸质表填完要录入、录入完要核对、核对完要汇总，一圈下来三天没了。精准扶贫数据收集这类微信小程序毕业设计，核心要解决的就是这个链路——把“入户采集→实时上报→后台汇总→可视化看板”压进一个手机端应用里。它适合两类人：一是正在做毕设、需要一套能跑通全流程的参考实现；二是刚接触小程序开发、想找一个业务闭环完整的练手项目。这篇笔记不讲空话，直接拆技术选型、数据库设计、核心接口和部署踩坑，让你拿到源码后能跑起来、改得动、讲得清。

2. 技术选型与数据库设计：为什么这套组合最适合毕设落地

2.1 前端为什么选微信小程序原生而不是 uni-app

毕设项目最怕的是“环境跑不起来”。uni-app 虽然能一套代码多端发布，但它依赖 HBuilderX 或 CLI 构建链，对不熟悉前端工程化的同学来说，光是配 node 版本和依赖就能卡两天。微信小程序原生开发用微信开发者工具打开就能跑，调试器、真机预览、云开发控制台都在一个 IDE 里，对毕设场景来说，省下来的环境调试时间可以全部投到业务逻辑上。

具体到精准扶贫数据收集这个场景，原生小程序的几个能力刚好够用：wx.chooseLocation拿入户定位，wx.chooseMedia拍房屋和证件照片，wx.request提交表单数据，wx.login+code2Session做微信身份绑定。这些 API 在原生框架下调用最直接，不需要额外封装层。

页面结构上，建议按角色拆成三个 tab：采集员端（表单填写、历史记录、草稿箱）、管理员端（数据审核、统计看板、导出）、公共端（登录、个人信息）。采集员端是核心，表单字段多，必须做分步填写和本地缓存，否则网络一断，填了半小时的数据全丢——这是血泪经验。

2.2 后端选 Node.js + Express 还是云开发

这是毕设选题里最纠结的一个点。云开发的好处是免服务器、免备案、数据库和存储直接调 API，部署成本几乎为零。但它的坑在于：数据库查询能力弱，复杂聚合统计要写云函数，调试起来不如本地直观；而且导出 Excel 这类操作在云函数里受运行时长限制。

我一般会推荐 Node.js + Express + MySQL 的组合，原因有三：第一，MySQL 的关系型结构天然适合“贫困户—帮扶记录—审核状态”这种多表关联；第二，本地开发时可以用 Navicat 直接看数据，调试效率高；第三，毕设答辩时，能讲清楚 RESTful 接口设计和 SQL 查询优化，比“我用了云开发”更有技术含量。

部署上，一台最低配的云服务器加宝塔面板就能跑起来。Node 进程用 pm2 守护，MySQL 设好定时备份，前端小程序走微信开发者工具上传审核。整套下来，一个下午能部署完。

2.3 数据库表结构：五张核心表撑起整个业务

精准扶贫数据收集的业务逻辑不复杂，但表设计要经得起推敲。下面是我在实际项目中反复调整后定下来的五张核心表，字段经过脱敏处理，你可以直接照着建。

-- 用户表：区分采集员和管理员 CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `openid` varchar(64) NOT NULL COMMENT '微信openid', `real_name` varchar(32) DEFAULT NULL COMMENT '真实姓名', `role` tinyint NOT NULL DEFAULT '1' COMMENT '1采集员 2管理员', `phone` varchar(20) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `idx_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 贫困户基础信息表 CREATE TABLE `household` ( `id` int NOT NULL AUTO_INCREMENT, `household_code` varchar(32) NOT NULL COMMENT '贫困户编号', `head_name` varchar(32) NOT NULL COMMENT '户主姓名', `id_card` varchar(18) NOT NULL COMMENT '身份证号', `address` varchar(255) NOT NULL COMMENT '家庭住址', `family_size` int DEFAULT '1' COMMENT '家庭人口数', `poverty_reason` varchar(255) DEFAULT NULL COMMENT '致贫原因', `longitude` decimal(10,6) DEFAULT NULL COMMENT '定位经度', `latitude` decimal(10,6) DEFAULT NULL COMMENT '定位纬度', `collector_id` int NOT NULL COMMENT '采集员ID', `status` tinyint DEFAULT '0' COMMENT '0待审核 1已通过 2已驳回', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `idx_household_code` (`household_code`), KEY `idx_collector` (`collector_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 帮扶记录表 CREATE TABLE `assist_record` ( `id` int NOT NULL AUTO_INCREMENT, `household_id` int NOT NULL, `assist_type` varchar(64) DEFAULT NULL COMMENT '帮扶类型', `assist_content` text COMMENT '帮扶内容', `assist_amount` decimal(10,2) DEFAULT '0.00' COMMENT '帮扶金额', `assist_date` date DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_household` (`household_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 附件表：存照片和视频的URL CREATE TABLE `attachment` ( `id` int NOT NULL AUTO_INCREMENT, `household_id` int NOT NULL, `file_type` tinyint DEFAULT '1' COMMENT '1图片 2视频', `file_url` varchar(512) NOT NULL, `upload_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_household_att` (`household_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 操作日志表：审核留痕 CREATE TABLE `audit_log` ( `id` int NOT NULL AUTO_INCREMENT, `household_id` int NOT NULL, `operator_id` int NOT NULL, `action` varchar(32) NOT NULL COMMENT 'pass/reject', `remark` varchar(255) DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这五张表的关联逻辑是：user表通过collector_id关联household，household通过household_id关联assist_record和attachment，audit_log记录每次审核动作。查询某个采集员名下所有贫困户时，走idx_collector索引；查询某户的所有帮扶记录时，走idx_household索引。字段类型上，经纬度用decimal(10,6)而不是float，避免定位精度丢失；身份证号用varchar(18)而不是char，兼容末位 X 的情况。

注意：household_code建议用“行政区划码+日期+序号”的规则生成，比如52010120240101001，这样在导出和归档时能直接按编号排序，比自增 ID 可读性强得多。

3. 核心功能实现：表单采集、定位拍照与后台审核的代码拆解

3.1 采集端表单：分步填写 + 本地缓存防丢数据

采集员在入户时最怕两件事：一是网络差提交失败，二是填到一半接电话切出去回来数据没了。解决办法是把表单拆成三步，每步的数据实时写入wx.setStorageSync，提交时再从缓存里读出来合并。

// pages/collect/step1.js Page({ data: { formData: { headName: '', idCard: '', address: '', familySize: 1, povertyReason: '' } }, onLoad() { // 页面加载时先读缓存，有草稿就回填 const draft = wx.getStorageSync('household_draft'); if (draft) { this.setData({ formData: draft }); } }, // 每个输入框的通用绑定方法 onInput(e) { const field = e.currentTarget.dataset.field; const value = e.detail.value; this.setData({ [`formData.${field}`]: value }); // 每次输入都写缓存，防止意外退出丢数据 wx.setStorageSync('household_draft', this.data.formData); }, // 身份证号格式校验 validateIdCard(idCard) { const reg = /(^\d{15}$)|(^\d{18}$)|(^\d{17}(\d|X|x)$)/; return reg.test(idCard); }, nextStep() { const { headName, idCard, address } = this.data.formData; if (!headName || !idCard || !address) { wx.showToast({ title: '请填写完整', icon: 'none' }); return; } if (!this.validateIdCard(idCard)) { wx.showToast({ title: '身份证格式有误', icon: 'none' }); return; } wx.navigateTo({ url: '/pages/collect/step2' }); } });

这段代码的关键点有三个：第一，onLoad里读缓存实现草稿恢复，采集员切出去再回来数据还在；第二，onInput里用dataset.field做通用绑定，避免每个字段写一个方法；第三，身份证校验放在前端做第一道拦截，减少无效请求打到后端。参数上，wx.setStorageSync的存储上限是 10MB，单条草稿数据远不会超，但要注意在提交成功后调用wx.removeStorageSync('household_draft')清掉缓存，否则下次新建时会带入旧数据。

3.2 定位与拍照：wx.chooseLocation 和 wx.chooseMedia 的配合

入户采集必须记录地理位置和房屋照片，这是审核时判断“是否真实入户”的核心依据。定位用wx.chooseLocation，拍照用wx.chooseMedia，两者都需要在app.json里声明权限。

// pages/collect/step2.js Page({ data: { location: null, photos: [], video: '' }, // 获取定位 getLocation() { wx.chooseLocation({ success: (res) => { this.setData({ location: { longitude: res.longitude, latitude: res.latitude, address: res.address } }); wx.setStorageSync('household_location', this.data.location); }, fail: (err) => { // 用户拒绝授权时引导去设置页开启 if (err.errMsg.includes('auth deny')) { wx.showModal({ title: '需要定位权限', content: '请在设置中开启位置权限后重试', success: (modalRes) => { if (modalRes.confirm) { wx.openSetting(); } } }); } } }); }, // 拍照或从相册选图，最多9张 choosePhotos() { wx.chooseMedia({ count: 9 - this.data.photos.length, mediaType: ['image'], sourceType: ['camera', 'album'], sizeType: ['compressed'], success: (res) => { const newPhotos = res.tempFiles.map(f => f.tempFilePath); this.setData({ photos: [...this.data.photos, ...newPhotos] }); } }); }, // 上传照片到后端 async uploadPhotos(householdId) { const uploadTasks = this.data.photos.map((filePath, index) => { return new Promise((resolve, reject) => { wx.uploadFile({ url: 'https://your-domain.com/api/upload', filePath: filePath, name: 'file', formData: { householdId: householdId, fileType: 1, sort: index }, success: (res) => { const data = JSON.parse(res.data); if (data.code === 0) { resolve(data.data.url); } else { reject(new Error(data.msg)); } }, fail: reject }); }); }); return Promise.all(uploadTasks); } });

wx.chooseLocation返回的res里包含longitude、latitude、address三个关键字段，直接存入household表的对应列。wx.chooseMedia的sizeType: ['compressed']很重要，原图一张可能 5MB 以上，压缩后通常 200KB 左右，上传速度和存储成本都大幅下降。上传时用Promise.all并发处理多张照片，但要注意后端接口的并发限制，如果服务器配置低，建议改成串行上传，每张间隔 200ms。

提示：wx.uploadFile的header里要带上登录态 token，否则后端无法识别是哪个采集员在上传。token 存在wx.getStorageSync('token')里，每次请求前取出来塞进 header。

3.3 后端接口：Express 路由与 MySQL 查询的配合

后端用 Express 起服务，路由按业务模块拆分。核心接口有三个：提交贫困户数据、查询采集员名下记录、管理员审核。下面以提交和审核为例。

// routes/household.js const express = require('express'); const router = express.Router(); const db = require('../db'); // mysql2 连接池 const auth = require('../middleware/auth'); // 提交贫困户数据 router.post('/submit', auth, async (req, res) => { const { householdCode, headName, idCard, address, familySize, povertyReason, longitude, latitude } = req.body; const collectorId = req.userId; // 从 token 解析出的用户ID try { // 先检查编号是否重复 const [existing] = await db.query( 'SELECT id FROM household WHERE household_code = ?', [householdCode] ); if (existing.length > 0) { return res.json({ code: 1, msg: '贫困户编号已存在' }); } const [result] = await db.query( `INSERT INTO household (household_code, head_name, id_card, address, family_size, poverty_reason, longitude, latitude, collector_id, status) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, 0)`, [householdCode, headName, idCard, address, familySize, povertyReason, longitude, latitude, collectorId] ); res.json({ code: 0, msg: '提交成功', data: { id: result.insertId } }); } catch (err) { console.error('提交失败:', err); res.json({ code: 500, msg: '服务器内部错误' }); } }); // 管理员审核 router.post('/audit', auth, async (req, res) => { const { householdId, action, remark } = req.body; const operatorId = req.userId; // 权限校验：只有管理员能审核 if (req.userRole !== 2) { return res.json({ code: 403, msg: '无审核权限' }); } const status = action === 'pass' ? 1 : 2; const conn = await db.getConnection(); try { await conn.beginTransaction(); await conn.query( 'UPDATE household SET status = ? WHERE id = ?', [status, householdId] ); await conn.query( `INSERT INTO audit_log (household_id, operator_id, action, remark) VALUES (?, ?, ?, ?)`, [householdId, operatorId, action, remark || ''] ); await conn.commit(); res.json({ code: 0, msg: '审核完成' }); } catch (err) { await conn.rollback(); console.error('审核失败:', err); res.json({ code: 500, msg: '审核失败，请重试' }); } finally { conn.release(); } }); module.exports = router;

提交接口里先查重再插入，避免同一户被重复采集。审核接口用事务包住“更新状态”和“写日志”两个操作，保证要么都成功要么都回滚。auth中间件负责解析 token 并把userId和userRole挂到req上，这样每个接口都能拿到当前用户身份。数据库连接用mysql2的连接池，db.query是 Promise 封装后的方法，比回调写法清爽很多。

参数说明：householdCode由前端生成，格式建议“区划码+日期+三位序号”；status字段 0 表示待审核，1 表示通过，2 表示驳回；audit_log里的action存pass或reject，方便后续统计审核通过率。

4. 避坑与排查：部署和联调阶段最容易翻车的五个点

4.1 小程序请求域名未配置导致真机预览全部失败

现象：开发者工具里接口调得通，真机预览时所有请求都报request:fail url not in domain list。

原因：微信小程序对wx.request的域名有白名单限制，开发者工具可以勾选“不校验合法域名”绕过，但真机不行。

解决：登录微信公众平台，在“开发管理→开发设置→服务器域名”里把后端接口域名加进request合法域名，把上传接口域名加进uploadFile合法域名。域名必须是 HTTPS，且已备案。本地调试阶段可以用内网穿透工具临时映射一个 HTTPS 地址，但正式提交审核前必须换成备案域名。

4.2 MySQL 中文乱码：数据库、表、连接三层都要设 utf8mb4

现象：采集员提交的中文姓名存进数据库变成问号，或者查询时返回乱码。

原因：MySQL 的字符集设置涉及服务器层、数据库层、表层和连接层，任何一层不是utf8mb4都可能出问题。

解决：建库时指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci；建表时同样指定；Node 连接池配置里加charset: 'utf8mb4'。三处都设好之后，中文和 emoji 都能正常存取。如果已经建了表，用ALTER TABLE household CONVERT TO CHARACTER SET utf8mb4改过来。

4.3 图片上传后无法访问：存储路径和静态服务没对上

现象：照片上传成功，数据库里也存了 URL，但小程序里image组件加载不出来。

原因：后端把文件存到了服务器某个目录，但没有配置静态文件服务，或者 URL 拼错了。

解决：Express 里用app.use('/uploads', express.static(path.join(__dirname, 'uploads')))把上传目录暴露成静态资源。上传接口返回的 URL 要是完整路径，比如https://your-domain.com/uploads/2024/01/abc.jpg。另外注意服务器防火墙要放行 443 端口，Nginx 反代时要把/uploads路径也代理到 Node 服务。

4.4 表单重复提交：网络慢时用户连点提交按钮

现象：同一户数据在数据库里出现两条，household_code相同但id不同。

原因：提交按钮没有做防抖或禁用，网络延迟时用户以为没提交成功就连点了。

解决：前端在提交时把按钮置灰，用loading状态锁住，请求返回后再恢复。后端在household_code上建唯一索引，即使前端漏了，数据库层也会拦截重复插入，返回错误码让前端提示“该编号已存在”。

4.5 审核状态不同步：管理员审核后采集员端看不到更新

现象：管理员在后台点了通过，采集员在小程序“我的记录”里看到的还是“待审核”。

原因：采集员端的数据是页面加载时查一次，之后没有刷新机制。

解决：在采集员端的记录列表页加onShow生命周期里重新拉取数据，这样从其他页面切回来时会自动刷新。如果要求实时性更高，可以用 WebSocket 推送，但毕设场景下onShow刷新足够用，实现成本也低。

5. 数据导出与可视化看板：让毕设答辩多一个加分项

5.1 用 ExcelJS 导出审核通过的数据

管理员端需要一个“导出 Excel”的功能，把审核通过的贫困户数据导成表格。Node 端用exceljs库实现，比xlsx更灵活，支持样式和列宽设置。

// routes/export.js const ExcelJS = require('exceljs'); const db = require('../db'); const auth = require('../middleware/auth'); router.get('/export', auth, async (req, res) => { if (req.userRole !== 2) { return res.json({ code: 403, msg: '无导出权限' }); } const [rows] = await db.query( `SELECT h.household_code, h.head_name, h.id_card, h.address, h.family_size, h.poverty_reason, u.real_name AS collector_name, h.create_time FROM household h LEFT JOIN user u ON h.collector_id = u.id WHERE h.status = 1 ORDER BY h.create_time DESC` ); const workbook = new ExcelJS.Workbook(); const sheet = workbook.addWorksheet('贫困户数据'); sheet.columns = [ { header: '贫困户编号', key: 'household_code', width: 22 }, { header: '户主姓名', key: 'head_name', width: 12 }, { header: '身份证号', key: 'id_card', width: 22 }, { header: '家庭住址', key: 'address', width: 40 }, { header: '家庭人口', key: 'family_size', width: 10 }, { header: '致贫原因', key: 'poverty_reason', width: 20 }, { header: '采集员', key: 'collector_name', width: 12 }, { header: '采集时间', key: 'create_time', width: 20 } ]; rows.forEach(row => sheet.addRow(row)); // 设置表头加粗 sheet.getRow(1).font = { bold: true }; res.setHeader( 'Content-Type', 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' ); res.setHeader( 'Content-Disposition', 'attachment; filename=household_export.xlsx' ); await workbook.xlsx.write(res); res.end(); });

这段代码的关键是sheet.columns定义列头和列宽，rows.forEach批量写入数据，最后通过res.setHeader设置响应头让浏览器触发下载。LEFT JOIN user是为了把采集员姓名带出来，比只显示 ID 可读性强。导出条件限定status = 1，只导审核通过的数据，避免未审核数据混入正式报表。

5.2 用 ECharts 在小程序端做统计看板

管理员端首页放一个统计看板，展示“已采集户数、已审核户数、各致贫原因占比”。小程序端用echarts-for-weixin组件，后端提供一个聚合查询接口。

// routes/stats.js router.get('/overview', auth, async (req, res) => { const [[total]] = await db.query( 'SELECT COUNT(*) AS cnt FROM household' ); const [[passed]] = await db.query( 'SELECT COUNT(*) AS cnt FROM household WHERE status = 1' ); const [reasonStats] = await db.query( `SELECT poverty_reason, COUNT(*) AS cnt FROM household WHERE status = 1 GROUP BY poverty_reason ORDER BY cnt DESC` ); res.json({ code: 0, data: { total: total.cnt, passed: passed.cnt, reasons: reasonStats } }); });

前端拿到reasons数组后，传给 ECharts 的饼图配置项，name用poverty_reason，value用cnt。这样答辩时展示的是一个动态更新的看板，比静态截图有说服力。注意GROUP BY查询在数据量大时会慢，如果超过一万条记录，建议加一个定时任务把统计结果缓存到 Redis 或单独的统计表里，接口直接读缓存。

5.3 答辩演示前必须检查的三件事

第一，数据库里要有至少 20 条测试数据，覆盖“待审核、已通过、已驳回”三种状态，否则看板和列表页都是空的，演示效果大打折扣。第二，演示视频里要包含“采集员提交→管理员审核→导出 Excel”的完整链路，不要只录一个页面。第三，提前在答辩用的电脑上装好微信开发者工具和数据库客户端，现场连自己的热点，避免依赖会场网络。

我自己带过的几届毕设里，翻车最多的不是代码写不出来，而是演示当天环境跑不起来。有个同学把数据库密码改了忘了同步到配置文件，现场调了二十分钟。所以答辩前一天，把整个流程从头到尾走一遍，比多写两个功能有用得多。希望帮到你。

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