苏黎世贝勒爷选毕业设计题目那会儿，我翻了好几天的论文选题库，最后定下“走失儿童管理系统小程序的设计与实现”。原因其实很实在：儿童走失是一个一直存在的公共问题，做一套能帮助发布信息、收集线索、辅助寻人的系统，既有社会价值，又符合计算机毕设需要的“完整闭环”——小程序端、后端接口、数据库、后台管理，该有的技术点一个不少。而且题目里的“赠源码”对后来者非常友好，拿到手可以直接跑起来，再按照自己的论文思路去改，能省掉大量重复造轮子的时间。
整套系统做下来，我的体感是：它不是一个简单的“增删改查”小程序。表面上看就是发布走失信息、浏览信息、上报线索，但真正落地时涉及到微信登录、图片存储、地图定位、数据审核、状态流转这些环节，任何一个没处理好都会影响使用体验。所以我这篇文章不会只贴代码，而是把“为什么这么设计”“踩过哪些坑”“怎么跑起来”都讲清楚，给准备做类似毕设或想入门微信小程序开发的同学一份能直接参考的实战笔记。
1. 项目起点：为什么选“走失儿童管理系统”作为毕业设计
1.1 选题思路：不是只做一个“增删改查”
很多同学选毕设题目，容易掉进“管理系统”三个字里，最后做出来就是一个学生信息管理、图书管理的翻版，应付答辩可以，但写论文时没有亮点。我当时给自己定了一个筛选标准：必须是“移动端 + 服务端 + 真实业务场景”。微信小程序天然适合这个题目，因为寻人信息的传播高度依赖社交裂变，用户看到一条走失信息，一键转发到群聊或朋友圈，比单独装一个App要顺畅得多。
另外，儿童走失信息有很强的时间敏感性和地理敏感性。一个孩子走失，前24小时是最关键的搜索窗口，所以系统不能只是简单地展示信息，还需要做到：信息按时间倒序、支持按地区筛选、能标注走失地点、能记录线索、能统计进展。这样就倒逼我思考业务模型，而不是写死几个CRUD接口。
还有一点，这类题目在答辩时容易讲价值：它可以为公益组织、社区、学校提供信息协同工具，也可以作为警民联动的一个补充渠道。当然，不涉及具体执法流程，只做信息发布和线索汇总，边界清楚，不会触碰敏感内容，论文也好写。
1.2 核心需求速览：家长、志愿者、管理员三个角色
我梳理需求时，没有照抄常规的“用户/管理员”两角色，而是拆成了三类使用者，这样功能边界更清晰：
- 家长/家属：发布走失儿童信息，包括孩子的姓名、年龄、体貌特征、走失地点、走失时间、照片等；查看线索反馈；确认已找到后关闭信息。
- 志愿者/普通用户：浏览走失信息，按城市或距离筛选；上报自己看到的线索（文字+图片）；收藏关注某条信息，方便后续持续跟进。
- 管理员：审核发布的走失信息，防止虚假信息；管理用户；管理公告；对结案信息进行归档。
这个角色划分直接决定了数据库表结构。用户表、走失信息表、线索表、收藏表、公告表，一张都不能少。而且从“用户”到“家属”再到“志愿者”，并不是强身份绑定，而是“谁都可以浏览，只有当发布信息时才登记为家属联系人”，这样降低了使用门槛。真正需要严格权限的是管理员后台，小程序端不开放管理功能。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型：从微信小程序到后端框架的取舍
2.1 微信小程序端：原生还是uni-app
小程序端我最终选择了微信原生开发，没有用uni-app。原因很直接：毕业设计需要交代微信登录、wx.request、getUserProfile这些原生平台能力，用uni-app虽然能跨端，但答辩时老师会追问“这套逻辑在微信端是怎么运行的”，不如直接看原生代码清晰。另外原生小程序包体积小，启动速度快，调试时直接看微信开发者工具的报错就行，不用额外处理跨端兼容。
如果你已经熟悉Vue，选uni-app也没问题，后台管理系统如果也用uni-app，可以前后台共用组件。但我个人建议：毕设项目尽量“少一点魔法，多一点直白”，原生写法反而更容易解释清楚。
2.2 后端框架与数据库设计
后端我选了 Spring Boot 2.7 + MyBatis Plus + MySQL 8.0，JDK用的1.8。这套组合很经典，网上资料多，遇到问题基本都能搜到解决方案。如果不想用Java，也可以换成Node.js + Express或Python + Flask，逻辑都一样，但Spring Boot的生态更适合体现工程化能力。
数据库设计我花了不少时间。最初想得很简单：一张走失信息表，字段全往里面塞。后来发现不行，因为“线索”和“走失信息”是一对多关系，图片字段也不能简单拼成一个字符串。最终拆了5张核心表：
user：用户表，id, openid, nickname, avatar, phone, create_timemissing_info：走失信息表，id, user_id, child_name, gender, age, height, features, missing_time, location_desc, longitude, latitude, photo_url, status, audit_status, create_timeclue：线索表，id, missing_id, user_id, content, photo_url, contact, status, create_timefavorite：收藏表，id, user_id, missing_id, create_timenotice：公告表，id, title, content, create_time
其中missing_info表的status字段我用0、1、2表示“寻找中”“已找到”“已撤销”，audit_status用0、1、2表示“待审核”“审核通过”“审核拒绝”。这两个状态分开很重要，因为“审核通过”不代表“已经找到”，如果只用一个字段，管理员审核后就无法描述寻找状态了。
2.3 为什么不用纯云开发
微信云开发这两年很火，不用自己买服务器，还自带云数据库和云存储。但我最后还是放弃了云开发。原因有三个：第一，毕设论文需要有“系统设计”章节，纯云开发会让后端设计单薄，写不出几千字；第二，MyBatis Plus、Maven、Redis这些技术栈是面试常问的，基于自建后端更能展示能力；第三，本地运行不受云开发环境配额限制，不用绑定时长。所以我采用“自建后端 + 小程序前端”的经典架构，源码拿到手后，只要本地有MySQL和JDK就能跑。
3. 系统整体设计：从需求到模块拆解
3.1 功能模块全景
整个系统可以拆成小程序端和后台管理端两部分。小程序端面向普通用户，后台管理端面向管理员。
小程序端功能：
- 首页：走失信息流，支持按地区、按状态筛选，下拉刷新和触底加载分页。
- 发布走失：表单填写儿童信息、上传照片、选择走失地点（地图选点）。
- 线索详情：进入信息详情页，查看基本信息、评论区线索、上报新线索。
- 我的：查看我发布的走失信息、我的收藏、我的线索记录、系统公告。
- 登录：微信授权登录，绑定手机号。
后台管理端我直接做成了Web页面，用Thymeleaf模板加Bootstrap，没单独拆前端工程。对毕设而言，这样做省成本，而且能验证后端模板渲染能力。管理端功能：
- 走失信息审核：通过/拒绝，拒绝时填理由。
- 用户管理：查看用户列表，禁用异常账号。
- 线索管理：查看所有线索，标记有效/无效。
- 公告发布：发布寻人公告或系统公告。
- 数据统计：按月份统计走失信息发布数、已找到数。
3.2 数据表设计与核心字段
我建表时有一个习惯：所有表都带create_time和update_time，并用MyBatis Plus的自动填充来维护，这样后面写统计接口会很方便。下面给出几个关键字段的设计说明：
missing_info表的longitude和latitude是必须的。刚开始我只存了文字描述“某某商场东门”，但做“附近寻人”功能时发现没法按距离排序，后来补上了经纬度字段。地图选点用的是微信小程序的wx.chooseLocation接口，用户在地图上点一个点，就能拿回经纬度和地址名，后端存字符串地址加两个浮点字段，实现起来不难，效果却很明显。
clue表的status用0、1、2表示“新线索”“已核实”“已无效”。线索提交后，发布者和管理员都能看到，管理员可以标记线索是否有效。这里注意：线索不需要审核，因为寻人过程中线索是越多越好，就算有些信息不准确，也应该让家属看到，再由人工判断。
图片上传我选择了后端接收wx.uploadFile上传的文件，然后存储到本地目录，同时把访问路径写入数据库。生产环境一般会存对象存储，但毕设直接存本地磁盘没问题。只是要记得在小程序端配置uploadFile合法域名，或在开发者工具里关闭域名校验，否则真机会失败。
3.3 接口设计与小程序端路由规划
我习惯先列接口清单再写代码，避免写到一半发现漏接口。核心接口如下：
POST /api/user/login：code换openid，保存用户信息GET /api/missing/list：分页查询走失信息，支持城市关键字和状态筛选GET /api/missing/detail?id=：走失信息详情，包含线索列表POST /api/missing/add：发布走失信息POST /api/missing/updateStatus：更新寻找状态，如已找到POST /api/clue/add：上报线索GET /api/clue/list?missingId=：查询某条信息的线索列表POST /api/favorite/add、POST /api/favorite/remove：收藏与取消GET /api/notice/list：公告列表
小程序端页面文件上，我按目录分成了pages/home、pages/detail、pages/release、pages/my、pages/notice，公共请求封装在utils/request.js里。这样的好处是后面做权限控制时，只需要在请求拦截器里统一加token即可。
4. 核心功能实现：从儿童信息登记到一键求助
4.1 微信登录与用户体系
微信小程序的登录流程是：wx.login拿到临时code，然后后端拿着code去https://api.weixin.qq.com/sns/jscode2session换openid。openid是用户在小程序里的唯一标识，我用它作为登录凭证的基础。
我封装了一个登录接口，返回一个自定义token（可以用UUID加用户id生成，也可以引入JWT），小程序端把token存到wx.setStorageSync里，后续每个请求都在header里带上。这里踩过一个坑：wx.login拿到的code有效期只有5分钟，而且只能用一次，所以一定要在需要登录时才调用，不能缓存code。
代码大致长这样：
java复制@PostMapping("/login")
public Result login(@RequestBody LoginRequest req) {
String url = "https://api.weixin.qq.com/sns/jscode2session?appid="
+ appid + "&secret=" + secret + "&js_code=" + req.getCode()
+ "&grant_type=authorization_code";
String result = restTemplate.getForObject(url, String.class);
JSONObject json = JSONObject.parseObject(result);
String openid = json.getString("openid");
// 查数据库，如果没有则插入新用户
...
}
4.2 走失信息发布与图片上传
发布页的核心是三个部分：基础信息表单、图片上传、地图选点。
图片上传不能直接把本地图片路径传给后端，小程序后台是拿不到本地真实路径的，必须用wx.uploadFile传到服务器。我在发布页做好表单校验后，先把图片一张一张传上去，拿到图片URL，再连同其他字段一起提交给/api/missing/add。这里推荐前端先传图片，后提交表单，因为如果表单提交成功但图片传输失败，会出现“有信息没照片”的残缺数据。
照片我控制最多传6张，第一张默认作为列表封面。服务端需要给这些图片生成随机文件名，防止重名覆盖。我用的方法是：
java复制String ext = originalFilename.substring(originalFilename.lastIndexOf("."));
String newName = UUID.randomUUID().toString().replace("-", "") + ext;
4.3 基于地图的附近走失提醒
这个功能是后期加的，却是答辩时最亮眼的部分。实现思路是：每条走失信息都存了经纬度，用户打开首页时，小程序通过wx.getLocation拿到自己的经纬度，传给后端，后端用Radius搜索计算出附近几公里内的走失信息。
计算距离的SQL不能直接用sqrt太简单，因为地球是圆的。我用了Haversine公式的简化版，在MySQL里用ST_Distance_Sphere函数，一行SQL就能按距离排序：
sql复制SELECT *, ST_Distance_Sphere(point(longitude, latitude),
point(#{lng}, #{lat})) AS distance
FROM missing_info
HAVING distance < 5000
ORDER BY distance
LIMIT 20
ST_Distance_Sphere返回的是米，所以distance < 5000就是5公里内。这个函数在MySQL 8.0里可以用，5.7需要装插件，建议直接上8.0。注意：调用wx.getLocation需要在小程序后台申请权限，并且要填写使用说明，否则审核会驳回。
4.4 线索上报与认领状态流转
线索上报是一个很能体现“业务完整性”的功能。用户看到走失信息，觉得见过这个孩子，就可以点“上报线索”，填文字、传照片，后端记录到clue表并关联到missing_id。管理员在后台看到线索后，可以标记“核实中”或“无效”。发布者在小程序端“我的发布”里也能看到每条线索的联系方式——注意联系方式不能直接明文展示给所有人，否则会被恶意用于骚扰，我在线索表里加了一个contact字段，只有发布者和管理员能看到。
状态流转我设计了这样一个闭环：
- 发布信息后，状态为“寻找中”。
- 如果有人提供线索，状态不变，线索状态变成“新线索”。
- 家属确认线索有效，可以更新线索状态，但不影响主信息状态。
- 孩子找到后，家属点击“确认已找到”，主信息状态变为“已找到”。
- 管理员复核后，这条信息在首页展示时会带“已找到”标签，并归档。
这个流程写清楚后，论文里的“业务流程设计”章节就非常扎实了。
5. 后台管理端：让系统真正“可运营”
毕设如果只做小程序端，答辩时会被问“怎么保证信息真实性”，所以后台管理端不是可有可无，而是整个系统的信任基石。我做的后台是Spring Boot + Thymeleaf + Bootstrap，所有页面需要管理员账号登录后才能访问，用拦截器做权限校验。
管理端首页放统计卡片：总注册用户数、总走失信息数、寻找中数量、已找到数量。下面是一个简单的发布趋势图，我用的是ECharts，后端返回按月统计数据，前端填充图表。ECharts引入很方便，但对毕设来说不是必须，如果你时间紧，用表格展示也可以。
审核列表是后台的核心页面。管理员能看到每条待审核信息的完整字段，包括照片、走失地点、描述。通过就改audit_status为1，拒绝就填理由，用户可以在小程序“我的发布”里看到拒绝原因。这一步做扎实了，整个系统的社会可信度就有了基本保障。
另外，我还给后台加了一个“线索管理”页面，把所有线索按最新时间倒序展示，管理员可以输入备注，方便同步给线下志愿者团队。这个功能其实是从实际寻人志愿者的工作流程里学来的：线上线索必须有人工核实，系统能做的是把信息和线索汇总清晰，减少人工沟通成本。
6. 实操过程：本地跑通项目的完整步骤
6.1 环境准备与项目导入
如果你拿到的是源码，按下面这套流程跑，顺序不要乱：
- 安装JDK 1.8，配置
JAVA_HOME环境变量。 - 安装Maven 3.6+，配置国内镜像，不然下载依赖很慢。
- 安装MySQL 8.0，创建一个数据库，比如
missing_child，然后把项目里的sql文件导入。 - 导入后端工程到IDEA，等Maven下载依赖。
- 修改
application.yml里的数据库账号密码、文件上传目录、小程序appid和secret。 - 启动后端项目，看到“Started Application”就说明后端起来了。
前端小程序部分：
- 打开微信开发者工具，选择“导入项目”。
- 把项目根目录下的
miniapp目录导入进去。 - 修改
utils/config.js里的后端接口地址，本地调试时用http://localhost:8080，真机预览需要改成局域网IP或HTTPS域名。 - 在详情里勾选“不校验合法域名”，否则本地请求后端接口会被拦截。
- 编译运行，先用
wx.login登录一次，数据库用户表里应该会多一条记录。
6.2 常见运行问题
首跑最容易出问题的是图片无法上传。排查思路是：先看后端控制台有没有报错，如果有上传目录权限异常，就手动创建配置的upload.dir目录；如果前端控制台报uploadFile:fail，多半是域名没有配置或IP不对。还有就是图片URL存储时，我存的是“相对路径”，前端展示时拼接baseUrl + photoUrl，这样换服务器时不用改数据库。
另一个问题就是微信登录失败。检查点有三个：appid和secret是否匹配；小程序是否绑定正确的AppID；后端是否配置了服务器域名或关闭了校验。如果是本地调试，不用配服务器域名，但真机预览时必须把后端接口域名加到小程序后台的request合法域名里，而且必须是HTTPS。如果暂时没有HTTPS证书，可以用开发工具的“真机调试”模式，或者用内网穿透临时调试。
我还遇到过一个很隐蔽的问题：MySQL的point类型列在MyBatis Plus插入时容易报类型不支持的错。我的解决方案是，表里不直接用point类型，而是拆成longitude和latitude两个double字段，查询距离时才用函数计算。这样既规避了类型转换问题，也使数据可读性更高。
7. 常见问题与调试记录
这个小节我把实际开发中遇到的高频问题整理成了一张速查表，方便你排查：
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 登录接口返回400 | code已使用或过期 | 重新调用wx.login，不要缓存code |
| 小程序请求后端报“url not in domain list” | 不在合法域名列表 | 本地调试关闭域名校验，真机配置HTTPS域名 |
| 图片上传失败，报“network error” | 后端地址不可达 | 检查IP端口，确认后端启动，关闭防火墙 |
| 数据库插入数据中文乱码 | MySQL字符集不对 | 建库时使用utf8mb4，连接串加参数 |
| 地图选点无法打开 | 未配置requiredPrivateInfos |
在app.json里配置permission和requiredPrivateInfos |
| 列表数据不刷新 | 分页参数未带 | 检查page和size参数，后端排序用create_time desc |
| 已找到状态无法修改 | 接口权限未做 | 确认发布者token是否匹配信息user_id |
除了表格，我再分享一个经验：调试接口时不要只看小程序控制台，后端日志才是关键。我在项目里加入了logback，每次请求都打印入参和出参，一旦前端传参类型不对，日志里会直接显示字段为null。这个习惯帮我省下了大量对照JS和Java类型的时间。
另外一个容易被忽略的问题是并发保存。用户连续点击“发布”按钮，可能会生成两条重复信息。我在前端加了一个submitting标志，后端也做了一个简单校验：同一个user_id在10秒内不能重复发布相同child_name的信息。毕设阶段不用上Redis分布式锁，用数据库查询加时间判断就够了。
8. 写在最后：毕设之外，这套系统还能怎么延伸
项目做完交上去，导师说了一句话让我印象很深：“你这套东西，再往前走一步就是一个公益产品了。”确实，现在的版本还有很多可以扩展的地方。
比如可以接入AI人脸比对，用户上传失踪儿童照片后，系统自动比对志愿者上传的疑似线索照片，降低人工比对成本。又比如可以增加志愿者定位打卡功能，让线下搜索队伍在系统里标记搜索区域，避免重复搜寻。再比如可以做走失信息联动发布，一条信息生成后，自动同步到公众号模板消息或短信通知附近志愿者。
但如果只是毕业设计，我的建议是不要过度堆功能，先把现有的闭环跑通、论文写清楚，比加十个半成品功能都强。这套系统的核心价值在于“信息透明、流转顺畅、责任明确”，你在做的时候始终围绕这三条主线去设计功能，论文和答辩都不会差。
最后再分享一个我做毕设的小技巧：把每一步的开发记录都写成周记，哪怕只有几句话，截图保留下来。答辩时老师问“你遇到什么困难”，你能直接翻出当时踩坑的记录，比临时编一个真实得多。走失儿童管理系统这个题目，技术难度适中，社会意义明确，只要把细节做扎实，就是一个很拿得出手的毕业设计。