微信小程序+Spring Boot警务辅助人员管理系统全栈开发实践

直接干活了，这篇不整虚的。说个现象：每年毕业季前后，"微信小程序"+“管理系统”这种组合需求量巨大，但真正能把一个项目从业务分析讲清楚、代码写明白、论文对得上的内容很少。到处都是拆东墙补西墙的碎片教程，看完还是不知道怎么落地。我最近完整过了一遍一个警务辅助人员管理系统的小程序项目，从需求建模、数据库设计、小程序端功能实现到后期论文撰写和答辩准备，全链路复盘。这篇文章就把整个思路、关键代码、踩坑点和论文写法一次性交代清楚。

这套系统最大的价值在于：它不是一个玩具Demo，而是真正围绕“警务辅助人员”这支队伍的管理场景设计的——人员档案、考勤打卡、任务派发、通知公告、请销假、培训考核、评分管理，全部浓缩在一个微信小程序里。无论你是急着做毕业设计的学生，还是刚接到政务类信息系统开发任务、想做移动端改造的开发者，这篇内容都值得完整看一遍。我会先讲清楚业务和模块设计，再拆技术选型、核心代码实现、真机调试的坑，最后直接告诉你怎么把源码跑起来、论文怎么写、答辩怎么答。

1. 警务辅助人员管理的业务痛点与系统定位

1.1 传统管理模式到底卡在哪

说实话，警务辅助人员这个群体的管理现状，和很多人想象的“信息化办公”差距很大。人员分散在各个驻点、卡口和巡逻片区，班次错开、24小时轮转，身边真正高频接触的就是一部手机和微信群。很多单位目前的真实状态是：

• 人员基本信息在Excel表里，几十个字段维护得乱，更新一个人事变动要层层转发
• 考勤靠签字表或者值班记录本，月末统计费时费力，还容易有补签、代签
• 通知传达靠微信群接龙，“收到请回复”，但总有人漏看、漏回，挨个打电话催
• 任务派发后没人跟踪进度，领导问起来只能翻聊天记录
• 请假申请走纸质单子，人不在现场就拖着
• 培训、考核结果散落在各处，年底评优评先很难拿出统一的数据依据

这些问题不是某个环节的失误，而是整个管理链条没有一个统一的移动端入口。微信小程序恰好是解决这类问题最合适的载体：用户不需要安装客户端，微信里扫一扫或者搜索就能进，学习成本低，还能配合微信的消息触达能力做通知提醒。这也是我为什么认为这个题目的选型方向本身就选对了。

1.2 系统定位与角色权限设计

这个系统的角色分成三类，权限边界非常清晰：

整个权限模型采用RBAC（基于角色的访问控制），用户表、角色表、用户角色关联表三张表搞定。小程序端拿到的登录态里直接带上角色标识，前端根据角色动态渲染TabBar和按钮，后端接口再用拦截器做权限校验。比如普通队员调删除接口会直接被拦截，管理员则正常放行。

1.3 功能模块全景

在源码里，这套系统的功能模块划分是这样的：

• 人员档案管理：警号、姓名、所属单位、岗位、手机号、入职时间、照片等基础信息
• 考勤管理：上下班打卡、打卡地点校验、考勤记录查询、月度统计
• 任务管理：任务创建、指派、接收、进度更新、超时标记
• 通知公告：发布、查看、已读回执
• 请销假管理：请假申请、审批流、销假确认
• 培训考核：培训内容发布、在线答题或考核登记、成绩查询
• 评分评优：月度/季度评分、考核结果归档、优秀人员排名

每个模块看着都不复杂，但合在一起就构成了完整的管理闭环。小程序端用户看到的是“首页 - 考勤 - 任务 - 我的”四个主Tab，管理端用独立的页面承载，通过角色判断是否可见。

2. 技术选型与系统架构：为什么用这套组合

2.1 小程序端用原生的理由

很多人纠结这个项目用uniapp还是原生微信小程序。我的建议很直接：如果项目只要求上微信一个端，而且是毕设或中小型管理系统，直接用原生开发。原因有三：

第一，原生小程序调试链路最短，微信开发者工具里点开就能跑，不用另外搭HBuilderX工程、不用做条件编译，定位报错、查看请求、检查Storage都方便。第二，这套系统的核心功能——定位、登录、订阅消息、扫码——都是微信提供的原生API，原生语法直接调用最省事，框架封装之后反而要多绕一层。第三，网上关于原生小程序踩坑的帖子密度最高，你遇到问题基本都能搜到，这对一个人独立开发非常重要。

当然，如果你需要同时上支付宝小程序或者抖音小程序，那uniapp是合理的，但那是另一套技术路线了，不在这个项目的核心范围内。

2.2 后端与数据库选型

后端用的是Spring Boot + MyBatis Plus + MySQL，这套组合已经是国内中小型管理系统的事实标准。Spring Boot负责提供RESTful API和事务管理，MyBatis Plus负责数据库操作，内置的代码生成器能直接根据表结构生成Entity、Mapper、Service，开发效率非常高。数据库用MySQL 5.7以上版本，表结构简单清晰，事务支持可靠。

会话管理这块没有用传统HttpSession，而是用的JWT（JSON Web Token）。小程序端每次请求都在header里带上token，后端写一个拦截器解析token、校验有效期、把用户信息放进ThreadLocal供业务层取用。这种方案天然适合前后端分离场景，接口无状态，服务端不用维护会话存储，后续如果要把接口开放给其他渠道接入也很方便。

2.3 前端项目结构与接口划分

小程序端的目录结构大概是这样的：

code复制miniprogram/
  pages/
    login/             // 登录页
    index/             // 首页
    attendance/        // 考勤
    task/              // 任务
    notice/            // 通知
    leave/             // 请假
    mine/              // 我的
    admin/             // 管理端页面（按模块拆分）
  components/
    custom-tabbar/     // 自定义TabBar
    user-auth/         // 头像昵称填写组件
  utils/
    request.js         // 请求封装
    auth.js            // 登录态管理
    location.js        // 定位与距离计算
  app.js
  app.json

后端核心接口清单大致是：

接口路径统一以/api开头，返回结构统一为{ code, message, data }，前端request.js里统一做拦截处理。后端Controller只做参数接收和返回，业务逻辑全部下沉到Service层，事务边界也放在Service层管理。

2.4 部署运行的两种模式

开发调试阶段，小程序端直接连接电脑本地启动的后端服务，手机和电脑连同一个局域网，开发者工具里勾选“不校验合法域名”，把后端地址填成http://局域网IP:8080。等项目功能稳定了要发体验版，后端必须部署到云服务器，小程序后台把HTTPS域名配置成合法请求域名，然后上传代码、提交体验版。这个从本地到线上的切换过程，很多人卡在域名校验和HTTPS证书上，第5部分我会展开讲。

3. 核心数据模型与关键业务逻辑

3.1 数据库表结构设计

业务功能最终都落到表上。这个项目的核心表不多，但每张表的设计都直接影响后面开发的复杂度。我挑三张最有代表性的来说。

第一张是用户表。字段不能只存基础信息，还要留出扩展余地：

sql复制CREATE TABLE `sys_user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录账号，默认警号',
  `password` varchar(128) DEFAULT NULL COMMENT '密码（可为空，微信登录用户）',
  `real_name` varchar(50) NOT NULL COMMENT '真实姓名',
  `police_no` varchar(50) NOT NULL COMMENT '警号',
  `unit_id` bigint(20) DEFAULT NULL COMMENT '所属单位ID',
  `phone` varchar(20) DEFAULT NULL,
  `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL',
  `role_id` bigint(20) NOT NULL COMMENT '角色ID',
  `status` tinyint(4) DEFAULT '1' COMMENT '1启用 0禁用',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第二张是考勤记录表。这里把经纬度直接存到了表里，不是为了炫技，而是为了给后续异常申诉和统计留证据：

sql复制CREATE TABLE `attendance_record` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `user_id` bigint(20) NOT NULL,
  `attendance_date` date NOT NULL,
  `clock_type` tinyint(4) NOT NULL COMMENT '1上班 2下班',
  `clock_time` datetime NOT NULL,
  `longitude` decimal(10,6) DEFAULT NULL,
  `latitude` decimal(10,6) DEFAULT NULL,
  `address` varchar(255) DEFAULT NULL COMMENT '打卡地点描述',
  `distance` decimal(10,2) DEFAULT NULL COMMENT '与打卡点距离，单位米',
  `status` tinyint(4) DEFAULT '1' COMMENT '1正常 2迟到 3早退 4外勤',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_user_date` (`user_id`, `attendance_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

第三张是任务表。任务状态放在字段里，配合状态机流转，比单纯存一个“完成/未完成”布尔值可靠得多：

sql复制CREATE TABLE `task_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `title` varchar(200) NOT NULL,
  `content` text,
  `assignor_id` bigint(20) NOT NULL COMMENT '创建人/派发人',
  `assignee_id` bigint(20) DEFAULT NULL COMMENT '接收人',
  `priority` tinyint(4) DEFAULT '0' COMMENT '0普通 1重要 2紧急',
  `status` tinyint(4) DEFAULT '0' COMMENT '0待接收 1进行中 2已完成 3已超时',
  `deadline` datetime DEFAULT NULL,
  `progress_note` varchar(500) DEFAULT NULL COMMENT '进度备注',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_assignee_status` (`assignee_id`, `status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

其他像通知表、请假表、培训考核表、评分表，结构上都是围绕“谁、在什么时间、对什么业务做了什么操作”来设计的，大同小异，不逐一写了。设计表结构时记住一句话：业务查询的维度要预先考虑好，比如考勤记录一定要有user_id + attendance_date联合索引，任务列表一定要有assignee_id + status联合索引，否则数据量上来之后接口会明显变慢。

3.2 考勤打卡的距离校验与时间窗口

打卡是整个系统里技术含量最高的一个模块，核心逻辑分三层：

第一步，小程序端调用wx.getLocation获取用户当前经纬度，参数type指定gcj02坐标系（国测局坐标），因为微信内置地图和大部分国内地图服务都用这个坐标系，直接拿WGS-84原始坐标会导致定位飘移，这个坑后面细说。

第二步，把经纬度传给后端，后端计算与预设打卡点的距离。距离计算用球面距离公式，也就是Haversine公式：

java复制public double distance(double lat1, double lng1, double lat2, double lng2) {
    double radLat1 = Math.toRadians(lat1);
    double radLat2 = Math.toRadians(lat2);
    double a = radLat1 - radLat2;
    double b = Math.toRadians(lng1) - Math.toRadians(lng2);
    double s = 2 * Math.asin(Math.sqrt(
            Math.pow(Math.sin(a / 2), 2) +
            Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2)));
    return s * 6371000; // 地球半径，单位米
}

打卡点可以配置多个（比如机关驻地、执勤点位），后端逐一计算距离，取最小值。只要最小值在允许范围内（比如300米），就判定为“在打卡点附近”，允许打卡。

第三步，判断时间窗口。上班打卡窗口比如6:00-9:00，下班打卡窗口比如17:00-22:00。窗口内打卡正常，超过上班窗口的最晚时间算迟到，早于下班窗口就提交算早退。这些时间参数存配置表，不要写死在代码里，因为不同班组时间不一样，后期改配置比改代码上线要方便得多。

3.3 任务状态机与超时处理

任务模块的逻辑核心是状态机。我设计的状态取值是0待接收、1进行中、2已完成、3已超时。每个状态都有自己的合法流转方向，Controller层接收请求后先判断当前状态是否允许目标操作。比如待接收状态下，接收人只能执行“接收”操作；进行中状态才能提交进度、标记完成。这些判断虽然简单，但没有的话很容易出现“任务还没接收就把进度提交了”这种脏数据。

超时处理用了Spring的定时任务（@Scheduled），每分钟扫一次任务表，把deadline小于当前时间且状态不等于完成和超时的任务批量更新为已超时状态。同时同步一条通知记录给指定人，提醒及时处理。

3.4 请销假审批流

请假单的状态是待审批、已通过、已驳回、已销假。队员提交请假申请后，状态为待审批，负责人审批通过则状态变为已通过，队员返岗后在系统里做销假操作，状态变为已销假。审批结果通过小程序订阅消息推送给申请人，让用户第一时间知道审批结果，不用反复进小程序刷状态。

4. 小程序端关键功能实现与踩坑

4.1 登录态与用户信息获取：这里最容易翻车

这是整个小程序开发中被问得最多的一个问题，甚至相关网络报错的帖子特别多，像是小程序获取登录后的微信用户失败这类报错。很多人第一次写登录，习惯性地在界面上放一个getUserProfile按钮弹窗获取微信头像昵称，结果发现按钮不弹窗了、代码报错了。原因很简单：微信官方调整了用户信息能力——基础库2.27.1以后，getUserProfile返回的匿名信息已经不适合做头像昵称展示，现在推荐用“头像昵称填写能力”，用户在小程序里主动填写或选择微信头像。

所以这个项目里的登录逻辑要分成两段：

第一段是静默登录。小程序端调用wx.login拿到临时code，传给后端，后端拿code调用微信的code2Session接口，换回openid和session_key。openid是微信用户在小程序里的唯一身份标识，直接存到sys_user表，如果用户不存在就自动创建一个账号，这一步就完成了“扫码即登录”。核心代码：

javascript复制// 小程序端
wx.login({
  success: async (res) => {
    const { code } = res
    const loginRes = await request.post('/api/auth/login', { code })
    wx.setStorageSync('token', loginRes.data.token)
  }
})

java复制// 后端
@PostMapping("/login")
public Result login(@RequestBody LoginDTO dto) {
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid +
                 "&secret=" + secret + "&js_code=" + dto.getCode() + "&grant_type=authorization_code";
    String result = restTemplate.getForObject(url, String.class);
    JSONObject obj = JSON.parseObject(result);
    String openid = obj.getString("openid");
    // 查库，不存在则新建用户，然后生成JWT返回
}

第二段是完善资料。如果新用户没有真实姓名和头像，小程序端跳转到资料完善页，使用微信官方开放的“头像昵称填写能力”。具体是页面放一个button的open-type="chooseAvatar"来选头像，昵称用一个input的type="nickname"来输入。这个方法不需要用户授权弹窗，合规且稳定。

遇到登录失败先检查三件事：小程序的AppID和后端配置的AppID是否一致、后端有没有正确配置微信小程序密钥、小程序后台有没有把request合法域名配好。大部分登录失败都是这三个基础问题引起的。

4.2 定位打卡的正确打开方式

先用wx.getLocation拿坐标。这里有两个坑：

第一个坑是坐标系。wx.getLocation支持两种坐标系类型：wgs84（国际标准）和gcj02（国测局加密坐标），不传参数时默认是wgs84。国内地图服务（包括微信内置地图）普遍使用gcj02，如果直接用wgs84坐标计算与打卡点的距离，会有几百米的偏差，正好超过打卡半径，导致明明在打卡点却打不上卡。所以调用时一定要写死type: 'gcj02'，后端打卡点存储的坐标也统一用gcj02，两边一致才不会有偏差。

第二个坑是用户拒绝授权。用户第一次进入小程序时如果拒绝了定位权限，再调用wx.getLocation直接fail。正确做法是：检测到授权被拒绝时，弹一个引导提示，指引用户点击“重新授权”跳转到小程序的设置页（wx.openSetting），让用户手动开启定位权限，而不是什么都不做或者反复弹窗打扰用户。

4.3 列表页的下拉刷新与分页加载

任务列表、通知列表都有翻页和刷新的需求，这里用了小程序原生页面的两个生命周期：onPullDownRefresh和onReachBottom。小程序配置文件里把enablePullDownRefresh设为true，再在页面里监听这两个事件。分页参数统一用pageNum和pageSize，后端用MyBatis Plus的Page对象分页查询，返回给前端的结构是当前页数据加total总条数。翻页时前端把pageNum累加，拉到的数据追加到数组里，避免重复插入。

一个细节：在分页数据追加时，如果用户快速触发多次onReachBottom，会导致重复请求。解决办法是加一个isLoading锁，在请求未返回前不允许新的请求发出。

4.4 订阅消息：审批结果和任务提醒的触达机制

消息触达用的小程序订阅消息。一次订阅只能发一条消息，所以队员提交请假申请时，页面里要调用wx.requestSubscribeMessage让用户勾选订阅“审批结果通知”。用户同意后，后端在审批状态变更时调用subscribeMessage.send接口推送通知。需要注意前端订阅消息是“一次性”的，用户如果拒绝了或者没勾选，这次审批结束就收不到推送，需要在下一次操作时再引导授权。

这块不要搞太复杂。对于这个系统来说，只要在“请假审批通过/驳回”和“任务已超时”这两个场景接入订阅消息就够了，覆盖核心通知场景，又不至于被复杂的模板消息体系折磨。

4.5 自定义TabBar：角色不同看到的菜单不同

普通队员和管理员的TabBar菜单不一样。普通队员是“首页/考勤/任务/我的”，管理员还要多一个“管理”入口。官方TabBar不支持动态变化，所以我用了自定义TabBar方案。

做法是在components目录下写一个自定义TabBar组件，里面用wx.switchTab切换页面，同时在app.json里把tabBar的custom字段设为true，并配置一个自定义TabBar组件路径。每个页面都要在json里注册这个组件。判断角色时，从全局变量或者Store里读用户信息，根据角色动态渲染菜单项，非管理员看不到管理入口。

这里有个容易踩的坑：自定义TabBar模式下，页面切换必须用wx.switchTab，不能用wx.navigateTo，否则TabBar不显示。另外自定义TabBar会挡页面底部，页面内容需要预留底部安全距离。

4.6 页面适配的常见细节问题

顶部导航栏高度：iPhone的刘海屏和非刘海屏状态栏高度不一样，胶囊按钮位置也不同。把高度写死会导致页面布局错位。正确做法是用wx.getWindowInfo()获取statusBarHeight，再用wx.getMenuButtonBoundingClientRect()获取菜单按钮的位置信息，两者相加得出导航栏总高度，动态设置给页面的自定义导航栏。

富文本图片溢出：通知公告里如果用了rich-text组件展示富文本内容，图片默认不受页面宽度约束，很容易超出屏幕。解决方式是把富文本内容里的img标签做一次正则替换，给图片加上max-width: 100%的样式，再传给rich-text渲染。代码就一行正则：

javascript复制html = html.replace(/<img/g, '<img style="max-width:100%;height:auto;" ')

5. 真机调试与体验版发布的坑

5.1 真机预览老连接失败怎么办

最典型的报错是运行真机调试时提示类似net::ERR_CONNECTION_RESET，然后页面白屏、接口全部请求失败。这种情况绝大多数不是代码问题，而是网络环境层面的。

开发阶段后端跑在电脑上，手机预览时访问的是电脑的局域网IP。手机和电脑必须在同一个WiFi下，而且Windows防火墙有可能拦掉来自手机的访问，需要在防火墙里放行后端服务端口（比如8080）。还有一个细节：电脑如果同时连着公司内网和WiFi，手机获取到的电脑IP可能是内网IP而不是局域网IP，要看电脑实际连的网卡IP。

到体验版阶段，后端部署到云服务器，就必须走HTTPS了。微信小程序后台的request合法域名只允许填HTTPS域名，不能用IP也不能用HTTP。商用域名需要备案，自己开发的话可以用容器或者对象存储的域名，配合Nginx挂SSL证书转发到后端服务。

5.2 模拟器正常、真机不正常的差异

最典型的是定位。模拟器里的经纬度可以随便选，但真机上依靠的是手机GPS和基站信息，经常遇到在室内定位跳动、误差大。所以本地开发验证距离判断逻辑时，最好把打卡半径设大一点（比如500米），或者在开发者工具里勾选“模拟定位”来测试。上生产前再把半径调回正常值。

另一个真机和模拟器的差异是请求数据包内容。小程序真机调试时，建议在app.js里做一个环境判断，开发环境输出调试日志、打印请求参数，生产环境关闭日志。用vConsole这个小工具可以在真机上直接看到Console和Network信息，排查请求参数对不上、返回数据解析失败这类问题非常有帮助。

5.3 包体超2MB之后怎么处理

原生小程序主包限制2MB，超过之后无法上传。项目常见超包原因有两个：一是本地图片资源太多，二是引入了体积较大的第三方库。

解决办法第一是图片压缩并转用云存储或对象存储的URL，本地只保留压缩后的缩略图。第二是开启分包加载，把“管理后台”相关页面全部挪进分包目录，小程序启动时只加载主包，用户点击进入管理功能时分包再异步加载。分包配置就在app.json里加一个subPackages字段，把管理页的路径写进去就行。

vConsole和WeUI这类库如果只是某些管理页用，也尽量只在对应分包里引入，不要全局加载。

5.4 调试请求的推荐方式

很多人一上来就想着用抓包工具去看小程序的请求。其实微信开发者工具自带的Network面板已经能看每个请求的URL、请求头、参数、响应数据，基本覆盖日常联调需求。真机上看请求，直接用vConsole就是最方便的，不需要额外搭任何环境，也不会涉及手机代理配置这一层，安全可靠，对学生和一线开发者来说够用了。

排查接口问题的顺序一般是：先看Network面板有没有请求发出、URL和参数对不对、后端有没有收到、返回的状态码和数据结构是不是预期、前端有没有解析异常。按照这个链路走一遍，绝大多数问题都能找到答案。

6. 论文怎么写、答辩怎么答

6.1 论文目录框架

这套系统配套论文的目录，我建议按下面这个框架走：

• 第一章 绪论：研究背景、国内外移动办公系统现状、研究目标和内容、论文结构
• 第二章 相关技术介绍：微信小程序介绍、Spring Boot框架、MyBatis Plus、MySQL、微信登录与订阅消息机制
• 第三章 系统需求分析：可行性分析、角色分析、功能需求（用例图+用例描述）、非功能需求（性能、安全、易用性）
• 第四章 系统总体设计：系统架构图、功能模块划分、数据库E-R图、数据表设计
• 第五章 系统详细设计与实现：登录模块、考勤模块、任务模块、请假审批模块、通知模块的实现，配合核心代码和界面截图
• 第六章 系统测试：测试环境、功能测试用例表、测试结果分析、兼容性测试
• 第七章 总结与展望

这套目录和项目实际开发过程是对应的，论文里写的每一章都等于开发过程的一个环节，不需要额外编造素材，写起来顺畅很多。

6.2 从代码到论文：素材怎么转化

不要小看转化这一步。很多人的代码写得挺完整，但论文写得像“说明书”或者“流水账”，原因就在于只描述了“做了什么”，没有上升到“为什么这么设计”。关键在转换视角：

需求分析章节要画用例图。用例图用什么工具都行，重点是准确覆盖角色和功能：队员能打卡、能看任务、能请假；负责人能派任务、能审批、能评分；管理员能管人管权限。把用例图当成整个系统对外能力的总地图来看。

数据库设计章节要画E-R图。从核心实体出发：用户、角色、考勤、任务、通知、请假、培训、评分，把实体之间的关系画清楚。注意多对多关系（比如用户和角色）要拆成关联表，这在论文里要进行说明。

系统实现章节不要大段贴代码。每个功能模块选1-2段核心代码，配一两张截图，用自然语言说清楚“这段代码实现了什么业务逻辑、解决了什么问题”，截图一定用真机或者模拟器跑出来的实际效果，不要贴设计图。

6.3 答辩高频问题与准备要点

答辩时老师最爱问的问题集中在几个点：需求来源是否真实、技术选型理由、安全性如何保证、工作量亮点在哪儿。我列几个高频问题，你可以提前准备：

• 为什么用微信小程序而不是APP？答：无需安装、跨平台、触达方便，微信生态自带登录和消息能力，对目标用户群体学习成本低。
• 考勤打卡的定位如何防止作弊？答：前端使用gcj02坐标，后端根据经纬度计算与打卡点距离，超出范围判定无效；历史数据保留原始定位，用于事后审计。
• 系统如何保证数据安全？答：后端接口统一JWT校验，管理端操作权限由角色控制，密码由BCrypt加密存储，小程序请求通过HTTPS传输。
• 这套系统还有什么可以扩展？答：人脸识别打卡、排班管理模块、数据可视化大屏、与企业微信集成等。
• 项目里哪个模块最有挑战？答：考勤模块的定位校验和状态流转是核心，需要仔细处理坐标系、授权、时间窗口等细节。

答辩的核心思路是：把项目当成一个完整的工程项目来展示，而不是“写了个小程序”。这就意味着需求分析、设计、实现、测试每个环节都得有拿得出手的素材，靠表格、图和测试用例说话。

7. 源码跑通与二次开发方向

7.1 拿到源码之后怎么快速启动

完整的源码拿到之后，不要急着看代码，先把环境跑通。前后端分离项目，启动步骤是固定的：

后端部分：修改application.yml里的数据库连接配置为本机MySQL地址和密码，创建数据库并导入SQL脚本，在IDEA里直接启动Spring Boot主类。启动成功后浏览器访问http://localhost:8080/api/auth/login，能看到JSON返回就算启动成功。

小程序部分：用微信开发者工具导入miniprogram目录，在project.config.json里把appid改成自己的测试号或者注册好的小程序AppID。后端本机地址如果改了端口或路径，在utils/request.js里同步修改baseURL。此时在开发者工具里点编译，就能看到登录页和首页了。

后端联调的关键点是先确认登录接口能通，再测试需要登录态的接口。登录成功后在开发者工具的Storage里能看到token字段，后续所有接口都会自动携带，正常用就不用管了。

7.2 源码目录结构速览

后端通常按标准Maven项目组织：controller放接口入口，service放业务逻辑，mapper放数据库操作，entity放实体类。小程序端结构在2.3节已经列过。配套文档（如果有论文和SQL脚本）一般单独放doc目录。拿到源码后先花半小时把目录结构过一遍，心里有个地图，后面改代码会顺手很多。

7.3 可以继续做的扩展点

如果这个项目作为毕设，想拿高分，或者你后续要把它落到真实场景里使用，有几个扩展方向值得投入：

一是打卡防作弊增强。当前的距离校验已经能挡住大部分“远程打卡”，但防不了“他人代打”。可以接入微信的实时人脸核身能力，打卡时做人脸比对，或者要求拍照上传，后端保存现场照片。

二是排班管理。目前系统没有排班概念，考勤窗口是全局配置的。引入排班模块后，可以按人、按岗位生成周/月排班表，考勤规则自动匹配对应班次，统计报表也能按班次纬度汇总。

三是数据可视化。在管理端加一个统计面板，用ECharts展示出勤率、任务完成率、培训通过率等核心指标，从表格数据变成图表看板，管理层使用的体验会提升一个档次。

四是通知与报表再往里推一步。当前订阅消息覆盖的是审批和任务提醒，可以把月度考勤异常名单、考核成绩推送也加进来。报表导出方面，后端用EasyExcel直接把月度考勤明细导出成xlsx，管理员在电脑端下载和归档都很方便。

我在把这个项目完整跑通的过程中最大的体会是：做这类管理系统，技术本身没有太多高难度的地方，难的是把业务场景理解透、把边界条件想清楚——比如打卡半径、任务超时判定、权限粒度这些细节，每一个不到位，实际用起来就总有别扭的地方。如果你是第一次做小程序全栈项目，我的建议是先别急着加功能，把“登录-打卡-任务列表”这条核心链路从前到后跑通，再逐步往上面叠加模块。核心链路稳定了，整个项目的骨架就立住了，其余都是往上面填肉的事情。希望这篇复盘能帮你少走几段弯路，这套双端加论文的组合能顺利落地。