每年毕业季，计算机专业的毕设选题里有一批“老熟人”：商城、食堂订餐、图书馆预约、健身房管理。这些不是不能做，但答辩撞车率实在太高。今天聊的这个题目，光看名字就跟别人拉开差距了——基于小程序的水上警务通设计与开发。我第一反应是，这不是一个普通的CRUD堆砌，背后藏着一套有真实行业背景的业务场景：水上执法巡逻、任务派发、现场事件上报、船舶信息登记、巡逻轨迹记录。这类偏行业+移动端+位置服务的题，认真做下来，答辩时老师想考察的点基本全都能覆盖。
这篇文章我从零开始把这个项目拆一遍。从业务怎么理解、技术选型为什么这么定、数据库怎么设计，到核心功能怎么实现、LW文档怎么写才能跟源码呼应，再到调试联调时那些绕不开的坑，全部按实际开发顺序走。无论你是正要选这个题的学生，还是想蹭这个思路做方案的程序员，照着这条线走，能省下大量瞎琢磨的时间。
1. 这个选题到底在做什么——业务与场景拆解
1.1 水上警务的业务特征决定了它必须“移动优先”
先别急着打开IDE，把业务想清楚比写代码重要得多。水上警务和普通陆地勤务最大的区别是什么？现场不固定。执法队员在水上巡逻时，人在船上、在码头、在锚地，不可能像办公室一样坐在电脑前处理工作。传统模式里，巡逻情况靠纸质记录、现场问题靠电话上报、船舶信息靠对讲机询问，信息链路长、实时性差、后期整理工作量大。
所以这个系统的核心价值就一句话：把巡逻、上报、查询这些动作全部塞进手机里，让一线人员在水上就能完成任务闭环。这跟普通小程序商城有本质区别——商城解决的是“随时随地购物”，警务通解决的是“随时随地执法记录”，数据敏感度、流程严谨度、异常处理要求完全不是一个量级。理解了这一点，后面设计功能模块时就不会跑偏。
1.2 为什么是小程序而不是App
一个很实际的问题：执法场景为什么不用原生App？这里有几个决定性因素。第一，免安装。微信小程序扫码即用，指挥中心给队员下发体验版或者内部版，不需要走应用商店审核、不需要考虑Android和iOS两套包。第二，更新无感。后端接口改了，小程序端代码在微信后台更新，队员下次打开就是新版本，在项目演示和答辩场景里，这一点能让你的系统长期保持“最新状态”，不用反复装机。第三，微信生态能力齐全，定位、地图、拍照、上传、消息订阅这些移动端需要的核心能力，小程序都有现成API。
当然App也有它的优势，比如后台保活、系统级权限更深，但作为毕设或者一个轻量级业务工具，小程序是性价比最高的载体。这个判断在方案里写清楚，答辩时老师问“为什么不做App”，你就能给出有理有据的回答。
1.3 这个题目适合什么人、能锻炼什么能力
如果你现在大三、大四，正在纠结选题，我直接说结论：这个题目的难度曲线非常合适。它没有特别冷门的技术，但涉及的面很全——小程序端开发、后端接口设计、数据库建模、位置服务处理、文件上传存储，一套下来相当于把Web开发的主要环节都摸了一遍。对于将来想找全栈或者后端方向工作的同学，这是一块很好的敲门砖。对已经有工作经验的人来说，这个思路也可以直接迁移到其他移动巡检类项目上，本质都是“任务+轨迹+上报”的模型。
2. 技术选型与系统架构——每个选择都要能说出理由
2.1 小程序端：原生还是UniApp
小程序端有两条路：微信原生小程序和UniApp跨端框架。我见过不少同学一上来就上UniApp，理由是“以后还能打包App”，但对这个项目来说原生小程序是更稳的选择。
原因有三。第一，项目只要求微信小程序，根本没有多端需求，UniApp的跨端优势发挥不出来，反而多了一层编译和兼容性风险。第二，原生小程序的调试体验最好，开发者工具里WXML、WXSS、JS的报错信息直接，map组件、定位API这些核心能力都是微信原生的，文档最全，踩坑时搜到的解决方案最多。第三，毕设时间本就紧张，用最少的技术栈做透一个场景，比堆一堆框架最后到处都是半吊子强得多。
如果你导师非要你体现跨端能力，那就再考虑UniApp。否则我的建议就一个：别自找麻烦，原生微信小程序足够。
前端核心API这块，我列几个你一定会用到的：
- wx.getLocation / wx.chooseLocation：获取当前位置、选择位置，用于巡逻打卡和事件上报
- wx.uploadFile：上传图片到服务端
- wx.request：调用后端接口
- wx.setNavigationBarTitle：动态设置页面标题
- wx.onAppHide / wx.onAppShow：监听小程序前后台切换，控制轨迹记录暂停与恢复
- wx.getMenuButtonBoundingClientRect：自定义导航栏时计算顶部高度
2.2 服务端：为什么默认Java Spring Boot
作为毕设选题，后端最主流的选择就是Spring Boot。虽然技术上用Node.js、Python Flask也能做，但考虑到LW文档写作、答辩讲解、资料查全率三个维度，Spring Boot的优势太明显了：网上相关教程海量，MyBatis Plus让数据库操作非常省事，统一的MVC分层结构写出来像模像样，导师看着也熟悉。
我建议的版本组合：Spring Boot 2.7.x + MyBatis Plus 3.5.x + MySQL 8.0 + Redis 5.x。不要刻意追新用Spring Boot 3，它对JDK版本有硬性要求（JDK17），如果本机环境不熟，反而给自己埋坑。2.7版本成熟稳定，资料多，随便搜什么问题都有答案。
Redis在这里不是摆设，有两个实际用途：一是存登录token，实现有效的会话管理；二是缓存系统参数和热点数据，比如船舶类型字典、任务状态枚举。业务量不大，但用了Redis，文档里可以理直气壮地写“基于缓存的数据访问优化”。
2.3 系统架构与统一的接口约定
整体架构分三层：
- 小程序端：负责交互展示、定位采集、拍照上传
- 服务端：负责业务逻辑、权限控制、数据持久化
- 管理后台Web端：负责任务下发、事件处理、数据统计（毕设里可以做成一个简单的Vue后台页面）
接口设计上，从第一个接口开始就要统一规范。所有接口返回统一的数据结构，前端拿到后按code判断逻辑。我在项目里习惯这样定：
{ "code": 200, "message": "success", "data": {} }登录态用token解决，在请求头里加一个Authorization字段，后端用拦截器校验。拦截器放行登录接口，其余接口全部校验token，未登录或过期直接返回401。这套机制在LW文档里写出来很清楚，答辩时老师问“你怎么控制权限”，你把拦截器结构说清楚就行。
核心接口列表我提前列一张表，开发时照着做就行：
| 模块 | 接口路径 | 说明 |
|---|---|---|
| 登录认证 | /api/auth/login | 用户名密码登录，返回token |
| 巡逻任务 | /api/task/list | 分页查询待办/进行中任务 |
| 巡逻任务 | /api/task/receive | 队员接单 |
| 巡逻打卡 | /api/patrol/record | 上报巡逻打卡点（经纬度） |
| 巡逻轨迹 | /api/patrol/track | 上传/获取巡逻轨迹 |
| 事件上报 | /api/event/create | 上报现场事件 |
| 事件处理 | /api/event/process | 更新事件处理状态 |
| 船籍查询 | /api/ship/info | 按船名精确查询船舶信息 |
| 通知公告 | /api/notice/list | 获取通知列表 |
| 文件上传 | /api/file/upload | 通用图片上传接口 |
3. 需求拆解与数据库设计——业务模型是怎么一步步落地的
3.1 角色设计：两类角色，一条完整闭环
这个系统里有两类角色，别做复杂了。第一类是巡逻队员，使用小程序端，核心动线是：查看任务、接单、出发打卡、巡逻、上报事件、结束打卡。第二类是指挥中心管理员，使用Web端，核心动线是：创建巡逻任务、分派给队员、查看队员上报的事件、处理事件、查看统计。
整条业务闭环就是：管理员下发任务 → 队员接单 → 队员巡逻并打卡 → 现场发现问题上报 → 管理员处理验证 → 任务归档。设计功能模块时，始终围绕这条主线走，就不会出现“为了凑功能硬加模块”的尴尬。
3.2 核心表结构：六张表打底，再加三张辅助表
数据库设计是LW文档的重头戏，一定花心思。我按实际项目落地顺序把核心表列出来，每张表都给出必要的字段说明。
用户表，角色字段区分队员和管理员：
CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, real_name VARCHAR(50), police_no VARCHAR(50), role TINYINT COMMENT '1-队员 2-管理员', team_id BIGINT, status TINYINT DEFAULT 1, create_time DATETIME );巡逻任务表，assigned_user_id指向接单队员，area_points存巡逻区域的坐标点集合，status用0/1/2/3表示待接单、进行中、已完成、已取消：
CREATE TABLE patrol_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_title VARCHAR(100), task_desc VARCHAR(500), area_points TEXT COMMENT '巡逻区域多边形坐标集合', assigner_id BIGINT, executor_id BIGINT, plan_start_time DATETIME, plan_end_time DATETIME, status TINYINT DEFAULT 0, create_time DATETIME );巡逻打卡记录表，type区分出发打卡、到达打卡、途经点，经纬度单独存字段，方便后面做轨迹展示：
CREATE TABLE patrol_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT, user_id BIGINT, record_type TINYINT COMMENT '1-出发 2-到达 3-途经', location_lat DECIMAL(10,6), location_lng DECIMAL(10,6), location_text VARCHAR(255), create_time DATETIME );事件上报表，event_type用字典，status从0到2表示待处理、处理中、已处理。images字段存多个图片URL，用逗号分隔即可：
CREATE TABLE event_report ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id BIGINT, reporter_id BIGINT, event_type TINYINT COMMENT '1-疑似违规 2-航道隐患 3-设备故障 4-其他', event_desc VARCHAR(500), images VARCHAR(1000), location_lat DECIMAL(10,6), location_lng DECIMAL(10,6), location_text VARCHAR(255), status TINYINT DEFAULT 0, handler_id BIGINT, handle_remark VARCHAR(255), create_time DATETIME, handle_time DATETIME );船舶信息表，这个表做基础数据维护，队员在小程序里输入船名就能查：
CREATE TABLE ship_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, ship_name VARCHAR(100), ship_type VARCHAR(50), owner_name VARCHAR(50), owner_phone VARCHAR(20), register_no VARCHAR(50), tonnage DECIMAL(10,2), create_time DATETIME );通知公告表不谈。另外加两张辅助表：一张是任务状态变更记录表task_log，记录任务从下发到归档的全部流转历史；一张是消息记录表message_record，用于保存队员端收到的消息通知。这两张表在答辩时讲“业务可追溯、操作有日志”，能体现你的工程意识。
3.3 数据字典与状态枚举：别把魔法值写死在代码里
事件类型、任务状态、记录类型这些字段，前后端要约定好统一的枚举值。我见过很多项目把1、2、3直接写死在对象里，后面需求一变就是灾难。正确做法是在后端定义枚举类，前端通过接口拉取字典，或者至少在小程序里建一个constants文件集中管理。这里多花十分钟，后面整个开发周期都受益。
4. 核心功能实现与难点攻破——这五个问题解决了，项目就成了一半
4.1 水域定位与巡逻打卡：GPS漂移怎么处理
巡逻打卡是这个项目的灵魂功能，但也最容易翻车的地方。水上作业时，定位漂移比城市里严重得多，因为水面反射会干扰GPS信号，你人在河中间，定位却可能飘到岸边。如果打卡逻辑只看当前位置坐标，就会出现“队员在河里巡逻，系统判定他上岸了”的荒唐事。
我的处理方案是三重保障。第一，前端连续采集三次坐标，取平均值再上报，过滤掉瞬时漂移点。第二，后端用射线法判断坐标点是否落在巡逻区域内。巡逻区域是管理员在创建任务时画的一个多边形，后端保存顶点坐标集合，队员打卡时把经纬度传过来，用射线法判断点在不在多边形内，不在就直接拒绝打卡。这一步逻辑简单但效果极好，也容易在LW文档里用流程图展示。第三，轨迹记录时做距离过滤，相邻两个点距离小于5米就丢弃，避免静止时原地抖动产生大量垃圾数据。
射线法的核心逻辑我放在后端工具类里，大致是这样：
public static boolean isPointInPolygon(double pointLng, double pointLat, List<Point> polygon) { int n = polygon.size(); boolean inside = false; for (int i = 0, j = n - 1; i < n; j = i++) { Point p1 = polygon.get(i); Point p2 = polygon.get(j); if ((p1.getLat() > pointLat) != (p2.getLat() > pointLat) && pointLng < (p2.getLng() - p1.getLng()) * (pointLat - p1.getLat()) / (p2.getLat() - p1.getLat()) + p1.getLng()) { inside = !inside; } } return inside; }这块代码在答辩现场直接甩出来，老师一看就知道你是真做了东西，而不是只会调CRUD。
4.2 现场事件上报：图文组合上报链路
事件上报是整个系统里最考察基本功的功能。它的组成是：事件类型选择 + 文字描述 + 现场照片 + 定位信息。前端页面要做成表单结构，事件类型用picker选择器从字典里取，照片用wx.chooseMedia获取后先压缩再上传。
图片上传有个关键细节：小程序真机上wx.uploadFile一次只传一个文件，多图要循环上传拿到URL列表后，再把URL拼到表单里一起提交。很多新手在这里踩坑，想用wx.request一次性把文件传上去，结果发现后端接不到。正确的时序是：先逐个上传图片，拿到返回的URL数组，再连同其他表单项调用wx.request提交完整数据。
图片压缩策略也不能忽略。队员在水上拍照，随手一拍可能就三四兆，直接传会非常慢。我建议用wx.compressImage把图片质量压到80%以内，单张控制在300KB以下，接口响应速度快一个量级。另外在后端要校验文件类型和大小，防止上传非图片文件，这个属于基本安全意识。
4.3 弱网与离线兜底：信号差的地方怎么处理
水上巡逻有个现实问题：河湖航道很多区段信号覆盖不好。如果app一旦断网就罢工，那这个系统在实际场景里根本没法用。所以离线兜底不是加分项，是刚需。
我的做法是前端维护一个待发送队列。队员在现场填写上报内容、拍照后，先检查wx.request是否可用。如果网络请求失败，就把这条记录连同图片本地路径一起缓存到wx.setStorage里，等到网络恢复时统一重发。但这个策略要小心：图片缓存到本地占空间，不能无限囤，我用的是最多缓存10条的策略，超出后强制提示队员“当前处于离线状态，请移至信号良好区域再上报”。这个细节在答辩时讲出来，能体现出你对真实业务场景的思考深度。
另外巡逻轨迹记录要跟小程序生命周期挂钩，这就是wx.onAppHide和wx.onAppShow派上用场的地方。队员正在巡逻中途切到别的App或者锁屏，小程序进入后台，如果还在高频采集定位，不仅费电而且数据无意义。我在切入后台时暂停轨迹采集，回到前台时自动恢复，同时在页面上显示“轨迹采集已暂停”的提示，避免队员误以为还在记录。
4.4 任务流转与消息通知：状态机推动整条业务线
任务状态流转是后端设计的主体逻辑。我把任务状态设计成待接单0、进行中1、已完成2、已取消3，每次状态变更都写入task_log表记录操作人、操作时间和备注。状态机的实现要封装成独立服务，不允许在Controller里随便改status字段，这样才能保证业务规则不被冲垮。
消息通知这里要坦诚说：微信订阅消息有严格的限制，一次性订阅模板发一次就要用户再授权一次，不适合做频繁的任务提醒。在毕设场景里，我更推荐用两种方式配合。一是后端在任务创建时，给队员生成一条站内消息，队员打开小程序在“消息中心”看到；二是配合订阅消息，在任务分配时申请一次订阅授权，管理员下发任务后给队员发一条模板消息。站内消息的轮询逻辑也简单，小程序onShow时刷新一次消息列表就行。
4.5 分页加载与导航栏细节：影响体感的小地方
小程序页面列表的“加载更多”是高频交互，坑也不少。常见错误是onReachBottom触发一次就疯狂请求，前端没有加loading锁。我的写法是在data里维护一个isLoading布尔值，请求开始置true，结束置false，onReachBottom触发时先判断，在加载中就return，同时把pageNo参数正确加一再发起请求。你把这些细节打磨到位了，小程序用起来才跟正常产品一个手感。
动态设置标题也值得提一下。任务详情页进入不同任务时，调用wx.setNavigationBarTitle把标题设为“巡逻任务-某某水域”，而不是所有页面都叫“任务详情”。这个功能一行代码的事，但做与不做，用户体感差别很大。自定义导航栏时，不要硬编码状态栏高度，要动态获取：
const menuButton = wx.getMenuButtonBoundingClientRect() const statusBarHeight = wx.getSystemInfoSync().statusBarHeight不同机型的顶部高度差异很大，硬编码在真机上很容易错位。
5. 源码结构与LW文档的配合——毕设交付的整条链
5.1 前端工程怎么组织，才能显得不业余
小程序端的目录结构要按业务分包，不要把所有页面堆在pages根目录下。我建议这样分：
- pages/login：登录
- pages/task：任务列表、任务详情、巡逻打卡
- pages/patrol：轨迹记录、轨迹回放
- pages/report：事件上报、事件列表
- pages/mine：个人中心、消息中心
每个页面目录下除了四件套（js、wxml、wxss、json），我还习惯加一个service.js文件，专门放这个页面的网络请求方法，页面里的Page对象只负责交互逻辑。这样分层在代码评审和文档书写时都非常舒服，别人一眼就能看出你的代码是有组织的。
5.2 LW文档的六段式结构与图文编号
LW文档（论文文档）是这个项目的另一半工作量。它跟源码是互相佐证的关系：文档里写到的每个设计，源码里都要有对应的实现；源码里做的每个关键点，文档里都要能解释清楚。我带的项目里，文档吃透六个部分就够了。
绪论部分包括研究背景、意义、国内外现状。这一部分注意别写得太虚，把水上执法从纸质化到移动化的演变过程写清楚就行，无必要引用多少篇文献。需求分析部分要画用例图，把巡逻队员和管理员各自的用例列出来，同时给出功能性需求表格。系统设计部分放总体架构图、业务流程图、E-R图，这是老师最爱翻的部分。数据库设计部分列出每张表的字段说明，写清楚字段类型、含义、是否主键、是否外键，就是数据字典。系统实现部分关键页面截图配核心代码，代码不要大段粘贴，挑有代表性的方法讲清楚就行。测试部分包括功能测试用例表和真机兼容性测试结果。
图片编号有个笨但有效的规矩：写文档之前先把所有图片按“图3-1”、“图4-2”这样的格式编好号，正文里引用编号写说明，别等截图完了再回头补，那时候你根本分不清哪张图是哪个功能。所有图插入后统一检查一遍编号是否连续，这个习惯能让你少熬两个夜。
5.3 怎么把“遇到问题”写进文档，成为加分项
LW文档里最容易被学生写崩的是“开发过程中遇到的问题”。大部分人写的是“遇到了一些问题，通过查阅资料解决了”，老师看了等于没看。正确的写法是：问题描述要具体，分析过程要讲思路，解决方案要落到代码。比如写GPS漂移问题，先描述水域巡逻打卡坐标漂移的现象，再分析水面反射导致信号不稳定的原因，最后给出多点采样取平均值加射线法校验的解决方案，配一段核心代码。这样的内容，老师问什么都难不倒你，因为它本来就是真实做出来的东西。
6. 调试、测试与高频坑位排查——上线前必看的实战记录
6.1 本地调试利器：抓包工具怎么用
做小程序开发，前后端联调阶段一定会用到抓包工具。查问题的时候，它能直接看到小程序发出去的实际请求参数和后端返回，判断到底是前端参数错了还是后端逻辑错了。
常用的方式是Charles配合手机代理。设置步骤大致是这样：电脑端开启Charles的SSL Proxying，手机WiFi代理指向电脑IP和端口，安装证书后打开开发者工具的“不校验合法域名”开关，就能在小程序操作时看到链路里的每条请求。
但这里有个关键知识点：抓包工具和证书配置只是开发调试的手段，部署上线时绝对不能依赖“不校验合法域名”这种后门。真正的微信小程序发布要求所有请求域名都配置为HTTPS，并在小程序后台把域名加入白名单。开发阶段可以为了调试方便关闭校验，但这个开关只该出现在你自己的开发者工具环境，不要写死了。
6.2 真机预览与体验版分发：怎么收集试用反馈
小程序开发完，给你的导师、同学试用收集反馈。具体做法就是在微信开发者工具里点“上传”，把代码传到微信后台，然后在“版本管理”里把当前版本设为体验版，生成体验版二维码。别人扫码就能在真机上用。这一步做完，你的“系统可以真实使用”这件事就不是自己说了，而是别人替你说的，答辩时这个分拿得很稳。
真机调试跟开发者工具模拟器完全是两回事。模拟器上定位随便点都行，真机上必须授权、必须真实GPS；模拟器上没有弱网，真机上可能一格信号；模拟器上抖音的API调用跟真机也有差异。所以我强烈建议所有核心功能都走一遍真机，至少要在两台不同品牌的手机上测。
6.3 高频问题速查表
我把这个项目开发过程中最容易踩的坑整理成一张表，按问题、原因、解决办法的顺序梳理，你用到时直接对号入座：
| 问题现象 | 原因分析 | 解决办法 |
|---|---|---|
| 小程序请求接口提示“域名不合法” | 真机上请求域名未配置到后台白名单 | 开发阶段勾选“不校验合法域名”；上线前在微信后台配置HTTPS域名 |
| wx.getLocation一直失败 | 未声明定位用途，或用户关闭了定位权限 | app.json里配置permission字段说明用途；被拒后调用wx.openSetting引导开启 |
| 真机图片上传慢 | 原图太大，没有压缩 | 上传前用wx.compressImage压缩，大小控制在300KB内 |
| 列表加载重复 | onReachBottom触发时无loading锁，或pageNo未递增 | 加isLoading标志位，请求完成再开放下一次加载 |
| 事件上报后图片丢失 | 先提交表单后上传图片，图片URL未入库 | 调整时序：先传图拿URL，再连同表单提交 |
| 任务状态不符 | 多个接口同时改status字段，逻辑混乱 | 状态变更统一走状态机服务，记录task_log |
| 后台收不到订阅消息 | 订阅消息一次有效，用户未重新授权 | 辅助站内消息轮询，订阅消息仅作提醒补充 |
| 数据库连接超时 | 本地MySQL连接数不够或连接池配置过小 | 检查连接池配置，调整最大连接数，注意连接释放 |
6.4 兼容性与性能检查清单
最后收尾前，过一遍这个清单，能帮你避免大量低级问题。
真机测试至少覆盖iOS和Android各一台，重点看定位和上传两个环节的表现。页面滚动和加载更多跑两轮，确认没有重复请求和漏加载。弱网模式用开发者工具的网络模拟功能验证离线暂存是否生效。拍照上传用不同像素的手机试三轮，确认压缩策略有效。任务状态流转连续操作，确认每个按钮在对应状态下可用或者置灰，避免用户瞎点导致数据混乱。
最后再分享一个实际做这类项目的心得。很多同学做毕设，前端堆页面、后端堆接口，看起来功能一大堆，但整体连起来跑一遍就散架了。我自己的习惯是，先花两天时间把主业务闭环走通——管理员建任务、队员接单打卡、上报事件、管理员处理，这个链条通了，再去补通知、统计这类周边功能。核心链路是骨架，功能再多，骨架散了全白搭。水上警务通这个题最大的价值，就是逼着你把这条带有行业特征的业务闭环想清楚，做完之后再回头看，你收获的远不止一个毕设分数。
