企业官网建设流程全解析

每年到毕业季，总有学弟学妹拿着同一个问题来找我：“想做一个微信小程序的毕业设计，居家养老方向，有没有完整能跑的源码？最好连论文一起搞定。”说实话，居家养老这个选题在我带过的毕设里属于出镜率相当高的一类，原因很简单：它既有业务复杂度可以写论文，又能在小程序端做出看得见摸得着的界面效果，加上微信生态本身自带传播属性，答辩演示时不会冷场。

但大多数同学卡住的点并不是“不会写代码”，而是不知道一个毕业设计级别的居家养老小程序到底该做哪些功能、后端接口怎么设计、数据库建几张表、代码写到什么程度才算“能答辩”。这篇文章我就拿自己实际搭建过的“基于微信的居家养老小程序”项目来完整拆一遍，从需求分析到技术选型、从数据表设计到关键代码实现、从联调坑点到答辩话术，尽量把能够直接参考复现的部分都给到。适合正在做计算机毕业设计选题的同学，也适合想快速搭一个微信小程序原型产品的人参考。项目本身是“源码+LW文档”的交付模式，我下面讲的都会对应到论文和代码的编写思路，方便你直接往自己的文档里套。

1. 项目整体设计与需求拆解

1.1 居家养老场景到底要解决什么问题

老年人养老目前主要有机构养老、社区养老和居家养老三种形态。居家养老指的是老人在自己家里居住，由社区或第三方服务机构提供上门助餐、助洁、助医、康复护理、紧急救援等服务。之所以成为毕设热门方向，是因为它的业务链条足够完整：有老人端、子女端、服务人员端、管理后台，天然适合做多角色小程序系统。

做毕业设计前先要搞清楚一个核心问题：你做的系统是“给谁用”的。很多同学一上来就想把功能做多，结果老人端做了个商城、子女端做了个社交、管理员端做了个报表，最后自己都解释不清业务闭环。居家养老小程序的核心闭环只有一条：老人在家发起服务请求，平台派单给服务人员，服务人员上门完成后核销订单，子女和家属可以远程查看服务记录和老人状态。所有功能都应该围绕这条主线展开，其他都是锦上添花。

1.2 用户角色怎么拆、功能边界在哪里

我通常建议把角色拆成四类，对应小程序端和管理后台两个子系统：

• 老人用户端：这是最核心的C端，要照顾到老年人手机操作能力偏弱的现实。功能上不要做复杂交互，做成大图标、大字体、少层级。核心功能是服务下单、服务进度查看、紧急求助一键呼叫、健康数据查看（子女帮填或设备同步）。
• 子女/家属端：许多老人其实不会用小程序，实际的操作者是子女。所以这个小程序还要具备“代老人下单”的入口。子女绑定老人账号后，可以看到老人的服务记录、健康数据、是否完成每日打卡等。
• 服务人员端：通常用同一个微信小程序通过角色切换实现，或另开一个独立小程序。服务人员需要接单、查看服务详情、上门签到、服务完成确认。
• PC管理后台：一般用Vue或原生HTML搭，用于服务项目管理、订单管理、人员管理、投诉处理、数据统计。毕设阶段不用做太复杂，能支撑核心业务流程即可。

这里有一个很容易掉进去的坑：老人端和服务人员端都做成同一套小程序会让你后面被答辩老师追问“角色权限怎么控制的”，所以建议在小程序入口做一个“身份选择”界面，老人/家属端选择“我是老人/家属”，服务人员选择“我是服务人员”，后续所有请求根据角色标识返回不同页面和数据。这样权限模型清晰，代码也好写。

1.3 功能清单与优先级排序

毕业设计的工期通常只有两到三个月，功能一定得排优先级。我建议把功能分成P0/P1/P2三档：

P0的功能必须在中期检查前全部实现，P1保证核心闭环，P2留有余量。我见过太多同学把时间花在做商城页面上，最后发现主流程都没走通，这是最可惜的事。

2. 技术选型与架构设计

2.1 小程序前端：原生还是uni-app

这是做微信小程序毕设遇到的第一个选择。给个明确结论：如果不是你已经有充分的Vue经验，老老实实用微信小程序原生开发。原生小程序语法就是WXML+WXSS+JS+JSON，微信开发者工具里写什么是什么，出问题网上随便一搜就有答案。用uni-app的好处是一套代码多端复用，但代价是你要额外理解Vue的响应式机制、uni-app的编译差异、各平台API兼容，这会把很多不必要的心智负担带进毕设项目。

反过来讲，如果你已经熟练Vue，uni-app确实能让代码组织更舒服，而且很多毕业设计题目要求“跨平台”，那么uni-app更合适。我当时帮学生做的时候选的是原生，因为答辩老师翻代码时能直接看到wx.request、Page({})这些熟悉的微信API，提问难度会低一些。

2.2 后端与数据库选型

后端选择上，Java Spring Boot + MySQL是计算机专业毕设的主流配置，也是最保险的组合。Spring Boot生态成熟，网上关于登录鉴权、MyBatis-Plus操作、Swagger接口文档的教程非常多，踩坑好查。如果你对Java不太熟，也可以用Node.js的Express/Koa或Python的Flask/Django来写，但是论文里的“技术选型”部分要想好怎么去比较和解释。

数据库我一般建议MySQL。原因很朴实：所有毕设相关的教学资料、开源项目、答辩PPT模板默认都是MySQL，数据导入导出方便，面试聊起来也通用。数据库管理工具推荐Navicat或DBeaver，可视化操作建表导数据都省心。至于要不要引入Redis，我的建议是：别加。毕业设计阶段引入Redis做缓存只会增加部署和答辩复杂度，除非你想在论文里多写一个技术难点，否则一个单机MySQL足够应付所有场景。

2.3 前后端交互与接口设计思路

小程序端通过HTTPS请求调用后端接口，后端返回统一JSON结构。这里要提前约定好返回格式，我一般使用：

{ "code": 200, "message": "操作成功", "data": { } }

code用200表示成功、500表示业务异常、401表示未登录，小程序前端统一判断code后做提示。这个结构虽然简单，但胜在统一，前端封装的请求方法里只要写一次拦截逻辑，后面所有接口都能自动处理错误提示。

接口路径设计上按资源划分，比如：

• POST /api/user/login：微信登录
• GET /api/service/list：服务列表
• POST /api/order/create：下单
• GET /api/order/myOrders：我的订单
• GET /api/health/list：健康记录

前后端分离的项目，接口文档可以用Swagger自动生成，也可以自己维护一个Markdown表格；毕设答辩时不需要把Swagger UI做得天花乱坠，接口清晰即可。

3. 核心功能与数据模型设计

3.1 老人端核心业务流程拆解

整个系统最核心的流程是“下单—派单—服务—完成”的闭环。以陪诊服务为例：家属在小程序里选择“陪诊服务”，填写老人的姓名、地址、预约时间、病情备注，提交后生成待支付订单；管理后台或服务人员端看到新订单后确认接单；到了预约时间服务人员上门，在小程序里点击“开始服务”；服务完成后点击“完成”，订单状态变为待评价；家属评价后订单关闭。养老服务存在多种计费方式，有的按小时计费，所以服务项目表要设计“计费类型”字段，支持按时计费和按次计费。

老人在家常用的另一个高频功能是紧急求助。这个功能不复杂，但设计上要考虑低门槛操作：首页最显眼的位置放一个SOS按钮，点击后弹窗确认，确认后调起微信订阅消息向老人的紧急联系人发送通知。订阅消息的触发条件是一次订阅一次推送，所以在老人或者家属绑定紧急联系人时就要引导用户多次授权订阅，否则后面推送配额不够用。

3.2 数据库表设计（可直接抄）

数据库表不建议超过12张，合理的设计是9到12张，既能体现业务完整性，又不会把自己卷死。下面是我实际用过的一个表结构，字段做了精简：

订单号建议用年月日时分秒+随机数生成，例如20250607153012001，避免踩到订单号重复的问题。状态字段用字符串而不是数字，状态码可读性更强，直接存WAIT_PAY、WAIT_SERVICE、SERVING、FINISHED、CANCELLED，写业务逻辑的时候一眼就能看明白。

3.3 关键接口实现思路

拿“微信登录”这个接口举例。小程序端调用wx.login()拿到临时 code，传给后端，后端用 code 去微信接口服务换取 openid 和 session_key，然后查数据库：

public class UserController { @PostMapping("/login") public Result login(@RequestBody LoginRequest req) { // 1. 用 code 调用微信接口 String url = "https://api.weixin.qq.com/sns/jscode2session"; // 2. 获取 openid String openid = getOpenid(req.getCode()); // 3. 查询用户是否存在 User user = userMapper.selectByOpenid(openid); // 4. 不存在则自动注册 if (user == null) { user = new User(); user.setOpenid(openid); user.setRole(req.getRole()); userMapper.insert(user); } // 5. 生成token返回前端 String token = JwtUtil.createToken(user.getId()); return Result.success(token); } }

这里要特别注意：实际项目中换 openid 需要 appid 和 secret，毕设调试时这两个值要从微信公众平台获取。如果没有注册小程序账号，也可以用测试号来开发，但测试号的 appid 和正式号不一样，后面上线要重新配置。

“下单接口”要注意事务控制：创建订单、扣减库存（如果有数量概念）、记录日志这几个动作必须在一个事务里，避免出现订单创建成功但日志没写入的脏数据。Spring Boot 里直接在 Service 方法上加@Transactional即可。

健康记录模块相对简单，就是一个针对老人维度的增删改查。要注意的是数值单位统一，比如血糖用mmol/L、血压用mmHg，前端展示的时候不要混用。

4. 从零到一的实操实现全流程

4.1 开发环境准备

工欲善其事，必先利其器。做微信小程序之前把下面的环境装好：

• 微信开发者工具：直接从官网下载稳定版，不要用开发版，开发版经常有小毛病。
• JDK 1.8+（或Java 8/11）和 Maven：如果做Spring Boot后端，这两个是标配。
• MySQL 5.7+ 和 Navicat：本地建库建表用。
• Postman/Apifox：接口自测用，Apifox可以同步接口文档，写论文时还能截接口团队视图。
• 一个微信小程序AppID：有学生认证的可以免费注册个人小程序；个人小程序部分接口权限受限（比如订阅消息可用但部分类目受限），不过毕设演示场景问题不大。

微信开发者工具第一天就要打开，不要等到后端写完再调。很多同学习惯先写后端，再建库，最后才打开小程序编辑器，结果第一周就被各种语法和目录问题搞懵。正确顺序是：第一天就新建一个小程序项目，里面写一个空页面，配好后端接口地址，先打通一个最基础的“请求后端返回字符串”的链路，之后再逐渐填业务。

4.2 小程序端关键页面实现示例

首页是老人端最重要的页面，布局遵循“高频操作靠前”的原则：顶部显示老人头像和问候语，中间放“紧急求助”大按钮，下面排服务分类，再往下是推荐服务卡片。

pages/ ├── index/index // 首页 ├── service/list // 服务列表 ├── service/detail // 服务详情 ├── order/confirm // 确认下单 ├── order/list // 我的订单 ├── order/detail // 订单详情 ├── health/list // 健康记录 ├── health/edit // 添加记录 ├── user/index // 个人中心 ├── worker/task // 服务人员端任务列表 ├── worker/taskDetail // 服务人员端任务详情 └── login/index // 登录/角色选择

以“服务列表页”为例，调接口拿数据后在onLoad中请求，使用wx.request时要注意小程序要求域名必须是HTTPS，本地开发可以在开发者工具里勾选“不校验合法域名”，否则真机预览时请求会直接失败。代码大致是这样：

getServiceList() { wx.request({ url: 'http://localhost:8080/api/service/list', method: 'GET', success: (res) => { if (res.data.code === 200) { this.setData({ serviceList: res.data.data }); } } }); }

页面渲染用wx:for循环列表项，serviceItem卡片里包含服务名称、价格、单位、简介，点击跳转详情页。要注意的是：小程序里wx:for一定要加wx:key，否则列表更新时容易出现渲染错乱，甚至在小程序基础库版本过低时直接在控制台报警告。

订单确认页需要传参，我的做法是通过wx.navigateTo的 URL 带 id：

wx.navigateTo({ url: '/pages/order/confirm?serviceId=' + serviceId });

在订单确认页的onLoad里用options.serviceId接收。参数多的时候建议用encodeURIComponent转一下再拼到URL里，否则遇到特殊字符会截断。

服务人员端页面设计从简：任务列表里展示“待接单”“待服务”“已完成”三个tab，接单按钮点击后调用POST /api/order/accept更新订单状态。为避免接口没返回时用户重复点击，按钮点击后要立即禁用，再在成功回调中跳转或刷新。

4.3 后端Spring Boot工程结构参考

后端工程目录建议按功能模块分包，避免答辩老师翻代码时看到一堆乱糟糟的类。推荐结构：

src/main/java/com/example/homecare/ ├── controller/ // 控制层 │ ├── UserController.java │ ├── ServiceController.java │ ├── OrderController.java │ └── HealthController.java ├── service/ // 业务层 │ ├── OrderService.java │ ├── HealthService.java ├── mapper/ // 数据访问层 │ ├── UserMapper.java │ ├── OrderMapper.java └── config/ // 配置类 ├── WebConfig.java └── JwtInterceptor.java

实体类用MyBatis-Plus的注解做映射，例如：

@Data @TableName("service_item") public class ServiceItem { @TableId(type = IdType.AUTO) private Integer id; private Integer categoryId; private String name; private BigDecimal price; private String unit; private String description; private String image; private Integer status; }

Mapper接口继承BaseMapper<T>之后，常见的增删改查就不用手写SQL了，项目代码量会少很多，写论文里的“系统实现”章节时也能留出篇幅描述MyBatis-Plus的使用。

小程序端的请求需要携带登录token，所以在拦截器里统一校验Header里的token字段，没带token或token过期就返回401，前端收到401后跳回登录页。这个逻辑务必实现，因为答辩老师十有八九会问“你怎么控制用户登录状态”。

4.4 小程序端真机预览与发布流程

写完代码在开发者工具里模拟器运行没问题之后，一定要点“预览”生成二维码用手机真机跑一遍。模拟器里经常不露出真实的问题，比如：

• 真机上字体太小、按钮点不到
• 手机网络慢导致请求超时
• 真机上wx.getLocation需要用户手动授权
• 开发版小程序过夜会失效，需要重新扫码预览

真机调试时如果接口请求失败，先确认是不是“开发环境域名校验”的问题。开发阶段可以在小程序后台把本地开发者工具的“不校验合法域名”打开，但提交体验版之前要把后端部署到有HTTPS证书的服务器，并在小程序后台配置request合法域名。毕设答辩前至少留出三天做部署和真机回归，不要等到答辩前一晚才临时部署。

5. 常见问题排查与答辩避坑技巧

5.1 开发中最容易卡住的十个问题

我整理了带学生做这类毕设项目时最高频的十个卡点，每个都是实际踩过的：

5.2 答辩老师常问的问题怎么回答

答辩环节最考验的不是代码能力，而是对系统的整体把握。根据经验，老师高频会问以下几个问题：

“你的系统角色权限是怎么控制的？”回答思路：前端通过登录接口传入角色标识（user表role字段），后端使用JWT拦截器解析token中的userId，再查询用户角色；接口层面用拦截器或注解校验角色，比如带@RequireRole("WORKER")注解的管理员接口只能服务人员访问。到这里如果老师听得起劲，还可以加一句：小程序端角色切换时重新登录获取不同角色的token，避免前端伪造。

“订单的状态流转是怎么设计的？”回答思路：在service_order表里维护status字段，状态值包括待支付、待服务、服务中、已完成、已取消。状态更新不允许跨级跳转，比如待支付不能直接变成已完成，所以设计了一张order_status_log表记录每一次状态变更。这个回答既说明了业务逻辑，又合理引出了你的表设计是有深意的。

“你的系统相比线下传统方式有什么优势？”回答思路：不要泛泛地说“方便、快捷”，要给出具体场景，比如子女在外地工作，可以通过小程序查看父母健康数据和服务记录；老人遇到突发情况可以一键SOS，系统自动通知紧急联系人；服务过程全留痕，平台可以追溯服务质量。三个点覆盖了社会需求、技术实现、平台价值三个维度。

“如果用户量变大，你的系统哪里最容易成为瓶颈？”回答思路：这个问题的考察点是看你对系统架构有没有思考。可以从三点回答：一是MySQL单库单表，数据量大后需要分库分表或引入读写分离；二是扫码登录和请求认证每次都查数据库，可引入Redis做会话缓存；三是服务图片等静态资源如果放在本地服务器，带宽会吃紧，未来要接对象存储和CDN。即使这些功能没实现，也要说得出方案。

5.3 提升整个项目档次的几个补充招数

毕设想拿高分，不需要把功能做得非常多，但一定要有几个“让老师觉得你动了脑子”的点。

第一招：在服务完成时让用户评价，评价数据回传后反向影响服务项目的排序。比如评分高的服务项目在列表页靠前，这个逻辑用一条SQL就能实现，但体现了“数据驱动运营”的思维。

第二招：给健康记录加“异常提醒”。让家属端设置血压/血糖的报警阈值，当新增记录超过阈值时，健康模块自动给家属推送订阅消息。这个功能不复杂，但论述价值很高，论文“系统特色”章节可以大书特书，答辩开场白也用得上。

第三招：接一个简单的数据统计接口。管理后台展示今日订单量、待服务订单数、服务完成率等指标，哪怕只是从订单表里SELECT COUNT(*)汇总出来的，也会让导师觉得系统有“平台管理”的概念，而不是简单的增删改查。

第四招：在代码里多写注释和日志。给核心Service类和状态流转方法写上清晰注释，在业务关键节点打印日志（如订单创建、接单、完成），答辩前把日志打印放在明显的位置，演示时现场展示日志输出，效果比你讲十页PPT都好。

5.4 论文（LW文档）怎么写不被老师挑毛病

毕业设计文档是这个项目的一半，很多同学重代码轻文档，结果代码能跑但论文被导师打回去改了三轮。这里分享一条清晰的文档主线：

• 绪论：写背景、国内外现状、研究内容。背景重点写老龄化趋势和社区养老政策的推进，但别大段堆政策原文，一两句带过即可，重点放在“信息不对称、服务响应慢、子女远程关怀缺失”这几个痛点上。
• 相关技术介绍：微信小程序框架、Spring Boot、MySQL、MyBatis-Plus，每项写300字左右，不要写成百度百科全文复制，要写“用在项目的哪个环节”。
• 需求分析：画用例图和角色图，把P0功能写成结构化用例表格（用例名称、参与者、触发条件、主流程、异常流）。
• 系统设计：架构图、功能模块图、数据库ER图、核心表结构。这里要贴完整的建表SQL，至少贴6到8张表的SQL。
• 系统实现：每个核心功能配一张页面截图 + 一段核心代码 + 两三句实现说明。注意代码不是越多越好，截取关键片段并加注释。
• 系统测试：写功能测试用例列表和测试结论，不要写“系统运行良好”，要写“通过XX个核心用例、XX个边界测试，整体满足需求”。

论文和源代码打包时，注意目录结构要清晰：doc/放开题报告、论文、答辩PPT，code/放后端工程和前端工程，sql/放初始化脚本，images/放截图和数据库设计图。一个整理干净的交付包在导师那里的第一印象分差距很大。

写在最后

从头到尾带完一个居家养老小程序项目，我最大的体会是：毕业设计不是要把系统做到商业级，而是要证明你“具备独立完成一个完整项目的能力”。所以永远把重心放在主流程闭环上，像微信登录、下单、状态流转、消息通知这几个核心链路，每一个环节都要能讲清楚“为什么这么设计”，远比堆砌十几个半成品功能有用得多。

最后分享一个关于写代码节奏的小技巧：每天开始写代码前，花10分钟把当天要完成的接口、页面、数据表变动写在项目根目录的DEV_NOTES.md里，哪怕只有五行。坚持到答辩前，这份笔记就是你整理论文第五章“系统实现”和答辩论述的最佳素材，讲起自己做过什么时，底气完全不同。

如果你正在找类似选题，或者已经做到一半被某个功能卡住，希望这篇梳理能帮你把思路理顺。照着这个骨架去搭，项目能跑、论文能写、答辩能讲，就够用了。剩下的细节，遇到具体问题了再逐一击破。