尧图网站建设 
每年毕业季计算机专业的毕设选题里有一批“老熟人”商城、食堂订餐、图书馆预约、健身房管理。这些不是不能做但答辩撞车率实在太高。今天聊的这个题目光看名字就跟别人拉开差距了——基于小程序的水上警务通设计与开发。我第一反应是这不是一个普通的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, ListPoint 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结束置falseonReachBottom触发时先判断在加载中就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各一台重点看定位和上传两个环节的表现。页面滚动和加载更多跑两轮确认没有重复请求和漏加载。弱网模式用开发者工具的网络模拟功能验证离线暂存是否生效。拍照上传用不同像素的手机试三轮确认压缩策略有效。任务状态流转连续操作确认每个按钮在对应状态下可用或者置灰避免用户瞎点导致数据混乱。最后再分享一个实际做这类项目的心得。很多同学做毕设前端堆页面、后端堆接口看起来功能一大堆但整体连起来跑一遍就散架了。我自己的习惯是先花两天时间把主业务闭环走通——管理员建任务、队员接单打卡、上报事件、管理员处理这个链条通了再去补通知、统计这类周边功能。核心链路是骨架功能再多骨架散了全白搭。水上警务通这个题最大的价值就是逼着你把这条带有行业特征的业务闭环想清楚做完之后再回头看你收获的远不止一个毕设分数。 基于小程序的水上警务通：设计与开发全解析
每年毕业季计算机专业的毕设选题里有一批“老熟人”商城、食堂订餐、图书馆预约、健身房管理。这些不是不能做但答辩撞车率实在太高。今天聊的这个题目光看名字就跟别人拉开差距了——基于小程序的水上警务通设计与开发。我第一反应是这不是一个普通的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, ListPoint 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结束置falseonReachBottom触发时先判断在加载中就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各一台重点看定位和上传两个环节的表现。页面滚动和加载更多跑两轮确认没有重复请求和漏加载。弱网模式用开发者工具的网络模拟功能验证离线暂存是否生效。拍照上传用不同像素的手机试三轮确认压缩策略有效。任务状态流转连续操作确认每个按钮在对应状态下可用或者置灰避免用户瞎点导致数据混乱。最后再分享一个实际做这类项目的心得。很多同学做毕设前端堆页面、后端堆接口看起来功能一大堆但整体连起来跑一遍就散架了。我自己的习惯是先花两天时间把主业务闭环走通——管理员建任务、队员接单打卡、上报事件、管理员处理这个链条通了再去补通知、统计这类周边功能。核心链路是骨架功能再多骨架散了全白搭。水上警务通这个题最大的价值就是逼着你把这条带有行业特征的业务闭环想清楚做完之后再回头看你收获的远不止一个毕设分数。