如果你正在为毕业设计选题头疼又不想做那种烂大街的图书管理系统或学生信息管理系统我的建议是多看看身边真实的需求。我这次完成的“基于微信小程序的社区宠物领养系统”就是从校园周边社区的实际情况出发围绕流浪动物救助与领养信息不对称问题做的完整项目包含了微信小程序端、后台管理端以及配套的LW文档论文等文字资料。整套系统从需求调研到上线演示大概花了三个月踩了不少坑也积累了很多可以写进答辩PPT的细节今天把这些东西整理出来希望能给正在做同类题目的同学一点参考。这个系统到底解决了什么问题简单说社区里想领养宠物的人找不到靠谱渠道救助站或好心人捡到流浪猫狗又不知道往哪里送供需两端中间缺了一个“可信任、可追溯、可管理”的桥。微信小程序恰好天然贴合这个场景——用户不用下载App扫码即用社区里转发也方便。对毕业设计来说它既有业务复杂度又不需要太多硬件依赖做完之后能讲清楚前端页面怎么交互、后端接口怎么设计、数据库表怎么关联、状态怎么流转这些都在计算机专业老师的关注范围里。下面按我的实际开发顺序来写先说定题再说数据库与功能规划然后是前后端实现和测试部署最后聊聊LW文档怎么组织。1. 定题之前的思考宠物领养为什么要放到微信小程序里1.1 选题背景里的真实需求当时我身边的社区和校园里有不少流浪猫同学们会在群里发领养信息但群消息很快被刷掉领养人信息也无法审核送养人只能靠私聊一单一单沟通。这种场景非常适合做成“社区宠物领养系统”救助人发布宠物照片和基本情况有领养意向的人通过小程序提交申请管理员或送养人在后台审核双方达成一致后完成线下交接。从毕业设计的角度看这个选题覆盖了典型的C端用户流程和B端管理流程。用户端有浏览、搜索、筛选、申请、消息通知管理端有宠物信息管理、领养申请审核、用户管理、数据统计。每一块都能对应到课程里的数据库设计、接口规范、前后端分离、状态管理等知识点答辩时无论老师问业务还是问技术都有内容可以讲。1.2 为什么不是Web端或原生App我一开始想过做成普通网页但后来发现微信小程序有几个无法替代的优势。第一它对普通用户几乎没有使用门槛微信扫一扫或者搜索小程序就能打开不需要注册新账号依托微信登录可以快速建立用户身份。第二宠物领养带有地域属性小程序容易在社区群、业主群、校园群里转发场景匹配度远高于一个独立网站。第三如果你在高校做毕业设计微信开发者工具和云开发环境都很成熟即使不自己搭服务器也能把项目完整跑起来。当然小程序也不是没有限制。审核比较严格用户隐私协议、图片内容安全都要考虑如果后端用自建服务器还必须配置HTTPS并把域名加到小程序后台白名单。这些细节在开发时让人头疼但反过来也是论文里“系统测试与问题解决”章节的好素材。2. 功能规划与数据库设计把领养流程变成能落地的表结构2.1 角色划分与核心流程这个系统我设计了三种角色普通用户领养者、送养人可以是管理员或普通用户、系统管理员。实际开发时为了控制复杂度前两种角色合并成“用户”管理员单独一个后台。核心流程用一句话概括送养人发布宠物信息管理员审核宠物信息并展示在小程序首页领养人浏览并提交申请管理员在后台审核领养申请双方联系完成领养之后宠物状态从“待领养”变为“已领养”。如果审核不通过流程要能回退领养人需要能看到被拒原因。这里最容易被忽略的是状态管理。宠物状态至少要有待审核、待领养、申请中、已领养、下架。申请状态至少要有待审核、已通过、已拒绝、已完成、用户取消。我在开发时把状态常量全部抽出来前端用枚举后端用状态码避免出现“1代表什么2代表什么”只能在代码里翻的尴尬。2.2 核心数据表与字段设计数据库我选了MySQL表结构一共八张用户表、宠物信息表、领养申请表、宠物图片表、消息通知表、收藏表、字典表、操作日志表。这里重点说几张最关键的表。用户表除了基本的openid、昵称、头像、手机号之外我额外加了一个user_type字段用来区分普通用户和管理员。Openid是微信返回的唯一标识建议直接建唯一索引后续所有业务都用openid关联不要在业务代码里用昵称当主键。宠物信息表是最复杂的表字段包括宠物名称、种类猫/狗/其他、品种、性别、年龄、是否绝育、是否驱虫、疫苗情况、健康状况描述、所在小区或社区、联系人信息、状态、审核状态、发布时间等。因为同一只宠物有多张照片我单独建了宠物图片表用pet_id关联主表只存一张封面图URL自己写一个字段命名规则比如cover_url和小图列表。领养申请表是流程的核心包含apply_no申请编号我用日期加随机数生成、宠物ID、申请者ID、申请说明、联系方式、期望领养日期、审核状态、审核意见、审核人、审核时间。这里要注意申请表和宠物表是一对多关系一只宠物可能接收到多次申请业务规则是同一时间只允许一个申请处于“待审核”状态否则会乱套。以下是我的建表示例节选核心字段CREATE TABLE pet_info ( id INT AUTO_INCREMENT PRIMARY KEY, pet_name VARCHAR(50) NOT NULL COMMENT 宠物昵称, pet_type TINYINT NOT NULL COMMENT 1猫 2狗 3其他, breed VARCHAR(50) DEFAULT COMMENT 品种, gender TINYINT DEFAULT 0 COMMENT 0未知 1公 2母, age_desc VARCHAR(50) DEFAULT COMMENT 年龄描述如2个月, is_neuter TINYINT DEFAULT 0 COMMENT 0未绝育 1已绝育, is_vaccine TINYINT DEFAULT 0 COMMENT 0未接种 1已接种, status TINYINT DEFAULT 0 COMMENT 10待审核 20待领养 30领养中 40已领养 50下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status (status), KEY idx_type (pet_type) ) COMMENT宠物信息表;数据库设计这块我踩过的一个坑是一开始把图片URL直接塞在宠物表的字段里用逗号分隔。后来发现添加第二张图片或替换图片时要先取出来、切分、再拼接非常痛苦。单独建图片表并关联pet_id排序用sort_order字段后面小程序端做轮播图就很顺畅。3. 小程序端页面与交互用户从头到尾怎么走一遍流程3.1 首页信息流与宠物卡片小程序端我用的是原生微信小程序没有额外使用第三方框架。首页从上到下分成顶部搜索框、分类筛选栏猫、狗、其他、宠物卡片瀑布流。因为宠物图片大小不一瀑布流用两列布局图片使用heightFix或类似模式避免拉伸。宠物卡片需要展示的信息有封面图、宠物名、品种性别年龄、是否已绝育或已驱虫的标签、所在区域。点击卡片跳转到详情页。这里要提一下首页加载逻辑用户进入首页先请求/api/pet/list默认查询状态为“待领养”的宠物每次加载10条下拉触底时加载下一页。分页参数我用page和pageSize返回体统一为{ code: 0, data: { list, total, hasMore } }。搜索功能前后端都要做。前端在搜索框输入关键字防抖300毫秒后再发请求避免每个字都触发接口。后端搜索用Like关键字对宠物名称、品种、地区三个字段做匹配同时加上状态条件已经领养的宠物不会出现在搜索结果里。以下是前端请求的一个简单封装示例function request(url, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, data, method: POST, header: { Content-Type: application/json }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: (err) reject(err) }); }); }3.2 宠物详情页与领养申请的关键逻辑详情页顶部用swiper展示多张宠物图片下方展示宠物档案和送养人留言底部固定一个“申请领养”按钮。如果用户未登录点击按钮时先调用wx.login获取code再传给后端换取openid。领养申请是整套系统逻辑最重的部分。我设计成一个表单页字段包括领养人姓名、手机号、居住地址精确到小区、是否有养宠经验、家中是否有其他宠物、申请理由、可接受的回访方式。这些内容不是为了让用户填得脑壳疼而是给送养人审核时一个判断依据比如“有养宠经验”和“接受不定期回访”这两项能淘汰掉大部分冲动申请。提交申请时前端校验必填项后端二次校验第一确认宠物状态必须为“待领养”第二检查当前用户是否存在未处理的申请如果有就直接返回“您已申请过该宠物”第三检查用户是否拉黑或异常。通过后创建申请记录并同时更新宠物状态为“领养中”。更新宠物状态这一步很多人会漏掉事务处理。我的做法是把“创建申请”和“更新宠物状态”放在同一个事务里如果更新失败则整体回滚避免出现“申请创建了但宠物还是待领养”的数据不一致。3.3 消息通知与个人中心用户提交或者收到申请反馈后需要有一个地方能看到进展。我做了消息通知表每当状态变化时插入一条记录用户在小程序端“消息”Tab里查看列表用红点标记未读数量。个人中心展示用户头像、昵称、手机号如果授权过下面分成三个栏目我发布的宠物、我的领养申请、我的收藏。这里要特别注意用户解除授权的情况我通过wx.getUserProfile获取头像昵称但不少新用户会拒绝所以后端的默认昵称和默认头像逻辑一定要写好避免拿不到昵称直接报错。收藏功能比较简单收藏表存user_id和pet_id列表页和详情页都提供收藏入口。我后来把“收藏量”加到宠物表中作为冗余字段查询排热门宠物时不用再统计性能好一些。4. 后端接口与管理后台审核闭环怎么实现4.1 接口分域与权限校验后端我用的是Spring Boot接口按模块划分用户、宠物、申请、消息、后台管理。所有接口统一前缀/api返回结构统一为code msg data。权限控制是这个项目里最容易被老师追问的点。我实现了两层第一层是小程序登录态校验。用户登录后后端根据wx.login返回的code调用微信接口换得openid生成一个自定义token并存入缓存表小程序端每次请求都带上Authorization: token。后端用一个拦截器统一校验token是否存在、是否过期并解析出当前用户ID放进ThreadLocal。第二层是管理员权限校验。后台管理接口的URL都以/admin开头拦截器会额外校验当前用户角色的user_type是否为管理员。如果权限不足直接返回code: 403。这里不要只在前端隐藏按钮后端必须拦因为小程序端非常容易被绕过。4.2 宠物发布与图片上传的细节宠物发布可以拆成两步先上传图片再提交宠物信息。图片上传我用的wx.chooseImage选择图片然后逐个调用wx.uploadFile上传到后端后端把文件保存到服务器静态目录返回可访问的URL。因为小程序要求前端访问域名必须HTTPS且白名单备案本地联调时我用的是开发者工具的“不校验合法域名”上线演示前再切换为正式域名。批量上传时有一个体验优化点不能一次把10张图片全部并发放出去微信开发者工具有一定的并发限制我通常控制同时最多3个上传请求并在页面显示上传进度条。后端接收图片时最好用UUID重命名文件避免中文名乱码和重名覆盖问题。宠物信息提交成功后状态默认是“待审核”需要管理员在后台审核通过后才会出现在小程序首页。这既是为了过滤发错分类或违规信息也符合宠物领养的信任要求。4.3 后台管理界面与审核状态流转管理后台我用了一个简单的后台模板做的页面功能包括登录、宠物列表、宠物审核、领养申请审核、用户列表、数据统计。宠物审核列表里每条宠物显示一张缩略图和详情摘要管理员可以查看完整信息点击“通过”或“不通过”。不通过时必须填写原因原因会推送到消息通知里让送养人知道为什么被拒绝。领养申请审核是整个项目的业务核心。管理员进入“申请列表”后可以看到某个用户对某只宠物提交的申请以及领养人在表单里填写的详细理由。审核结果为“通过”后系统自动把宠物状态改为“已领养”并给送养人发消息提示其尽快联系领养人完成交接。审核为“拒绝”时宠物状态回到“待领养”并且给当前领养人发送拒绝原因方便他调整后再次申请。状态流转图不用画太复杂核心就是确保每一步都有前置状态校验。我在代码里写了一个PetStatusMachine类只有预定状态转换才允许执行非法跳转会抛出异常。答辩或写文档时这个类可以直接作为业务健壮性的证据。5. 联调测试与部署踩过的坑和能写进论文的细节5.1 本地开发中的三个常见坑坑一局域网IP访问后端。手机预览小程序时localhost:8080无法访问必须把接口地址改为电脑局域网IP并且电脑防火墙要放行对应端口。我在本地demo阶段用真机测试时接口一直失败最后发现是安卓手机和电脑不在同一个Wi-Fi网段改成手机热点后马上就好。坑二微信登录session_key有效期。wx.login拿到的code一次性的5分钟有效换取的session_key有效期也不能持久。我最初把openid存在前端缓存里结果删除重装小程序后openid能拿到但session_key过期后端业务失败。后来统一改成每次启动小程序都静默wx.login把code发给后端后端维护自己的token前端只保存token不关心openid。坑三图片域名限制。小程序渲染网络图片时如果图片域名没有加入“downloadFile合法域名”图片会不显示。开发工具可以勾选跳过校验但正式环境必须配置。如果使用对象存储还要配合CDN回源设置。我在部署阶段因为漏配一个域名首页图片加载不出来排查了一个晚上。5.2 部署时的HTTPS与域名校验如果不想自己买服务器和域名可以使用微信云开发免鉴权数据库和存储都有免费额度。如果想自己部署需要一台云服务器、一个已备案的域名以及HTTPS证书。云服务器我推荐用轻量级的即可配置不用太高1核2G跑Spring Boot加MySQL完全没问题。HTTPS证书申请后需要配置到Nginx反向代理后端接口。小程序端请求的BASE_URL要改成https://你的域名/api。这里有一个特别容易忽略的细节Nginx配置里要设置client_max_body_size否则多图上传大文件时接口直接返回413客户端却看不出原因。部署完成后不要急着演示一定用微信开发者工具关闭“不校验合法域名”选项从头走一遍完整领养流程。正式环境第一次审核小程序提交时类目选择“生活服务-宠物”需要提交相关的资质或个人身份信息每个地区的审核要求可能不同提前预留一个星期比较稳妥。5.3 数据统计与后续功能扩展思路最后是我的后端加了一个简单的统计接口用SQL语句按月份统计宠物发布量、领养成功量、申请量。小程序端管理后台展示三个卡片和一张柱状图。统计数据对毕业设计很有加分作用既体现了数据库聚合查询能力也说明系统有运营价值。如果想继续扩展可以考虑这几个方向引入地图模块显示附近待领养宠物、增加领养回访评价、增加宠物医疗信息表、对接微信订阅消息替代轮询通知。订阅消息比站内信更实用但需要申请模板并注意每次订阅只能下发一次限制。我个人的建议是在文档里写“已预留扩展接口”不要在毕业设计阶段全部做进去毕竟时间有限核心流程完整跑通是最重要的。6. 写LW文档时我是怎么组织内容的6.1 章节安排与代码对应关系LW文档不是软件说明书而是要让评审老师快速看懂“你做了什么、怎么做的、为什么这么做”。我的文档目录是标准的六章但每章都跟实际代码对应第一章绪论写背景与意义重点写“当前社区宠物领养信息分散于微信群、缺乏审核机制”这个痛点引出小程序解决方案。第二章相关技术介绍这部分不要大量堆名词重点说明为什么选微信原生小程序、Spring Boot和MySQL写一句就够了“原生开发避免额外依赖Spring Boot快速构建RESTful接口MySQL满足中小型项目数据存取需求”。第三章需求分析给出功能用例图和领养业务流程图把角色权限讲清楚。第四章系统设计包括总体架构、功能模块设计、数据库表设计这是我花时间最多的一章。第五章系统实现按页面和接口贴关键代码块避免整段贴长代码。第六章系统测试包含功能测试和性能测试概述。6.2 测试章节不能只写“能运行”有的同学论文里测试全是“点击按钮系统响应正常”这种内容答辩必被质疑。我的测试表是这样设计的每个功能模块一列前置条件、操作步骤、预期结果、实际结果、是否符合预期。比如对于“重复申请”用例前置条件是“该用户已申请过某宠物”操作是“再次提交领养申请”预期结果是“前端提示该宠物已申请过”实际结果是“提示成功且后端拒绝创建记录”结论“符合预期”。我还针对状态冲突做了一次模拟测试管理员先通过领养申请又尝试修改宠物状态为待领养由于状态机限制直接返回非法操作。这种结论能体现出你考虑了业务流程的边界是老师比较认可的测试内容。6.3 源码压缩包与文档打包时的细节最后说一下项目交付时的小事项。源码包要包含清晰的README写清楚工程结构、数据库初始化SQL、接口文档路径、管理员账号说明。LW文档里引用的图片需要单独打包一份高清原图。演示视频不要超过十分钟重点录首页浏览、发布宠物、提交申请、管理员审核这四个环节视频里关闭开发者工具的调试模式避免左上角出现一堆Layout warnings。这些细节看起来和“代码”无关但在评审环节直接影响第一印象。毕竟老师拿到手上的是一份完整材料不是在Git仓库里边翻边感叹你的代码多优雅。做完整个项目我最大的体会是毕业设计选题不怕小就怕做完讲不清楚逻辑。宠物领养系统听起来不复杂但把它拆成用户、送养人、管理员三个视角再串起发布、审核、申请、再审核、交接这条状态链业务完整度就出来了。现在再有人问我“小程序毕设做什么题目好”我仍然会推荐这个方向——前提是你愿意把每一个状态流转、每一次权限校验都做成能讲出理由的设计而不是东拼西凑一个能跑的Demo。代码能实现什么界面只是下限文档里能解释清楚“为什么这么设计”才是毕业设计的真正加分项。
如果你正在为毕业设计选题头疼又不想做那种烂大街的图书管理系统或学生信息管理系统我的建议是多看看身边真实的需求。我这次完成的“基于微信小程序的社区宠物领养系统”就是从校园周边社区的实际情况出发围绕流浪动物救助与领养信息不对称问题做的完整项目包含了微信小程序端、后台管理端以及配套的LW文档论文等文字资料。整套系统从需求调研到上线演示大概花了三个月踩了不少坑也积累了很多可以写进答辩PPT的细节今天把这些东西整理出来希望能给正在做同类题目的同学一点参考。这个系统到底解决了什么问题简单说社区里想领养宠物的人找不到靠谱渠道救助站或好心人捡到流浪猫狗又不知道往哪里送供需两端中间缺了一个“可信任、可追溯、可管理”的桥。微信小程序恰好天然贴合这个场景——用户不用下载App扫码即用社区里转发也方便。对毕业设计来说它既有业务复杂度又不需要太多硬件依赖做完之后能讲清楚前端页面怎么交互、后端接口怎么设计、数据库表怎么关联、状态怎么流转这些都在计算机专业老师的关注范围里。下面按我的实际开发顺序来写先说定题再说数据库与功能规划然后是前后端实现和测试部署最后聊聊LW文档怎么组织。1. 定题之前的思考宠物领养为什么要放到微信小程序里1.1 选题背景里的真实需求当时我身边的社区和校园里有不少流浪猫同学们会在群里发领养信息但群消息很快被刷掉领养人信息也无法审核送养人只能靠私聊一单一单沟通。这种场景非常适合做成“社区宠物领养系统”救助人发布宠物照片和基本情况有领养意向的人通过小程序提交申请管理员或送养人在后台审核双方达成一致后完成线下交接。从毕业设计的角度看这个选题覆盖了典型的C端用户流程和B端管理流程。用户端有浏览、搜索、筛选、申请、消息通知管理端有宠物信息管理、领养申请审核、用户管理、数据统计。每一块都能对应到课程里的数据库设计、接口规范、前后端分离、状态管理等知识点答辩时无论老师问业务还是问技术都有内容可以讲。1.2 为什么不是Web端或原生App我一开始想过做成普通网页但后来发现微信小程序有几个无法替代的优势。第一它对普通用户几乎没有使用门槛微信扫一扫或者搜索小程序就能打开不需要注册新账号依托微信登录可以快速建立用户身份。第二宠物领养带有地域属性小程序容易在社区群、业主群、校园群里转发场景匹配度远高于一个独立网站。第三如果你在高校做毕业设计微信开发者工具和云开发环境都很成熟即使不自己搭服务器也能把项目完整跑起来。当然小程序也不是没有限制。审核比较严格用户隐私协议、图片内容安全都要考虑如果后端用自建服务器还必须配置HTTPS并把域名加到小程序后台白名单。这些细节在开发时让人头疼但反过来也是论文里“系统测试与问题解决”章节的好素材。2. 功能规划与数据库设计把领养流程变成能落地的表结构2.1 角色划分与核心流程这个系统我设计了三种角色普通用户领养者、送养人可以是管理员或普通用户、系统管理员。实际开发时为了控制复杂度前两种角色合并成“用户”管理员单独一个后台。核心流程用一句话概括送养人发布宠物信息管理员审核宠物信息并展示在小程序首页领养人浏览并提交申请管理员在后台审核领养申请双方联系完成领养之后宠物状态从“待领养”变为“已领养”。如果审核不通过流程要能回退领养人需要能看到被拒原因。这里最容易被忽略的是状态管理。宠物状态至少要有待审核、待领养、申请中、已领养、下架。申请状态至少要有待审核、已通过、已拒绝、已完成、用户取消。我在开发时把状态常量全部抽出来前端用枚举后端用状态码避免出现“1代表什么2代表什么”只能在代码里翻的尴尬。2.2 核心数据表与字段设计数据库我选了MySQL表结构一共八张用户表、宠物信息表、领养申请表、宠物图片表、消息通知表、收藏表、字典表、操作日志表。这里重点说几张最关键的表。用户表除了基本的openid、昵称、头像、手机号之外我额外加了一个user_type字段用来区分普通用户和管理员。Openid是微信返回的唯一标识建议直接建唯一索引后续所有业务都用openid关联不要在业务代码里用昵称当主键。宠物信息表是最复杂的表字段包括宠物名称、种类猫/狗/其他、品种、性别、年龄、是否绝育、是否驱虫、疫苗情况、健康状况描述、所在小区或社区、联系人信息、状态、审核状态、发布时间等。因为同一只宠物有多张照片我单独建了宠物图片表用pet_id关联主表只存一张封面图URL自己写一个字段命名规则比如cover_url和小图列表。领养申请表是流程的核心包含apply_no申请编号我用日期加随机数生成、宠物ID、申请者ID、申请说明、联系方式、期望领养日期、审核状态、审核意见、审核人、审核时间。这里要注意申请表和宠物表是一对多关系一只宠物可能接收到多次申请业务规则是同一时间只允许一个申请处于“待审核”状态否则会乱套。以下是我的建表示例节选核心字段CREATE TABLE pet_info ( id INT AUTO_INCREMENT PRIMARY KEY, pet_name VARCHAR(50) NOT NULL COMMENT 宠物昵称, pet_type TINYINT NOT NULL COMMENT 1猫 2狗 3其他, breed VARCHAR(50) DEFAULT COMMENT 品种, gender TINYINT DEFAULT 0 COMMENT 0未知 1公 2母, age_desc VARCHAR(50) DEFAULT COMMENT 年龄描述如2个月, is_neuter TINYINT DEFAULT 0 COMMENT 0未绝育 1已绝育, is_vaccine TINYINT DEFAULT 0 COMMENT 0未接种 1已接种, status TINYINT DEFAULT 0 COMMENT 10待审核 20待领养 30领养中 40已领养 50下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status (status), KEY idx_type (pet_type) ) COMMENT宠物信息表;数据库设计这块我踩过的一个坑是一开始把图片URL直接塞在宠物表的字段里用逗号分隔。后来发现添加第二张图片或替换图片时要先取出来、切分、再拼接非常痛苦。单独建图片表并关联pet_id排序用sort_order字段后面小程序端做轮播图就很顺畅。3. 小程序端页面与交互用户从头到尾怎么走一遍流程3.1 首页信息流与宠物卡片小程序端我用的是原生微信小程序没有额外使用第三方框架。首页从上到下分成顶部搜索框、分类筛选栏猫、狗、其他、宠物卡片瀑布流。因为宠物图片大小不一瀑布流用两列布局图片使用heightFix或类似模式避免拉伸。宠物卡片需要展示的信息有封面图、宠物名、品种性别年龄、是否已绝育或已驱虫的标签、所在区域。点击卡片跳转到详情页。这里要提一下首页加载逻辑用户进入首页先请求/api/pet/list默认查询状态为“待领养”的宠物每次加载10条下拉触底时加载下一页。分页参数我用page和pageSize返回体统一为{ code: 0, data: { list, total, hasMore } }。搜索功能前后端都要做。前端在搜索框输入关键字防抖300毫秒后再发请求避免每个字都触发接口。后端搜索用Like关键字对宠物名称、品种、地区三个字段做匹配同时加上状态条件已经领养的宠物不会出现在搜索结果里。以下是前端请求的一个简单封装示例function request(url, data {}) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, data, method: POST, header: { Content-Type: application/json }, success: (res) { if (res.data.code 0) { resolve(res.data.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: (err) reject(err) }); }); }3.2 宠物详情页与领养申请的关键逻辑详情页顶部用swiper展示多张宠物图片下方展示宠物档案和送养人留言底部固定一个“申请领养”按钮。如果用户未登录点击按钮时先调用wx.login获取code再传给后端换取openid。领养申请是整套系统逻辑最重的部分。我设计成一个表单页字段包括领养人姓名、手机号、居住地址精确到小区、是否有养宠经验、家中是否有其他宠物、申请理由、可接受的回访方式。这些内容不是为了让用户填得脑壳疼而是给送养人审核时一个判断依据比如“有养宠经验”和“接受不定期回访”这两项能淘汰掉大部分冲动申请。提交申请时前端校验必填项后端二次校验第一确认宠物状态必须为“待领养”第二检查当前用户是否存在未处理的申请如果有就直接返回“您已申请过该宠物”第三检查用户是否拉黑或异常。通过后创建申请记录并同时更新宠物状态为“领养中”。更新宠物状态这一步很多人会漏掉事务处理。我的做法是把“创建申请”和“更新宠物状态”放在同一个事务里如果更新失败则整体回滚避免出现“申请创建了但宠物还是待领养”的数据不一致。3.3 消息通知与个人中心用户提交或者收到申请反馈后需要有一个地方能看到进展。我做了消息通知表每当状态变化时插入一条记录用户在小程序端“消息”Tab里查看列表用红点标记未读数量。个人中心展示用户头像、昵称、手机号如果授权过下面分成三个栏目我发布的宠物、我的领养申请、我的收藏。这里要特别注意用户解除授权的情况我通过wx.getUserProfile获取头像昵称但不少新用户会拒绝所以后端的默认昵称和默认头像逻辑一定要写好避免拿不到昵称直接报错。收藏功能比较简单收藏表存user_id和pet_id列表页和详情页都提供收藏入口。我后来把“收藏量”加到宠物表中作为冗余字段查询排热门宠物时不用再统计性能好一些。4. 后端接口与管理后台审核闭环怎么实现4.1 接口分域与权限校验后端我用的是Spring Boot接口按模块划分用户、宠物、申请、消息、后台管理。所有接口统一前缀/api返回结构统一为code msg data。权限控制是这个项目里最容易被老师追问的点。我实现了两层第一层是小程序登录态校验。用户登录后后端根据wx.login返回的code调用微信接口换得openid生成一个自定义token并存入缓存表小程序端每次请求都带上Authorization: token。后端用一个拦截器统一校验token是否存在、是否过期并解析出当前用户ID放进ThreadLocal。第二层是管理员权限校验。后台管理接口的URL都以/admin开头拦截器会额外校验当前用户角色的user_type是否为管理员。如果权限不足直接返回code: 403。这里不要只在前端隐藏按钮后端必须拦因为小程序端非常容易被绕过。4.2 宠物发布与图片上传的细节宠物发布可以拆成两步先上传图片再提交宠物信息。图片上传我用的wx.chooseImage选择图片然后逐个调用wx.uploadFile上传到后端后端把文件保存到服务器静态目录返回可访问的URL。因为小程序要求前端访问域名必须HTTPS且白名单备案本地联调时我用的是开发者工具的“不校验合法域名”上线演示前再切换为正式域名。批量上传时有一个体验优化点不能一次把10张图片全部并发放出去微信开发者工具有一定的并发限制我通常控制同时最多3个上传请求并在页面显示上传进度条。后端接收图片时最好用UUID重命名文件避免中文名乱码和重名覆盖问题。宠物信息提交成功后状态默认是“待审核”需要管理员在后台审核通过后才会出现在小程序首页。这既是为了过滤发错分类或违规信息也符合宠物领养的信任要求。4.3 后台管理界面与审核状态流转管理后台我用了一个简单的后台模板做的页面功能包括登录、宠物列表、宠物审核、领养申请审核、用户列表、数据统计。宠物审核列表里每条宠物显示一张缩略图和详情摘要管理员可以查看完整信息点击“通过”或“不通过”。不通过时必须填写原因原因会推送到消息通知里让送养人知道为什么被拒绝。领养申请审核是整个项目的业务核心。管理员进入“申请列表”后可以看到某个用户对某只宠物提交的申请以及领养人在表单里填写的详细理由。审核结果为“通过”后系统自动把宠物状态改为“已领养”并给送养人发消息提示其尽快联系领养人完成交接。审核为“拒绝”时宠物状态回到“待领养”并且给当前领养人发送拒绝原因方便他调整后再次申请。状态流转图不用画太复杂核心就是确保每一步都有前置状态校验。我在代码里写了一个PetStatusMachine类只有预定状态转换才允许执行非法跳转会抛出异常。答辩或写文档时这个类可以直接作为业务健壮性的证据。5. 联调测试与部署踩过的坑和能写进论文的细节5.1 本地开发中的三个常见坑坑一局域网IP访问后端。手机预览小程序时localhost:8080无法访问必须把接口地址改为电脑局域网IP并且电脑防火墙要放行对应端口。我在本地demo阶段用真机测试时接口一直失败最后发现是安卓手机和电脑不在同一个Wi-Fi网段改成手机热点后马上就好。坑二微信登录session_key有效期。wx.login拿到的code一次性的5分钟有效换取的session_key有效期也不能持久。我最初把openid存在前端缓存里结果删除重装小程序后openid能拿到但session_key过期后端业务失败。后来统一改成每次启动小程序都静默wx.login把code发给后端后端维护自己的token前端只保存token不关心openid。坑三图片域名限制。小程序渲染网络图片时如果图片域名没有加入“downloadFile合法域名”图片会不显示。开发工具可以勾选跳过校验但正式环境必须配置。如果使用对象存储还要配合CDN回源设置。我在部署阶段因为漏配一个域名首页图片加载不出来排查了一个晚上。5.2 部署时的HTTPS与域名校验如果不想自己买服务器和域名可以使用微信云开发免鉴权数据库和存储都有免费额度。如果想自己部署需要一台云服务器、一个已备案的域名以及HTTPS证书。云服务器我推荐用轻量级的即可配置不用太高1核2G跑Spring Boot加MySQL完全没问题。HTTPS证书申请后需要配置到Nginx反向代理后端接口。小程序端请求的BASE_URL要改成https://你的域名/api。这里有一个特别容易忽略的细节Nginx配置里要设置client_max_body_size否则多图上传大文件时接口直接返回413客户端却看不出原因。部署完成后不要急着演示一定用微信开发者工具关闭“不校验合法域名”选项从头走一遍完整领养流程。正式环境第一次审核小程序提交时类目选择“生活服务-宠物”需要提交相关的资质或个人身份信息每个地区的审核要求可能不同提前预留一个星期比较稳妥。5.3 数据统计与后续功能扩展思路最后是我的后端加了一个简单的统计接口用SQL语句按月份统计宠物发布量、领养成功量、申请量。小程序端管理后台展示三个卡片和一张柱状图。统计数据对毕业设计很有加分作用既体现了数据库聚合查询能力也说明系统有运营价值。如果想继续扩展可以考虑这几个方向引入地图模块显示附近待领养宠物、增加领养回访评价、增加宠物医疗信息表、对接微信订阅消息替代轮询通知。订阅消息比站内信更实用但需要申请模板并注意每次订阅只能下发一次限制。我个人的建议是在文档里写“已预留扩展接口”不要在毕业设计阶段全部做进去毕竟时间有限核心流程完整跑通是最重要的。6. 写LW文档时我是怎么组织内容的6.1 章节安排与代码对应关系LW文档不是软件说明书而是要让评审老师快速看懂“你做了什么、怎么做的、为什么这么做”。我的文档目录是标准的六章但每章都跟实际代码对应第一章绪论写背景与意义重点写“当前社区宠物领养信息分散于微信群、缺乏审核机制”这个痛点引出小程序解决方案。第二章相关技术介绍这部分不要大量堆名词重点说明为什么选微信原生小程序、Spring Boot和MySQL写一句就够了“原生开发避免额外依赖Spring Boot快速构建RESTful接口MySQL满足中小型项目数据存取需求”。第三章需求分析给出功能用例图和领养业务流程图把角色权限讲清楚。第四章系统设计包括总体架构、功能模块设计、数据库表设计这是我花时间最多的一章。第五章系统实现按页面和接口贴关键代码块避免整段贴长代码。第六章系统测试包含功能测试和性能测试概述。6.2 测试章节不能只写“能运行”有的同学论文里测试全是“点击按钮系统响应正常”这种内容答辩必被质疑。我的测试表是这样设计的每个功能模块一列前置条件、操作步骤、预期结果、实际结果、是否符合预期。比如对于“重复申请”用例前置条件是“该用户已申请过某宠物”操作是“再次提交领养申请”预期结果是“前端提示该宠物已申请过”实际结果是“提示成功且后端拒绝创建记录”结论“符合预期”。我还针对状态冲突做了一次模拟测试管理员先通过领养申请又尝试修改宠物状态为待领养由于状态机限制直接返回非法操作。这种结论能体现出你考虑了业务流程的边界是老师比较认可的测试内容。6.3 源码压缩包与文档打包时的细节最后说一下项目交付时的小事项。源码包要包含清晰的README写清楚工程结构、数据库初始化SQL、接口文档路径、管理员账号说明。LW文档里引用的图片需要单独打包一份高清原图。演示视频不要超过十分钟重点录首页浏览、发布宠物、提交申请、管理员审核这四个环节视频里关闭开发者工具的调试模式避免左上角出现一堆Layout warnings。这些细节看起来和“代码”无关但在评审环节直接影响第一印象。毕竟老师拿到手上的是一份完整材料不是在Git仓库里边翻边感叹你的代码多优雅。做完整个项目我最大的体会是毕业设计选题不怕小就怕做完讲不清楚逻辑。宠物领养系统听起来不复杂但把它拆成用户、送养人、管理员三个视角再串起发布、审核、申请、再审核、交接这条状态链业务完整度就出来了。现在再有人问我“小程序毕设做什么题目好”我仍然会推荐这个方向——前提是你愿意把每一个状态流转、每一次权限校验都做成能讲出理由的设计而不是东拼西凑一个能跑的Demo。代码能实现什么界面只是下限文档里能解释清楚“为什么这么设计”才是毕业设计的真正加分项。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
