尧图网站建设 
我先说句实在话很多同学第一次看到“基于微信小程序的社区养老服务平台”这种题目第一反应是“又是个毕设烂大街项目”。但真上手做一遍你会发现它把微信小程序前端、后端接口、数据库设计、角色权限、订单流转、甚至支付对接全串起来了是一个覆盖面很全、很能体现工程能力的项目。这篇文章我就以这个项目为例子把从立项到功能拆解、数据库设计、核心接口、前端实现、常见坑位的完整过程捋一遍。不管你是要做毕业设计还是想给自己的社区业务做个信息化试点都能直接照着落地。文里我会给出具体的表结构、接口定义、部署顺序和在调试过程中最容易翻车的地方内容比较长建议先收藏再慢慢看。1. 项目定位与整体架构拆解1.1 社区养老服务平台到底在解决什么问题社区养老和机构养老不一样老人大多数时间住在自己家里社区负责提供助餐、助浴、助医、上门护理、紧急呼叫这类服务。传统模式靠打电话、微信群、纸质登记表来流转信息非常散。做这个平台的核心目标就是把“老人档案、服务预约、工单派发、健康记录、费用结算”这几件事搬到线上让各方角色在一个闭环里协作。项目涉及的角色通常有四类老人/家属是服务发起方护工是服务执行方社区管理员是调度和审核方后台超级管理员负责系统配置和数据统计。一个合格的设计不能只做一个小程序页面而是要把这几类角色的使用路径都打通。比如老人家属在小程序里给父母预约上门保洁订单推给管理员审核管理员指派护工护工接单后上门打卡、填写服务记录家属在小程序里确认完成并付款最后管理员在后台看到完整的服务工单和评价数据。这种角色分工直接决定了技术选型。小程序适合老人家属和护工使用后台管理系统适合管理员在电脑上操作。所以项目需要做成“小程序端 Web管理后台 后端API服务”的形态而不只是一个小程序壳子。很多初学者喜欢只盯小程序页面把数据写死在本地这种做法在后端接口一接就崩根本走不通。做这类项目的第一步是先画清楚角色和业务流程图再动手写代码。1.2 技术选型为什么是原生小程序 Spring Boot MySQL技术选型是这个项目里最常被问、也最影响后面开发效率的决策点。前端我建议直接用微信小程序原生开发不要一上来就上uniapp或Taro。原因很简单原生框架虽然写起来啰嗦但每个API的调用逻辑、组件的生命周期、wx.request的返回结构都是直来直去的遇到问题在微信开发者工具里一查就清楚。uniapp这类跨端框架确实能一套代码多端复用但对一个社区养老服务场景来说主要用户就在微信里多端复用意义不大反而因为多了一层编译转换有时候代码在小程序端表现正常、在App端就变形排查成本更高。后端我推荐Spring Boot版本用2.x系列JDK用1.8或者11都行。Spring Boot 3.x虽然新但部分依赖和教程不兼容对刚接触项目的人来说踩坑成本太高没必要为了新而新。Spring Boot最大的好处是生态成熟Spring MVC写接口、MyBatis-Plus操作数据库、Spring Security或拦截器做权限每一个环节都有大量文档和现成代码可以参考。社区养老项目里涉及的订单、用户、健康记录这些表关系并不复杂Spring Boot完全扛得住而且部署到云服务器上也简单一个jar包就能跑起来。数据库用MySQL版本5.7或8.0都可以5.7更稳定8.0支持窗口函数和更好的JSON支持。字符集一定要设置成utf8mb4不然后面存emoji表情、生僻字都会出现乱码问题这是很多新手最容易忽略的细节。服务器部署时用Nginx做反向代理把HTTPS证书配置好小程序端才能正常发起request请求。微信小程序对接口域名有几个硬性要求必须HTTPS、必须ICP备案、需要在小程序后台配置request合法域名这几个点我后面会专门说。还有一点想提一下现在微信云开发也很流行不需要自己买服务器数据库和云函数都是现成的。如果项目只是为了快速出Demo或者内部演示云开发确实省事。但如果目标是完整交付一套可部署到企业服务器的系统或者毕设需要体现后端设计能力我还是推荐自己搭Spring Boot MySQL这套组合。原因很现实答辩或者项目验收的时候考官一定会问“你的数据表怎么设计的、接口怎么保证安全、订单状态怎么流转”这些问题用云开发很难讲清楚但用传统架构可以讲得很深。1.3 功能模块拆分三端一后台整个平台的功能模块可以拆成三个端小程序用户端、小程序护工端、Web管理后台。同一套后端服务通过不同的登录入口和角色权限让不同身份的用户看到不同的界面和操作按钮。小程序用户端解决的是“老人/家属能用”的问题。核心功能有微信登录、老人档案管理、服务项目浏览、服务预约下单、订单状态查询、健康打卡血压、心率、血糖、体温、健康趋势图表、紧急呼叫入口、消息通知。这个端的设计重点是操作简单、信息清晰按钮要够大字体不能太小毕竟很多实际使用者是老年人或者对手机不熟练的家属。小程序护工端解决的是“服务执行闭环”的问题。护工登录后能看到分配给自己的待接单任务接单后可以查看老人地址、预约时间、服务要求。上门时打卡确认到达服务完成后填写服务记录并提交家属端会同步看到服务完成状态。整个流程避免了线下沟通的扯皮每一步都有记录。Web管理后台解决的是“管理员管得过来”的问题。管理员可以维护老人信息和护工信息审核预约订单手动或者自动派单管理服务项目上架下架发布社区公告查看订单统计和健康数据汇总。如果项目再大一点还可以加护工排班、服务评价管理、费用结算报表这些功能可以作为后期扩展方向。这三个端不是独立存在的它们通过后端接口共享同一套数据。小程序用户端下单 - 后端写入订单表 - 管理后台看到新订单 - 管理员派单 - 护工端收到任务 - 执行完成 - 用户端确认。整个数据流是一条完整的链这也是这个项目最有价值的练习点不只是写页面而是把业务链路完整打通。2. 数据库设计与接口规划系统的地基在这2.1 核心数据表设计从用户到订单一次讲清数据库设计是整个项目的重中之重表设计得好不好直接决定后面写接口是顺手还是憋屈。我按业务模块把核心表分成五组每一组都有明确的职责边界。第一组是用户与角色核心表是user表。这张表不只是存登录账号还承担了角色区分的功能。字段包括id、openid微信唯一标识、nickname、avatar、phone、role老人/家属/护工/管理员、create_time。请注意openid是由微信根据小程序AppID和用户openid加密生成的前端把code传给后端后端再请求微信的code2Session接口才能拿到前端自己拿不到。这是很多新手容易搞混的地方。第二组是老人档案核心表是elderly表。这个表是整个平台业务的核心数据源。字段包括id、name、gender、birthday、id_card、address、health_desc基础病史、blood_type、allergy过敏史、emergency_contact紧急联系人、emergency_phone、risk_level风险等级、create_time。每一行对应一位老人而user表通过elderly_user_rel表或者直接在user表加elderly_id关联建立家属和老人之间的绑定关系。实际开发中一位家属可能绑定多位老人一位老人也可能有多个家属所以关联表更灵活建议用关系表来实现多对多映射。第三组是服务项目与订单这是业务流转的主链路。service_item表存服务项目字段有id、name、icon、price、duration、description、category助餐/助洁/助医/陪护、status上架/下架。order表存预约订单字段很多但每个都必须想清楚用途id、order_no订单号、elderly_id、user_id下单人、service_item_id、worker_id护理员、appointment_time预约时间、address、status待支付/待派单/已派单/服务中/已完成/已取消、pay_status、pay_time、amount、remark、create_time、update_time。订单状态机是这个项目里最容易写乱的部分我建议状态值只用英文小写字符串比如pending_payment、pending_assign、assigned、in_progress、completed、cancelled别用数字否则看数据都不知道3代表什么。第四组是健康数据核心表是health_record表。字段包括id、elderly_id、heart_rate、blood_pressure_high、blood_pressure_low、blood_sugar、temperature、record_time、remark。这张表是给老人健康打卡用的数据量会随着使用时间增长后期可以按老人和时间段做图表展示。健康数据的关键是关联关系要清晰一条健康记录必须能追溯到某一位老人这样才能在老人档案页里按时间轴展示趋势。第五组是运营管理包括emergency表紧急呼叫记录notice表公告evaluation表服务评价。emergency表记录老人紧急呼叫的时间、状态待处理/已处理、处理结果这个功能对养老场景特别重要哪怕只是采集和通知系统里也一定要留有痕迹。notice表存社区发布的公告内容在小程序首页轮播展示。我建议你在正式写代码之前先把这几张表用Navicat或者SQL脚本建好并且录入一批测试数据。不要边写接口边建表那样你会在接口参数和表字段之间反复改效率极低。建表脚本最好放在项目根目录的sql文件夹里这也是“文档交付”的一部分。2.2 接口设计统一返回结构才是王道后端接口设计要遵循两个原则统一返回结构和RESTful语义。统一返回结构非常重要不然前端每个页面都要单独解析json太痛苦。我通常定义一个Result类结构如下public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }code为200表示成功非200表示失败message给出错误原因data放真正的业务数据。前端小程序里可以封装一个request工具函数判断code后统一弹提示不用每个页面重复写错误处理。这个文件必须在项目一开始就写好后面所有接口都返回这个结构你会省掉大量联调时间。核心接口可以按模块拆成几组。用户模块POST /api/user/login参数为code、nickname、avatar后端通过code换取openid判断用户是否存在不存在则自动注册返回token和用户信息。GET /api/user/info获取当前登录用户信息需要token鉴权。这个接口是用户进入小程序后第一个调用的接口。老人档案模块GET /api/elderly/list获取当前用户绑定的老人列表GET /api/elderly/detail?idxx获取老人详情POST /api/elderly/add新增老人档案PUT /api/elderly/update更新老人信息。注意elderly接口必须做权限校验只有绑定了该老人的用户才能查看和修改后端要校验elderly_user_rel表里是否存在关联关系。服务与订单模块GET /api/service/list获取服务项目列表POST /api/order/create创建订单参数是elderlyId、serviceItemId、appointmentTime、address、remarkPOST /api/order/pay模拟支付后面会讲微信支付v3的思路GET /api/order/list?statusxx按状态查订单列表POST /api/order/cancel用户取消订单。这些接口是业务主链路前端所有关键流程都围绕它们展开。健康模块POST /api/health/add新增健康打卡记录GET /api/health/list?elderlyIdxx获取健康记录列表按时间倒序GET /api/health/statistics?elderlyIdxxdays30获取最近N天的统计数据用于前端画健康趋势图。管理端接口GET /api/admin/order/list管理员查所有订单支持按状态筛选POST /api/admin/order/assign给订单指派护工POST /api/admin/service/save新增或修改服务项目GET /api/admin/statistics/overview获取平台运营数据概览比如今日订单数、注册老人数、服务完成率。这些接口定义要在编码前写进接口文档里推荐直接用Swagger或者Apifox来管理。背后逻辑很简单接口先定好前端和后端并行开发时就知道对什么数据结构负责不会出现后端返回字段叫service_id、前端拿的字段叫serviceId然后双双怀疑人生的情况。3. 小程序端核心功能实现每个模块都能落地3.1 微信登录与用户身份识别微信小程序的登录流程是所有功能的前置条件它的机制和普通账号密码登录不同。前端调用wx.login拿到临时code这个code有效期只有5分钟且只能用一次。前端把code发给后端后端拿这个code加上小程序AppID和AppSecret去请求微信的code2Session接口获取openid和session_key。openid是用户在你这一个小程序里的唯一标识所有用户数据都以openid作为主键关联。这里要注意一个安全边界小程序AppSecret绝对不能放在前端代码里一旦泄露别人就能冒充你的小程序获取任意用户信息。AppSecret只能保存在后端服务中由后端发起请求。前端给后端传code的时候可以顺带把nickname和avatar传过去用于自动注册时初始化用户资料。登录成功后后端要生成一个自定义token返回给前端前端把token存到wx.setStorageSync里。后续每个需要鉴权的接口前端都在请求头里带上Authorization: Bearer ${token}。token的过期时间建议设成7天用户再次打开小程序时先检查本地有没有token有就直接用没有再走登录流程。为了用户体验登录页不要做得太重最好在启动页静默登录用户感知不到。代码实现上前端可以封装一个request方法统一处理token注入和401过期跳转const request (url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${token} }, success: (res) { if (res.data.code 200) { resolve(res.data.data) } else if (res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络请求失败, icon: none }) reject(err) } }) }) }这个封装是必须的。没有统一封装你可能要在十几个页面里重复写wx.request错误处理那是纯纯的内耗。3.2 首页与老人档案展示信息架构决定了体验小程序的首页是用户打开小程序后的第一屏直接影响用户对整个平台的信任感。我的设计思路是顶部是社区公告轮播中间是老人档案卡片和健康风险等级标签下面是可以直接预约的服务项目入口底部是紧急呼叫按钮。信息层级清楚老人家属打开就知道“我家老人的情况”和“我现在能做什么”。老人档案卡片是首页最核心的信息模块。卡片上要展示老人姓名、年龄、风险等级、最近体检时间和紧急联系人电话。点击卡片进入详情页能看到更完整的档案信息基础信息、病史信息、过敏信息、健康记录时间轴、服务记录。这里有个设计细节风险等级用颜色区分低风险绿色、中风险橙色、高风险红色一眼就能识别。这个色彩标识不是花架子而是养老场景里很实用的设计护工在接单前就能对老人状况有个预判。如果当前用户还没有绑定老人首页要给出明显的“添加老人”引导按钮点击后进入老人档案填写表单。表单字段不要一次性全展示那样会让人望而却步。我建议分两步第一步填核心信息姓名、性别、生日、地址、紧急联系人第二步填健康补充信息病史、过敏史、血型、风险等级。分步填写能让用户更愿意完成录入这个经验在很多业务场景都适用。老人档案页面还有一个容易被忽略但很重要的功能绑定关系管理。一位老人可能同时由儿子和女儿绑定了他们都能看到老人的健康数据。所以在老人档案详情页需要展示“守护人列表”并支持邀请家人绑定。小程序里可以通过生成带参的小程序码来实现邀请扫码后自动绑定到对应老人名下。这个功能可以放到后期迭代但设计上要在elderly_user_rel表里留好位置。3.3 服务预约与订单流转状态机是灵魂服务预约流程是用户最常用的路径也是项目里最容易出bug的地方。用户在首页点击“预约服务”后进入服务项目列表页选择服务类型助餐、助洁、助医、陪护查看价格和服务时长点击“立即预约”进入下单页。下单页要选择预约日期和时间段、填写服务地址、备注特殊要求最后点击“提交订单”。提交订单后数据流是这样的前端调用POST /api/order/create后端创建订单初始状态pending_payment。如果是纯演示项目我们直接提供一个“模拟支付”按钮点击后调用POST /api/order/pay后端模拟支付成功把订单状态改为pending_assign。如果接了微信支付v3就按真实支付流程走这个我后面单独讲。订单状态转移是整个模块的核心逻辑建议在后端写一个状态机校验不允许随意跳状态。比如已取消的订单不能变成已完成待支付订单不能直接进入服务中。我当时的实现是在Service层封装一个updateOrderStatus方法传入订单号和目标状态方法内部先查当前状态判断是否符合转移规则符合才更新。这种写法虽然多写几行但能避免大量脏数据。状态流转规则如下待支付 - 已取消用户主动取消待支付 - 待派单支付成功待派单 - 已派单管理员指派护工已派单 - 服务中护工到达打卡服务中 - 已完成护工填写完成记录已完成 - 已评价用户提交评价用户端订单列表页要支持按状态切换查看常见的有全部、待服务、进行中、已完成、已取消。每张订单卡片显示服务项目、老人姓名、预约时间、状态标签、操作按钮。状态标签的颜色要一致比如待服务橙色、进行中蓝色、已完成绿色、已取消灰色。这样用户在列表页扫一眼就能知道哪些订单需要处理。3.4 健康打卡与数据可视化让数据有用起来健康打卡模块是整个养老平台里最能体现行业属性的功能。老人每天可以在小程序里记录血压、心率、血糖、体温这几项关键指标数据存到health_record表。打卡页面设计成卡片式表单每项指标一个输入框加上单位提示。为了降低输入门槛我给心跳和体温做了快捷选择按钮比如心率过快/过慢/正常用户一键选择不用每次手动敲数字。健康数据的价值在于趋势分析。数据录入后前端要用图表展示变化趋势让家属能直观看到老人近30天的健康波动。图表实现方案有几种用ECharts的微信小程序版功能强大但体积大用ucharts轻量够用自己用canvas画折线图简单但需要自己处理坐标轴。我建议用ucharts集成简单折线图、柱状图、饼图都支持体积也能接受。健康数据还要在录入时做基础校验。比如收缩压的正常范围是90~140mmHg超出这个范围前端要提示“血压偏高请关注”同时在后台标记为异常记录。不要小看这个校验逻辑它让系统从“记录工具”变成了“健康预警工具”。更进一步异常数据也要弹窗提醒用户并且在管理后台的统计页面里标红方便社区工作人员重点关注高风险老人。还有一个容易忽略的点健康数据的隐私性。小程序端调用健康列表接口时后端要严格校验当前用户是否绑定了对应老人不能让别人通过遍历老人ID就能看到所有健康记录。我在实际项目中遇到过这种越权问题多亏接口联调阶段专门做了权限测试才补上漏洞。3.5 微信支付v3对接思路进阶加分项微信支付是小程序商业化的关键能力虽然很多毕设和演示项目用模拟支付带过但如果你能把微信支付v3真正对接上整个项目的完整度和专业度会上升一个档次。微信支付v3和v2最大的区别是API风格从XML变成了JSON签名方式从MD5变成了哈希签名整体更规范。对接流程是这样的小程序端下单后后端调用微信支付的JSAPI下单接口传参包括appid、mchid、description商品描述、out_trade_no商户订单号、notify_url支付结果回调地址、amount金额单位是分记得把元转成分。微信返回prepay_id后后端再按签名规则生成支付参数返回给前端。前端拿到参数后调用wx.requestPaymentwx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: RSA, paySign: res.data.paySign, success: (payRes) { // 支付成功跳转订单详情 }, fail: (err) { // 支付失败或取消处理逻辑 } })后端需要在notify_url接收支付结果回调回调里要验签使用微信支付平台证书的公钥验证签名确认订单号与金额一致后更新订单状态为已支付并返回成功应答。实际操作中微信支付v3有几个常见坑。第一个是商户号和AppID的绑定关系小程序支付必须在小程序后台和商户平台完成双向绑定否则报错。第二个是API证书和APIv3密钥的配置证书序列号要填对密钥要在请求头中通过Authorization带上。第三个是回调地址必须是HTTPS公网地址本地调试可以用内网穿透工具把本地服务暴露到公网。不过我也要说一句实在话微信支付的申请对主体资质有要求个人主体小程序无法开通微信支付必须是企业或个体工商户。很多学生在做项目时没有自己的商户号所以实际开发中“支付功能暂时无法使用”是很常见的情况。遇到这个问题最务实的处理方式是在后端保留微信支付接口的代码和对接文档同时提供一个“模拟支付”通道在管理后台可以切换支付模式。这样既不影响业务演示又能证明你具备真实对接的能力。面试或答辩时你可以直接说“我已经按照微信支付v3规范实现了对接但因为没有企业商户号演示环境走了模拟支付”这个说法非常加分。4. 后台管理与护工端缺一不可的闭环拼图4.1 管理后台任务派单与数据看板管理后台是整个平台的调度中心没有它前台的订单就成了无人处理的孤岛。Web管理后台我建议用Vue3 Element Plus来做或者直接用Spring Boot Thymeleaf做服务端渲染页面。如果团队里有人习惯用Vue那就用前后端分离如果是单人开发Thymeleaf能省掉跨域和前端打包的麻烦出活更快。考虑到这个项目有“源码文档”的交付压力管理后台的界面不用炫酷关键是信息清晰、操作高效。管理后台的核心页面有四块订单管理、老人管理、护工管理、数据统计。订单管理页面是使用频率最高的页面。管理员在订单列表中能看到所有待派单的订单按服务类型和地址筛选点击“指派护工”按钮后弹窗选择可用的护工。派单可以是手动指定也可以按规则自动推荐系统先查该地址附近的护工再按当前接单量排序把接单少的护工排在前面。这个自动推荐逻辑不复杂但能体现系统的“智能感”面试或答辩时可以重点讲一下。老人管理页面用来维护老人的基础档案和导入的测试数据一样管理员可以新增、编辑、删除老人信息。护工管理页面用来维护护工的入职信息、服务状态和评分。数据统计页面展示今日订单数、本周服务完成率、各服务类型占比、高风险老人数量等指标。在发起派单前系统最好先给护工发一条微信订阅消息提醒有新的待接单任务。微信订阅消息是可配置的小程序后台申请模板审核通过后后端在派单时调用订阅消息接口推送。这个功能能让整个订单闭环从“管理员操作”延伸到“护工感知”体验提升非常明显。4.2 护工端的接单与执行流程护工端的实现方式有两种一种是单独一个小程序另一种是在同一个小程序里通过角色切换显示不同页面。我推荐后者因为同一套代码维护成本低而且护工和家属都是从同一个入口进入用户心智更统一。护工登录后首页显示“我的任务”列表里是分配给自己的订单。订单卡片显示老人姓名、地址、服务项目、预约时间、联系电话。护工点击“开始服务”按钮需要获取当前定位证明自己确实到了老人位置。这里要调用wx.getLocation同时在app.json里声明requiredPrivateInfos字段。用户授权定位后前端把经纬度传给后端后端可以做一次简单的距离校验比如距离老人地址500米内才允许打卡。这个功能虽然简单但在项目演示时会有很好的效果因为它能证明你在认真做产品而不是凑功能。服务完成后护工在订单详情页填写服务记录包括服务内容、老人状态、有无异常情况、现场照片上传。照片上传用wx.uploadFile后端把图片存到本地目录或者云存储。上传图片要注意大小小程序端先压缩再上传单张控制在1MB以内不然流量消耗大、服务器压力也大。护工端的打卡和记录功能完成后订单状态变成“已完成”前端要触发订阅消息通知家属“服务已完成请确认并评价”。这一步是把整个服务链路的最后一环扣上让用户对服务结果有感知。5. 开发调试与交付实录那些反复踩过的坑5.1 微信小程序端高频报错与排查小程序开发的报错信息有时候比较迷糊但每个高频报错背后都有固定原因我整理成一张速查表遇到问题照着排查就行。表格整理报错信息常见原因解决方案不在以下 request 合法域名列表中开发者工具未勾选跳过域名校验开发阶段在详情-本地设置中勾选“不校验合法域名”上线必须配置域名域名不合法使用了IP地址或未备案域名访问接口部署到已备案域名并配置HTTPS证书组件 is not defined页面未注册第三方组件在页面的usingComponents中引入对应组件app.json 未找到入口文件pages路径配置错误检查pages数组是否与页面文件路径一致wx.request:fail url not in domain list真机预览时域名未在小程序后台配置登录小程序后台添加request合法域名401 Unauthorizedtoken过期或未携带检查请求头Authorization字段确认token是否有效开发阶段还有一个特别容易忽略的坑开发者工具默认是模拟器环境模拟器里能请求通的地址换到真机上可能请求不通。原因通常是本机IP或localhost。真机预览时需要把后端服务部署到局域网可访问的地址接口BASE_URL改成局域网IP。如果后端也是跑在本机真机和电脑必须在同一WiFi下且后端启动时要监听0.0.0.0而不是127.0.0.1。还有个微信开发者工具的怪癖有时候改完代码不生效或者运行报一些莫名其妙的错。处理方法很简单开发者工具菜单栏点“清缓存 - 清除全部缓存”然后重新编译。不要小看这个操作它能解决80%的“玄学”问题。5.2 后端接口联调与排查技巧后端接口联调是项目周期里耗时最长的阶段但也是最能体现工程能力的地方。我建议用Apifox或Postman管理接口测试。每个接口写完后先在后端Swagger页面或Apifox里测试通过再去和小程序前端联调。提前做好单测可以极大减少前后端扯皮。联调阶段最常遇到的问题有三个。第一个是跨域问题。小程序端wx.request没有浏览器那种跨域限制所以不用配置CORS。但Web管理后台用Vue开发时请求Spring Boot接口会跨域需要在后端添加CORS配置类允许指定来源访问。我建议只允许管理后台的本地开发地址访问别用allowedOrigins(*)不安全。第二个是参数名不一致的问题。后端习惯用下划线命名法如service_id前端习惯用驼峰命名法serviceId。MyBatis-Plus默认开启了驼峰转换所以只要数据库字段用下划线实体类用驼峰返回给前端的JSON字段就是驼峰。但如果你在XML里写了自定义resultMap一定要手动配置映射。这个错误很隐蔽数据查出来了但字段值是null排查起来非常耗时间。第三个是token失效与并发请求的问题。小程序端同一时间可能发起多个请求如果有一个接口返回401多个页面同时跳转登录页体验很差。建议在request封装里加一个“是否正在跳转登录”的锁只跳转一次。代码如下let isRedirecting false if (res.data.code 401) { if (!isRedirecting) { isRedirecting true wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) setTimeout(() { isRedirecting false }, 2000) } reject(res.data) }5.3 部署上线域名、HTTPS、备案一步都不能少小程序部署上线是一个完整工程不是把代码传上去就行。前后端要分别部署后端Spring Boot打包成jar包部署到云服务器管理后台前端构建成静态文件部署到Nginx的某个目录小程序前端在微信开发者工具里上传代码提交审核。后端部署步骤云服务器安装JDK和MySQL导入数据库初始化脚本。将jar包上传到服务器用nohup java -jar命令启动。当然这在正式环境不太讲究但演示和毕设完全够用。如果想更规范可以写一个systemd服务脚本实现开机自启和自动重启。Nginx配置要做两件事反向代理后端接口和托管管理后台静态页面。关键配置是location /api/代理到http://127.0.0.1:8080。HTTPS证书用Lets Encrypt免费证书或者云厂商免费证书证书配置好后小程序才能正常请求。域名必须ICP备案域名解析到服务器IP在小程序后台配置request合法域名。我见过很多同学项目功能都是好的卡在域名备案这一步上所以至少要提前两周搞定域名和备案。小程序端上传发布在微信开发者工具点击上传按钮填好版本号和备注然后到微信小程序管理后台提交审核。个人主体小程序有些类目不开放比如医疗服务和家政服务可能审核不通过这个要提前在小程序后台确认服务类目。正式发布前一定用体验版二维码做完整流程测试包括登录、下单、支付、打卡、后台派单不要急着提交审核。“源码文档调试”的交付建议源码目录要清晰按后端、小程序端、管理后台、数据库脚本、部署文档分类。文档至少包含需求说明书、系统设计文档、接口文档、部署说明手册每个文档要有图表可以截图代替流程图、要有目录、要能让人照着操作。调试阶段保留一份调试日志记录每个模块的测试环境、测试数据和问题修复记录这会在答辩和验收时给你加分。结尾我的几点真心建议把这个项目完整做下来我的体会是它不是一个“写个页面交差”的活而是一个需要你把用户端、管理端、数据流转、权限控制、异常处理全部串起来的系统工程。中间最让我抓狂的不是代码本身而是“订单状态乱了”“数据对不上”这种业务逻辑问题所以我才反复强调状态机设计要充分校验。如果你刚开始动手我有一个很具体的建议先把数据库脚本写好再把后端接口用Apifox跑通最后才碰小程序页面。顺序不要反。很多同学一上来就做页面页面好看但没数据驱动后期接接口时改动量非常大。反过来先把“数据地基”打牢页面只是表现层接起来会非常顺手。最后再分享一个小技巧项目里一定不要写死数据。哪怕是一个下拉框的服务项目列表也要走接口获取。虽然写死在前端会省事但一旦管理后台改了服务价格或状态前端就不同步了。所有数据走接口才是系统设计应有的样子也会让最终交付的源码看起来专业很多。希望这篇复盘能帮你少踩几个坑做完之后你会发现这种全链路业务项目带来的成长比单纯学某个框架要扎实得多。 基于微信小程序的社区养老服务平台全栈开发实战
我先说句实在话很多同学第一次看到“基于微信小程序的社区养老服务平台”这种题目第一反应是“又是个毕设烂大街项目”。但真上手做一遍你会发现它把微信小程序前端、后端接口、数据库设计、角色权限、订单流转、甚至支付对接全串起来了是一个覆盖面很全、很能体现工程能力的项目。这篇文章我就以这个项目为例子把从立项到功能拆解、数据库设计、核心接口、前端实现、常见坑位的完整过程捋一遍。不管你是要做毕业设计还是想给自己的社区业务做个信息化试点都能直接照着落地。文里我会给出具体的表结构、接口定义、部署顺序和在调试过程中最容易翻车的地方内容比较长建议先收藏再慢慢看。1. 项目定位与整体架构拆解1.1 社区养老服务平台到底在解决什么问题社区养老和机构养老不一样老人大多数时间住在自己家里社区负责提供助餐、助浴、助医、上门护理、紧急呼叫这类服务。传统模式靠打电话、微信群、纸质登记表来流转信息非常散。做这个平台的核心目标就是把“老人档案、服务预约、工单派发、健康记录、费用结算”这几件事搬到线上让各方角色在一个闭环里协作。项目涉及的角色通常有四类老人/家属是服务发起方护工是服务执行方社区管理员是调度和审核方后台超级管理员负责系统配置和数据统计。一个合格的设计不能只做一个小程序页面而是要把这几类角色的使用路径都打通。比如老人家属在小程序里给父母预约上门保洁订单推给管理员审核管理员指派护工护工接单后上门打卡、填写服务记录家属在小程序里确认完成并付款最后管理员在后台看到完整的服务工单和评价数据。这种角色分工直接决定了技术选型。小程序适合老人家属和护工使用后台管理系统适合管理员在电脑上操作。所以项目需要做成“小程序端 Web管理后台 后端API服务”的形态而不只是一个小程序壳子。很多初学者喜欢只盯小程序页面把数据写死在本地这种做法在后端接口一接就崩根本走不通。做这类项目的第一步是先画清楚角色和业务流程图再动手写代码。1.2 技术选型为什么是原生小程序 Spring Boot MySQL技术选型是这个项目里最常被问、也最影响后面开发效率的决策点。前端我建议直接用微信小程序原生开发不要一上来就上uniapp或Taro。原因很简单原生框架虽然写起来啰嗦但每个API的调用逻辑、组件的生命周期、wx.request的返回结构都是直来直去的遇到问题在微信开发者工具里一查就清楚。uniapp这类跨端框架确实能一套代码多端复用但对一个社区养老服务场景来说主要用户就在微信里多端复用意义不大反而因为多了一层编译转换有时候代码在小程序端表现正常、在App端就变形排查成本更高。后端我推荐Spring Boot版本用2.x系列JDK用1.8或者11都行。Spring Boot 3.x虽然新但部分依赖和教程不兼容对刚接触项目的人来说踩坑成本太高没必要为了新而新。Spring Boot最大的好处是生态成熟Spring MVC写接口、MyBatis-Plus操作数据库、Spring Security或拦截器做权限每一个环节都有大量文档和现成代码可以参考。社区养老项目里涉及的订单、用户、健康记录这些表关系并不复杂Spring Boot完全扛得住而且部署到云服务器上也简单一个jar包就能跑起来。数据库用MySQL版本5.7或8.0都可以5.7更稳定8.0支持窗口函数和更好的JSON支持。字符集一定要设置成utf8mb4不然后面存emoji表情、生僻字都会出现乱码问题这是很多新手最容易忽略的细节。服务器部署时用Nginx做反向代理把HTTPS证书配置好小程序端才能正常发起request请求。微信小程序对接口域名有几个硬性要求必须HTTPS、必须ICP备案、需要在小程序后台配置request合法域名这几个点我后面会专门说。还有一点想提一下现在微信云开发也很流行不需要自己买服务器数据库和云函数都是现成的。如果项目只是为了快速出Demo或者内部演示云开发确实省事。但如果目标是完整交付一套可部署到企业服务器的系统或者毕设需要体现后端设计能力我还是推荐自己搭Spring Boot MySQL这套组合。原因很现实答辩或者项目验收的时候考官一定会问“你的数据表怎么设计的、接口怎么保证安全、订单状态怎么流转”这些问题用云开发很难讲清楚但用传统架构可以讲得很深。1.3 功能模块拆分三端一后台整个平台的功能模块可以拆成三个端小程序用户端、小程序护工端、Web管理后台。同一套后端服务通过不同的登录入口和角色权限让不同身份的用户看到不同的界面和操作按钮。小程序用户端解决的是“老人/家属能用”的问题。核心功能有微信登录、老人档案管理、服务项目浏览、服务预约下单、订单状态查询、健康打卡血压、心率、血糖、体温、健康趋势图表、紧急呼叫入口、消息通知。这个端的设计重点是操作简单、信息清晰按钮要够大字体不能太小毕竟很多实际使用者是老年人或者对手机不熟练的家属。小程序护工端解决的是“服务执行闭环”的问题。护工登录后能看到分配给自己的待接单任务接单后可以查看老人地址、预约时间、服务要求。上门时打卡确认到达服务完成后填写服务记录并提交家属端会同步看到服务完成状态。整个流程避免了线下沟通的扯皮每一步都有记录。Web管理后台解决的是“管理员管得过来”的问题。管理员可以维护老人信息和护工信息审核预约订单手动或者自动派单管理服务项目上架下架发布社区公告查看订单统计和健康数据汇总。如果项目再大一点还可以加护工排班、服务评价管理、费用结算报表这些功能可以作为后期扩展方向。这三个端不是独立存在的它们通过后端接口共享同一套数据。小程序用户端下单 - 后端写入订单表 - 管理后台看到新订单 - 管理员派单 - 护工端收到任务 - 执行完成 - 用户端确认。整个数据流是一条完整的链这也是这个项目最有价值的练习点不只是写页面而是把业务链路完整打通。2. 数据库设计与接口规划系统的地基在这2.1 核心数据表设计从用户到订单一次讲清数据库设计是整个项目的重中之重表设计得好不好直接决定后面写接口是顺手还是憋屈。我按业务模块把核心表分成五组每一组都有明确的职责边界。第一组是用户与角色核心表是user表。这张表不只是存登录账号还承担了角色区分的功能。字段包括id、openid微信唯一标识、nickname、avatar、phone、role老人/家属/护工/管理员、create_time。请注意openid是由微信根据小程序AppID和用户openid加密生成的前端把code传给后端后端再请求微信的code2Session接口才能拿到前端自己拿不到。这是很多新手容易搞混的地方。第二组是老人档案核心表是elderly表。这个表是整个平台业务的核心数据源。字段包括id、name、gender、birthday、id_card、address、health_desc基础病史、blood_type、allergy过敏史、emergency_contact紧急联系人、emergency_phone、risk_level风险等级、create_time。每一行对应一位老人而user表通过elderly_user_rel表或者直接在user表加elderly_id关联建立家属和老人之间的绑定关系。实际开发中一位家属可能绑定多位老人一位老人也可能有多个家属所以关联表更灵活建议用关系表来实现多对多映射。第三组是服务项目与订单这是业务流转的主链路。service_item表存服务项目字段有id、name、icon、price、duration、description、category助餐/助洁/助医/陪护、status上架/下架。order表存预约订单字段很多但每个都必须想清楚用途id、order_no订单号、elderly_id、user_id下单人、service_item_id、worker_id护理员、appointment_time预约时间、address、status待支付/待派单/已派单/服务中/已完成/已取消、pay_status、pay_time、amount、remark、create_time、update_time。订单状态机是这个项目里最容易写乱的部分我建议状态值只用英文小写字符串比如pending_payment、pending_assign、assigned、in_progress、completed、cancelled别用数字否则看数据都不知道3代表什么。第四组是健康数据核心表是health_record表。字段包括id、elderly_id、heart_rate、blood_pressure_high、blood_pressure_low、blood_sugar、temperature、record_time、remark。这张表是给老人健康打卡用的数据量会随着使用时间增长后期可以按老人和时间段做图表展示。健康数据的关键是关联关系要清晰一条健康记录必须能追溯到某一位老人这样才能在老人档案页里按时间轴展示趋势。第五组是运营管理包括emergency表紧急呼叫记录notice表公告evaluation表服务评价。emergency表记录老人紧急呼叫的时间、状态待处理/已处理、处理结果这个功能对养老场景特别重要哪怕只是采集和通知系统里也一定要留有痕迹。notice表存社区发布的公告内容在小程序首页轮播展示。我建议你在正式写代码之前先把这几张表用Navicat或者SQL脚本建好并且录入一批测试数据。不要边写接口边建表那样你会在接口参数和表字段之间反复改效率极低。建表脚本最好放在项目根目录的sql文件夹里这也是“文档交付”的一部分。2.2 接口设计统一返回结构才是王道后端接口设计要遵循两个原则统一返回结构和RESTful语义。统一返回结构非常重要不然前端每个页面都要单独解析json太痛苦。我通常定义一个Result类结构如下public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ... } public static T ResultT error(String message) { ... } }code为200表示成功非200表示失败message给出错误原因data放真正的业务数据。前端小程序里可以封装一个request工具函数判断code后统一弹提示不用每个页面重复写错误处理。这个文件必须在项目一开始就写好后面所有接口都返回这个结构你会省掉大量联调时间。核心接口可以按模块拆成几组。用户模块POST /api/user/login参数为code、nickname、avatar后端通过code换取openid判断用户是否存在不存在则自动注册返回token和用户信息。GET /api/user/info获取当前登录用户信息需要token鉴权。这个接口是用户进入小程序后第一个调用的接口。老人档案模块GET /api/elderly/list获取当前用户绑定的老人列表GET /api/elderly/detail?idxx获取老人详情POST /api/elderly/add新增老人档案PUT /api/elderly/update更新老人信息。注意elderly接口必须做权限校验只有绑定了该老人的用户才能查看和修改后端要校验elderly_user_rel表里是否存在关联关系。服务与订单模块GET /api/service/list获取服务项目列表POST /api/order/create创建订单参数是elderlyId、serviceItemId、appointmentTime、address、remarkPOST /api/order/pay模拟支付后面会讲微信支付v3的思路GET /api/order/list?statusxx按状态查订单列表POST /api/order/cancel用户取消订单。这些接口是业务主链路前端所有关键流程都围绕它们展开。健康模块POST /api/health/add新增健康打卡记录GET /api/health/list?elderlyIdxx获取健康记录列表按时间倒序GET /api/health/statistics?elderlyIdxxdays30获取最近N天的统计数据用于前端画健康趋势图。管理端接口GET /api/admin/order/list管理员查所有订单支持按状态筛选POST /api/admin/order/assign给订单指派护工POST /api/admin/service/save新增或修改服务项目GET /api/admin/statistics/overview获取平台运营数据概览比如今日订单数、注册老人数、服务完成率。这些接口定义要在编码前写进接口文档里推荐直接用Swagger或者Apifox来管理。背后逻辑很简单接口先定好前端和后端并行开发时就知道对什么数据结构负责不会出现后端返回字段叫service_id、前端拿的字段叫serviceId然后双双怀疑人生的情况。3. 小程序端核心功能实现每个模块都能落地3.1 微信登录与用户身份识别微信小程序的登录流程是所有功能的前置条件它的机制和普通账号密码登录不同。前端调用wx.login拿到临时code这个code有效期只有5分钟且只能用一次。前端把code发给后端后端拿这个code加上小程序AppID和AppSecret去请求微信的code2Session接口获取openid和session_key。openid是用户在你这一个小程序里的唯一标识所有用户数据都以openid作为主键关联。这里要注意一个安全边界小程序AppSecret绝对不能放在前端代码里一旦泄露别人就能冒充你的小程序获取任意用户信息。AppSecret只能保存在后端服务中由后端发起请求。前端给后端传code的时候可以顺带把nickname和avatar传过去用于自动注册时初始化用户资料。登录成功后后端要生成一个自定义token返回给前端前端把token存到wx.setStorageSync里。后续每个需要鉴权的接口前端都在请求头里带上Authorization: Bearer ${token}。token的过期时间建议设成7天用户再次打开小程序时先检查本地有没有token有就直接用没有再走登录流程。为了用户体验登录页不要做得太重最好在启动页静默登录用户感知不到。代码实现上前端可以封装一个request方法统一处理token注入和401过期跳转const request (url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${token} }, success: (res) { if (res.data.code 200) { resolve(res.data.data) } else if (res.data.code 401) { wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(res.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: (err) { wx.showToast({ title: 网络请求失败, icon: none }) reject(err) } }) }) }这个封装是必须的。没有统一封装你可能要在十几个页面里重复写wx.request错误处理那是纯纯的内耗。3.2 首页与老人档案展示信息架构决定了体验小程序的首页是用户打开小程序后的第一屏直接影响用户对整个平台的信任感。我的设计思路是顶部是社区公告轮播中间是老人档案卡片和健康风险等级标签下面是可以直接预约的服务项目入口底部是紧急呼叫按钮。信息层级清楚老人家属打开就知道“我家老人的情况”和“我现在能做什么”。老人档案卡片是首页最核心的信息模块。卡片上要展示老人姓名、年龄、风险等级、最近体检时间和紧急联系人电话。点击卡片进入详情页能看到更完整的档案信息基础信息、病史信息、过敏信息、健康记录时间轴、服务记录。这里有个设计细节风险等级用颜色区分低风险绿色、中风险橙色、高风险红色一眼就能识别。这个色彩标识不是花架子而是养老场景里很实用的设计护工在接单前就能对老人状况有个预判。如果当前用户还没有绑定老人首页要给出明显的“添加老人”引导按钮点击后进入老人档案填写表单。表单字段不要一次性全展示那样会让人望而却步。我建议分两步第一步填核心信息姓名、性别、生日、地址、紧急联系人第二步填健康补充信息病史、过敏史、血型、风险等级。分步填写能让用户更愿意完成录入这个经验在很多业务场景都适用。老人档案页面还有一个容易被忽略但很重要的功能绑定关系管理。一位老人可能同时由儿子和女儿绑定了他们都能看到老人的健康数据。所以在老人档案详情页需要展示“守护人列表”并支持邀请家人绑定。小程序里可以通过生成带参的小程序码来实现邀请扫码后自动绑定到对应老人名下。这个功能可以放到后期迭代但设计上要在elderly_user_rel表里留好位置。3.3 服务预约与订单流转状态机是灵魂服务预约流程是用户最常用的路径也是项目里最容易出bug的地方。用户在首页点击“预约服务”后进入服务项目列表页选择服务类型助餐、助洁、助医、陪护查看价格和服务时长点击“立即预约”进入下单页。下单页要选择预约日期和时间段、填写服务地址、备注特殊要求最后点击“提交订单”。提交订单后数据流是这样的前端调用POST /api/order/create后端创建订单初始状态pending_payment。如果是纯演示项目我们直接提供一个“模拟支付”按钮点击后调用POST /api/order/pay后端模拟支付成功把订单状态改为pending_assign。如果接了微信支付v3就按真实支付流程走这个我后面单独讲。订单状态转移是整个模块的核心逻辑建议在后端写一个状态机校验不允许随意跳状态。比如已取消的订单不能变成已完成待支付订单不能直接进入服务中。我当时的实现是在Service层封装一个updateOrderStatus方法传入订单号和目标状态方法内部先查当前状态判断是否符合转移规则符合才更新。这种写法虽然多写几行但能避免大量脏数据。状态流转规则如下待支付 - 已取消用户主动取消待支付 - 待派单支付成功待派单 - 已派单管理员指派护工已派单 - 服务中护工到达打卡服务中 - 已完成护工填写完成记录已完成 - 已评价用户提交评价用户端订单列表页要支持按状态切换查看常见的有全部、待服务、进行中、已完成、已取消。每张订单卡片显示服务项目、老人姓名、预约时间、状态标签、操作按钮。状态标签的颜色要一致比如待服务橙色、进行中蓝色、已完成绿色、已取消灰色。这样用户在列表页扫一眼就能知道哪些订单需要处理。3.4 健康打卡与数据可视化让数据有用起来健康打卡模块是整个养老平台里最能体现行业属性的功能。老人每天可以在小程序里记录血压、心率、血糖、体温这几项关键指标数据存到health_record表。打卡页面设计成卡片式表单每项指标一个输入框加上单位提示。为了降低输入门槛我给心跳和体温做了快捷选择按钮比如心率过快/过慢/正常用户一键选择不用每次手动敲数字。健康数据的价值在于趋势分析。数据录入后前端要用图表展示变化趋势让家属能直观看到老人近30天的健康波动。图表实现方案有几种用ECharts的微信小程序版功能强大但体积大用ucharts轻量够用自己用canvas画折线图简单但需要自己处理坐标轴。我建议用ucharts集成简单折线图、柱状图、饼图都支持体积也能接受。健康数据还要在录入时做基础校验。比如收缩压的正常范围是90~140mmHg超出这个范围前端要提示“血压偏高请关注”同时在后台标记为异常记录。不要小看这个校验逻辑它让系统从“记录工具”变成了“健康预警工具”。更进一步异常数据也要弹窗提醒用户并且在管理后台的统计页面里标红方便社区工作人员重点关注高风险老人。还有一个容易忽略的点健康数据的隐私性。小程序端调用健康列表接口时后端要严格校验当前用户是否绑定了对应老人不能让别人通过遍历老人ID就能看到所有健康记录。我在实际项目中遇到过这种越权问题多亏接口联调阶段专门做了权限测试才补上漏洞。3.5 微信支付v3对接思路进阶加分项微信支付是小程序商业化的关键能力虽然很多毕设和演示项目用模拟支付带过但如果你能把微信支付v3真正对接上整个项目的完整度和专业度会上升一个档次。微信支付v3和v2最大的区别是API风格从XML变成了JSON签名方式从MD5变成了哈希签名整体更规范。对接流程是这样的小程序端下单后后端调用微信支付的JSAPI下单接口传参包括appid、mchid、description商品描述、out_trade_no商户订单号、notify_url支付结果回调地址、amount金额单位是分记得把元转成分。微信返回prepay_id后后端再按签名规则生成支付参数返回给前端。前端拿到参数后调用wx.requestPaymentwx.requestPayment({ timeStamp: res.data.timeStamp, nonceStr: res.data.nonceStr, package: res.data.package, signType: RSA, paySign: res.data.paySign, success: (payRes) { // 支付成功跳转订单详情 }, fail: (err) { // 支付失败或取消处理逻辑 } })后端需要在notify_url接收支付结果回调回调里要验签使用微信支付平台证书的公钥验证签名确认订单号与金额一致后更新订单状态为已支付并返回成功应答。实际操作中微信支付v3有几个常见坑。第一个是商户号和AppID的绑定关系小程序支付必须在小程序后台和商户平台完成双向绑定否则报错。第二个是API证书和APIv3密钥的配置证书序列号要填对密钥要在请求头中通过Authorization带上。第三个是回调地址必须是HTTPS公网地址本地调试可以用内网穿透工具把本地服务暴露到公网。不过我也要说一句实在话微信支付的申请对主体资质有要求个人主体小程序无法开通微信支付必须是企业或个体工商户。很多学生在做项目时没有自己的商户号所以实际开发中“支付功能暂时无法使用”是很常见的情况。遇到这个问题最务实的处理方式是在后端保留微信支付接口的代码和对接文档同时提供一个“模拟支付”通道在管理后台可以切换支付模式。这样既不影响业务演示又能证明你具备真实对接的能力。面试或答辩时你可以直接说“我已经按照微信支付v3规范实现了对接但因为没有企业商户号演示环境走了模拟支付”这个说法非常加分。4. 后台管理与护工端缺一不可的闭环拼图4.1 管理后台任务派单与数据看板管理后台是整个平台的调度中心没有它前台的订单就成了无人处理的孤岛。Web管理后台我建议用Vue3 Element Plus来做或者直接用Spring Boot Thymeleaf做服务端渲染页面。如果团队里有人习惯用Vue那就用前后端分离如果是单人开发Thymeleaf能省掉跨域和前端打包的麻烦出活更快。考虑到这个项目有“源码文档”的交付压力管理后台的界面不用炫酷关键是信息清晰、操作高效。管理后台的核心页面有四块订单管理、老人管理、护工管理、数据统计。订单管理页面是使用频率最高的页面。管理员在订单列表中能看到所有待派单的订单按服务类型和地址筛选点击“指派护工”按钮后弹窗选择可用的护工。派单可以是手动指定也可以按规则自动推荐系统先查该地址附近的护工再按当前接单量排序把接单少的护工排在前面。这个自动推荐逻辑不复杂但能体现系统的“智能感”面试或答辩时可以重点讲一下。老人管理页面用来维护老人的基础档案和导入的测试数据一样管理员可以新增、编辑、删除老人信息。护工管理页面用来维护护工的入职信息、服务状态和评分。数据统计页面展示今日订单数、本周服务完成率、各服务类型占比、高风险老人数量等指标。在发起派单前系统最好先给护工发一条微信订阅消息提醒有新的待接单任务。微信订阅消息是可配置的小程序后台申请模板审核通过后后端在派单时调用订阅消息接口推送。这个功能能让整个订单闭环从“管理员操作”延伸到“护工感知”体验提升非常明显。4.2 护工端的接单与执行流程护工端的实现方式有两种一种是单独一个小程序另一种是在同一个小程序里通过角色切换显示不同页面。我推荐后者因为同一套代码维护成本低而且护工和家属都是从同一个入口进入用户心智更统一。护工登录后首页显示“我的任务”列表里是分配给自己的订单。订单卡片显示老人姓名、地址、服务项目、预约时间、联系电话。护工点击“开始服务”按钮需要获取当前定位证明自己确实到了老人位置。这里要调用wx.getLocation同时在app.json里声明requiredPrivateInfos字段。用户授权定位后前端把经纬度传给后端后端可以做一次简单的距离校验比如距离老人地址500米内才允许打卡。这个功能虽然简单但在项目演示时会有很好的效果因为它能证明你在认真做产品而不是凑功能。服务完成后护工在订单详情页填写服务记录包括服务内容、老人状态、有无异常情况、现场照片上传。照片上传用wx.uploadFile后端把图片存到本地目录或者云存储。上传图片要注意大小小程序端先压缩再上传单张控制在1MB以内不然流量消耗大、服务器压力也大。护工端的打卡和记录功能完成后订单状态变成“已完成”前端要触发订阅消息通知家属“服务已完成请确认并评价”。这一步是把整个服务链路的最后一环扣上让用户对服务结果有感知。5. 开发调试与交付实录那些反复踩过的坑5.1 微信小程序端高频报错与排查小程序开发的报错信息有时候比较迷糊但每个高频报错背后都有固定原因我整理成一张速查表遇到问题照着排查就行。表格整理报错信息常见原因解决方案不在以下 request 合法域名列表中开发者工具未勾选跳过域名校验开发阶段在详情-本地设置中勾选“不校验合法域名”上线必须配置域名域名不合法使用了IP地址或未备案域名访问接口部署到已备案域名并配置HTTPS证书组件 is not defined页面未注册第三方组件在页面的usingComponents中引入对应组件app.json 未找到入口文件pages路径配置错误检查pages数组是否与页面文件路径一致wx.request:fail url not in domain list真机预览时域名未在小程序后台配置登录小程序后台添加request合法域名401 Unauthorizedtoken过期或未携带检查请求头Authorization字段确认token是否有效开发阶段还有一个特别容易忽略的坑开发者工具默认是模拟器环境模拟器里能请求通的地址换到真机上可能请求不通。原因通常是本机IP或localhost。真机预览时需要把后端服务部署到局域网可访问的地址接口BASE_URL改成局域网IP。如果后端也是跑在本机真机和电脑必须在同一WiFi下且后端启动时要监听0.0.0.0而不是127.0.0.1。还有个微信开发者工具的怪癖有时候改完代码不生效或者运行报一些莫名其妙的错。处理方法很简单开发者工具菜单栏点“清缓存 - 清除全部缓存”然后重新编译。不要小看这个操作它能解决80%的“玄学”问题。5.2 后端接口联调与排查技巧后端接口联调是项目周期里耗时最长的阶段但也是最能体现工程能力的地方。我建议用Apifox或Postman管理接口测试。每个接口写完后先在后端Swagger页面或Apifox里测试通过再去和小程序前端联调。提前做好单测可以极大减少前后端扯皮。联调阶段最常遇到的问题有三个。第一个是跨域问题。小程序端wx.request没有浏览器那种跨域限制所以不用配置CORS。但Web管理后台用Vue开发时请求Spring Boot接口会跨域需要在后端添加CORS配置类允许指定来源访问。我建议只允许管理后台的本地开发地址访问别用allowedOrigins(*)不安全。第二个是参数名不一致的问题。后端习惯用下划线命名法如service_id前端习惯用驼峰命名法serviceId。MyBatis-Plus默认开启了驼峰转换所以只要数据库字段用下划线实体类用驼峰返回给前端的JSON字段就是驼峰。但如果你在XML里写了自定义resultMap一定要手动配置映射。这个错误很隐蔽数据查出来了但字段值是null排查起来非常耗时间。第三个是token失效与并发请求的问题。小程序端同一时间可能发起多个请求如果有一个接口返回401多个页面同时跳转登录页体验很差。建议在request封装里加一个“是否正在跳转登录”的锁只跳转一次。代码如下let isRedirecting false if (res.data.code 401) { if (!isRedirecting) { isRedirecting true wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) setTimeout(() { isRedirecting false }, 2000) } reject(res.data) }5.3 部署上线域名、HTTPS、备案一步都不能少小程序部署上线是一个完整工程不是把代码传上去就行。前后端要分别部署后端Spring Boot打包成jar包部署到云服务器管理后台前端构建成静态文件部署到Nginx的某个目录小程序前端在微信开发者工具里上传代码提交审核。后端部署步骤云服务器安装JDK和MySQL导入数据库初始化脚本。将jar包上传到服务器用nohup java -jar命令启动。当然这在正式环境不太讲究但演示和毕设完全够用。如果想更规范可以写一个systemd服务脚本实现开机自启和自动重启。Nginx配置要做两件事反向代理后端接口和托管管理后台静态页面。关键配置是location /api/代理到http://127.0.0.1:8080。HTTPS证书用Lets Encrypt免费证书或者云厂商免费证书证书配置好后小程序才能正常请求。域名必须ICP备案域名解析到服务器IP在小程序后台配置request合法域名。我见过很多同学项目功能都是好的卡在域名备案这一步上所以至少要提前两周搞定域名和备案。小程序端上传发布在微信开发者工具点击上传按钮填好版本号和备注然后到微信小程序管理后台提交审核。个人主体小程序有些类目不开放比如医疗服务和家政服务可能审核不通过这个要提前在小程序后台确认服务类目。正式发布前一定用体验版二维码做完整流程测试包括登录、下单、支付、打卡、后台派单不要急着提交审核。“源码文档调试”的交付建议源码目录要清晰按后端、小程序端、管理后台、数据库脚本、部署文档分类。文档至少包含需求说明书、系统设计文档、接口文档、部署说明手册每个文档要有图表可以截图代替流程图、要有目录、要能让人照着操作。调试阶段保留一份调试日志记录每个模块的测试环境、测试数据和问题修复记录这会在答辩和验收时给你加分。结尾我的几点真心建议把这个项目完整做下来我的体会是它不是一个“写个页面交差”的活而是一个需要你把用户端、管理端、数据流转、权限控制、异常处理全部串起来的系统工程。中间最让我抓狂的不是代码本身而是“订单状态乱了”“数据对不上”这种业务逻辑问题所以我才反复强调状态机设计要充分校验。如果你刚开始动手我有一个很具体的建议先把数据库脚本写好再把后端接口用Apifox跑通最后才碰小程序页面。顺序不要反。很多同学一上来就做页面页面好看但没数据驱动后期接接口时改动量非常大。反过来先把“数据地基”打牢页面只是表现层接起来会非常顺手。最后再分享一个小技巧项目里一定不要写死数据。哪怕是一个下拉框的服务项目列表也要走接口获取。虽然写死在前端会省事但一旦管理后台改了服务价格或状态前端就不同步了。所有数据走接口才是系统设计应有的样子也会让最终交付的源码看起来专业很多。希望这篇复盘能帮你少踩几个坑做完之后你会发现这种全链路业务项目带来的成长比单纯学某个框架要扎实得多。