简介针对企业实习生招聘、培训、考勤和评估等环节的管理需求这份微信小程序实习生管理系统源码资源包可帮助开发者快速搭建完整的移动端管理方案。资源共6个文件压缩包约28MB核心为基于Spring Boot的整站源码、db.sql数据库脚本以及技术文档与毕业论文配套的docx和doc文件对系统结构、数据库表关系和功能实现流程做了详细说明。前端采用微信小程序原生框架涵盖WXML、WXSS、JavaScript等核心组件后端以Spring Boot为主涉及API接口设计、数据库与业务逻辑处理代码结构清晰、注释详尽。学习此资源可掌握小程序前后端联动开发的全流程也能借助论文理解系统的选题背景、设计理念和架构为课程设计或毕业设计提供参考。目前已有99人浏览学习适合需要复现完整项目、快速上手小程序开发或准备毕业设计的开发者作为学习素材。1. 实习生管理系统小程序压缩包里不只有代码还有一条完整全栈链路「实习生管理系统小程序(整站源码sql脚本论文).zip」这类压缩包在毕设和课设场景里很常见一个小程序前端、一个后端工程、一份 SQL 脚本、一篇配套论文。第一次解压的人往往急着找启动教程结果卡在数据库导入报错、openid 换不到、真机请求失败这些地方。我的看法是这套东西能不能跑起来只算及格线真正值钱的是它把实习生管理这条业务线完整串了起来角色权限、任务派发、每日打卡、周报提交、导师评分每个环节都有对应的表、接口和页面。适合读这篇内容的人也明确正在做毕设或课程设计的学生想摸清小程序全栈链路的新手以及想快速搭一套内部实习管理工具的小团队。接下来按我实际调试这类系统的顺序来写——先拆业务和库表再导库启动后端最后打通登录鉴权末尾把高频踩坑点和改造建议列全。2. 拆实习生管理系统业务模块与数据库读论文之前先看 SQL 脚本怎么建表2.1 三类角色与权限边界管理员、导师、实习生这套系统的第一件事是角色划分。常见的做法是管理员、导师、实习生三种不会多也不会少。管理员负责维护部门、导师账号、把实习生分配到导师名下偶尔看一眼全局统计导师负责给名下实习生派任务、审周报、打考勤分、写评语实习生是小程序端最活跃的用户打卡、看任务、交周报、查评分都在这里完成。落到代码上角色通常不建三张用户表而是统一放一张用户表里用一个 role 字段区隔。这样设计的原因很实际三者的登录方式、基础字段完全一致都是姓名、手机号、微信 openid只有业务权限不同。前端拿到登录返回的 role 之后决定进入哪个首页、显示哪些 tab后端在拦截器或过滤器里对 /mentor/、/admin/ 开头接口做角色校验。这里最容易翻车的设计是前端只靠页面隐藏控制权限。小程序包一旦被解开或者请求被直接构造接口就完全暴露了所以角色判断必须以后端为准。我一般会在调试初期打开后端工程的拦截器把接口前缀和免鉴权白名单打印出来看一眼比对着论文里的用例图更直观。常见的白名单只有登录接口和静态资源其余接口都必须从 token 里解析出对应的角色。2.2 从任务下达到评分四个核心流程串起的数据流业务闭环基本是四段。第一段任务下发导师创建任务指定实习生和截止时间实习生在小程序里看到待办第二段每日打卡实习生上班打卡、下班打卡记录时间生成考勤第三段周报提交实习生每周交一篇周报导师查看后给通过或打回第四段评分汇总实习结束时导师给综合评分管理员可以导出汇总。这四段的数据库流向很清晰。任务创建写 t_task打卡写 t_attendance周报写 t_weekly评分写 t_evaluation。每一段都会反写一个状态字段任务从待办变成已完成周报从待审变成已审评分完成后把实习生标记为已结业。状态一般存数字0、1、2 这样的枚举值比字符串好比较、好索引也比布尔值好扩展——比如任务状态要表达待办、进行中、已完成、超时布尔值就做不到。理解这条数据流的意义在于联调定位问题。周报提交后导师端看不到先别急着怀疑推送或者刷新去查 t_weekly 的状态字段是不是没写对或者压根没插入成功。我见过不少类似模拟项目把不同表的状态含义搞混拿任务的 1 去比周报的 1查来查去查不出原因最后发现两个枚举定义根本不一样。2.3 从 SQL 脚本反推业务五张核心表的关系与字段演进拿到 SQL 脚本不要急着跑先把建表语句读完。实习生管理系统最核心的是五张表用户表、实习生表、任务表、考勤表、周报表评分表有些版本单独建有些并进周报表看脚本里实际怎么写的。用户表存公共信息实习生表存实习期专属字段业务表挂在实习生表下面。-- 用户表管理员、导师、实习生统一存储 CREATE TABLE t_user ( id INT NOT NULL AUTO_INCREMENT COMMENT 主键, openid VARCHAR(64) DEFAULT NULL COMMENT 微信openid小程序登录凭据, username VARCHAR(50) NOT NULL COMMENT 账号/工号, password VARCHAR(100) DEFAULT NULL COMMENT 密码可空小程序端走openid, role TINYINT NOT NULL COMMENT 角色1管理员 2导师 3实习生, real_name VARCHAR(50) NOT NULL COMMENT 真实姓名, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这段 DDL 有四个值得留意的参数。openid 用 VARCHAR(64)微信返回的 openid 在 28 到 36 位之间留点余量没坏处role 用 TINYINT 而不是字符串省空间且容易被后端枚举映射username 建了唯一索引这是给管理员和导师做账号密码登录用的实习生如果纯走小程序登录username 可以自动生成字符集选 utf8mb4因为姓名和评语里可能出现中文及表情符号utf8mb3 存不了 emoji。如果脚本里写的是 utf8 或 gbk建议建库时直接改成 utf8mb4后面能少一片乱码的坑。五张核心表的关联关系用一个表就能说清表名关键字段关联关系业务含义t_userid, openid, username, role根表三种角色统一登录t_internid, user_id, mentor_id, departmentuser_id → t_user.id实习生扩展信息mentor_id 也指向用户表t_taskid, title, assignee_id, publisher_id, deadline, statusassignee_id → t_intern.id导师派发任务t_attendanceid, intern_id, work_date, check_in, check_outintern_id → t_intern.id每日打卡记录t_weeklyid, intern_id, week_no, content, audit_statusintern_id → t_intern.id周报与导师审核用户表是根表实习生表是一层扩展业务表全挂在实习生表下面。这样设计的好处是导师离职或者管理员调整角色时只改用户表业务数据不受影响。看字段命名也能看出版本演进痕迹有 openid 说明后来接入了小程序登录有 audit_status 说明审核流是后加的这些细节在答辩时要能讲出为什么。3. 本地跑通最小可运行版本导库、启动后端、拉起小程序3.1 导入 SQL 脚本字符集、版本与导入后的自检导入前先检查两件事脚本开头有没有 CREATE DATABASE以及脚本是按 MySQL 5.7 还是 8.0 写的。带建库语句的脚本直接导入即可不带的话要先手动建库否则所有表可能落到默认库里后端配置连的库名对不上启动直接报找不到表。我推荐手动建库字符集可控后面排查也简单。# 第一步建库显式指定 utf8mb4 mysql -uroot -p -e CREATE DATABASE IF NOT EXISTS intern_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # 第二步导入脚本指定目标库 mysql -uroot -p intern_system intern_system.sql # 第三步自检表数量 mysql -uroot -p intern_system -e SHOW TABLES;导入后的自检别只看有没有报错。报错会当场中断但隐患往往是静默的表数量少了几张、某张表是空表、字段类型和论文描述不一致。所以建议再跑一条SELECT COUNT(*) FROM t_user;如果用户表里连一条管理员初始记录都没有说明这份脚本可能只有结构初始化数据要靠后端启动时自动插入或者自己手动补一条管理员的 INSERT。这一步没做后面登录进不去后台可别急着怪代码。3.2 启动后端服务配置文件的三个必改项后端启动前配置文件里至少有三处要改。第一是数据库连接包含库名、账号、密码和服务时区第二是微信小程序相关的 appid 和 secret第三是可能被占用的端口。以最常见的 Spring Boot 工程为例配置文件长这样server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/intern_system?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8 wx: appid: 你的小程序appid secret: 你的小程序secret逐项说明参数的含义。url 里的 intern_system 必须和建库名一致characterEncodingutf8 是兼容写法配合 utf8mb4 库实际走的是 utf8mb4 编码serverTimezoneAsia/Shanghai 是让 JDBC 拿到本地时间而不是 UTC不配的话后面打卡时间会整体差 8 小时。jackson 的 date-format 和 time-zone 控制后端返回给前端的日期格式统一成 yyyy-MM-dd HH:mm:ss 后小程序端就不用再做字符串拼接转换。wx.appid 和 secret 在微信公众平台的开发设置里取测试阶段可以用测试号但测试号和正式号的登录数据互不相通这个坑后面单独说。改完配置再启动。Maven 工程在根目录执行mvn spring-boot:run没有 Maven 的用 IDE 直接运行标注了 SpringBootApplication 的主类。启动日志里看到 Tomcat started on port 8080 才算真正起来此时最好立刻用浏览器访问一下登录接口的路径确认不是启动即崩溃。如果端口被占用要么换端口要么查出占用进程别硬不改配置去碰运气。3.3 用微信开发者工具加载小程序端并打通登录后端起来后打开微信开发者工具导入项目时选小程序目录——也就是包含 app.json 的那个目录不是压缩包解压后的根目录更不是后端工程目录。AppID 可以先填测试号等需要真机预览再换正式 AppID。开发者工具里有个关键开关详情 → 本地设置 → 不校验合法域名开发阶段必须勾选否则 wx.request 访问 http://localhost:8080 会被拦下。登录打通的核心在小程序前端配置的后端地址。常见做法是在 app.js 的 globalData 里维护 baseUrl// app.js App({ onLaunch() { const token wx.getStorageSync(token); if (token) { // 已有登录凭证冷启动时预拉用户信息 wx.request({ url: ${this.globalData.baseUrl}/user/info, header: { Authorization: token }, success: (res) { if (res.data.code 200) { this.globalData.userInfo res.data.data; } } }); } }, globalData: { baseUrl: http://localhost:8080/api, // 真机调试时改成局域网IP或HTTPS域名 token: } });onLaunch 里判断有无 token 是这类系统的常规写法好处是冷启动时把用户信息预加载进全局各页面打开时不必再各自拉一次。baseUrl 写死是源码包的常态本地联调没问题但换真机预览时必须改成开发机在局域网里的 IP否则手机访问不到 localhost——这个点几乎每次都会被问后面避坑章还会展开。打开小程序后先完整走一遍登录页点登录按钮看后端日志是否收到 /api/login 请求再看 t_user 表是否多了一条带 openid 的新记录。这条链路通了后面任务、打卡、周报就都顺着同一条路走后面的调试基本都在业务逻辑层不再碰环境。4. 登录鉴权与请求联调wx.login 到 token 的完整链路4.1 code2Session 换 openid后端这一步怎么接小程序端的 wx.login() 拿到的 code 是一次性凭证有效期五分钟用一次就作废。它的唯一用途是交给后端去微信接口换 openid 和 session_key。整条链路是小程序发 code → 后端带 appid、secret、code 调微信 code2Session 接口 → 拿到该用户在本小程序的唯一身份 openid → 后端查用户表有则登录无则按待分配处理 → 生成 token 返回前端。这一步对很多新手是个黑匣子其实拆开看只有三步// LoginController.java PostMapping(/login) public Result login(RequestBody MapString, String body) { String code body.get(code); // 1. 用 code appid secret 换 openid String openid wxService.code2Session(code); if (openid null) { return Result.fail(code 无效或已过期); } // 2. 查用户表不存在则创建一条待分配账号 User user userMapper.selectByOpenid(openid); if (user null) { user User.builder() .openid(openid) .role(3) // 默认实习生管理员后台可改 .username(wx_ openid.substring(0, 8)) .build(); userMapper.insert(user); } // 3. 生成 token后续请求放在 Header 里 String token JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(ImmutableMap.of(token, token, role, user.getRole())); }这段逻辑有三个参数值得专门说。code2Session 返回的 openid 必然存在session_key 留作以后解密用户手机号等数据用这里只需要 openid所以空值判断要做在入参 code 上role 默认给 3实习生是常见选择因为管理员和导师账号通常是预置的实习生才是扫码即用的那类人群token 用 JWT 时 payload 至少要放 userId 和 role过期时间建议两小时到一天实习生打卡场景不需要更长。还要提醒一点code 只能消费一次前端如果重复调用 wx.login 并把旧 code 再发一次后端换 openid 会失败所以登录页的按钮要做好防重复点击。4.2 请求封装与 401 处理一套能迁移的写法登录拿到 token 之后所有业务请求都必须在 Header 里带 Authorization。小程序原生没有 axios 那样的拦截器所以大家都会自己封装一个 request 方法这是整个前端工程里最值得看懂的文件没有之一。// utils/request.js const { baseUrl } require(./config); const request (url, method GET, data {}) { return new Promise((resolve, reject) { wx.request({ url: baseUrl url, method, data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) || }, success(res) { const { code, data } res.data; if (code 200) { resolve(data); } else if (code 401) { // token 失效清掉本地凭证回登录页 wx.removeStorageSync(token); wx.reLaunch({ url: /pages/index/index }); reject(res.data); } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); }; module.exports request;这段封装解决三件事。统一注入 token各页面不用重复写 header统一处理 401后端说 token 失效时所有页面行为一致——清缓存、回登录页统一错误提示后端返回的业务错误按其 msg 字段展示。参数上url 传的是 /task/list 这种相对路径baseUrl 从 config 引入而不是在这里写死这是为了把环境切换收敛到一个文件里避免以后改域名满项目找。用法是页面里const data await request(/task/list, GET, { status: 0 });因为返回的是 Promise配合 async/await 读写很顺手。4.3 两个最容易弄错的参数测试号 openid 与合法域名调试阶段有两个参数最容易卡人。第一个是 AppID 切换。测试阶段用测试号开发完全没问题但测试号的 appid 和正式号的 appid 是两套体系同一个人在两套 appid 下拿到的 openid 完全不一样。如果你先用测试号登录生成了用户记录换正式号后同一微信号会生成第二条新记录表现就是登录后角色变成默认的实习生、之前的任务和数据全部消失。这不是代码 bug是 openid 绑定 appid 的机制决定的。所以要在项目早期就决定用哪个 AppID别在数据库里攒了一堆测试号数据之后才后悔。第二个是合法域名。开发者工具勾了不校验合法域名可以随便访问 http 接口但真机预览默认会校验正式 AppID 下wx.request 的域名必须是备案过的 HTTPS 域名并且要到微信公众平台的开发设置里配置到 request 合法域名列表。临时方案是打开真机调试模式能撑一两天长期方案是给后端配 HTTPS 域名。如果后端只有 IP 或 http真机上就只能靠调试模式这是环境限制不是代码问题答辩时也别夸口说生产可用。5. 避坑指南实习生管理系统小程序本地与真机调试的 5 个翻车点5.1 真机请求全部失败合法域名和 baseUrl 双坑叠加现象开发者工具里一切正常扫码换真机预览后所有接口报网络错误或者页面白屏后端日志里一条请求都看不到。原因往往是两个叠加真机访问不到 http://localhost:8080因为 localhost 指向的是手机自己同时正式 AppID 下未配置合法域名请求在校验层就被拦了。解决分两步把 baseUrl 改成开发机在局域网里的 IP确保手机和电脑在同一个 WiFi同时在开发者工具里开启真机调试模式绕过域名校验。如果后端部署在服务器上直接用服务器 IP 更省事但 http 协议在真机上仍受限制最终还是要走上 HTTPS 域名。5.2 登录成功但接口全部 401token 传递断链现象登录接口返回了 token页面也跳转了但随后每个业务接口都返回 401后端日志里全是未登录。原因大多在前端有的页面没走封装的 request 方法直接拿 wx.request 原生调用忘了带 Authorization 头有的是登录时写入 storage 的 key 和请求封装里读取的 key 不一致一个写 token 一个读 Token大小写一差就找不到了。解决全局搜索 token 的读写位置统一 key 名再全局搜索 wx.request把漏网的原生请求都替换成封装好的 request 方法半小时能根治。这条是最典型的看着像后端问题实际是前端问题。5.3 打卡时间少了 8 小时时区默认 UTC 的坑现象早上九点打卡列表里显示凌晨一点整整差 8 个小时。原因MySQL 连接串没配 serverTimezoneJDBC 默认用 UTC而本地时间是 UTC8或者后端 Jackson 序列化时间时用了默认时区。解决连接串加serverTimezoneAsia/Shanghai后端再统一配置 date-format 和 time-zone GMT8前端拿到的时间字符串就正常了。这里不要想着在前端做 8 小时的偏移换算来补救数据库、后端、前端三层统一时区才是正路前端硬算只会让导出和统计继续错下去。5.4 SQL 导入报错MySQL 8 认证与 sql_mode 冲突现象导入脚本时报Unknown database、Table already exists或者字段默认值报错后中断。原因脚本是按 MySQL 5.7 写的本机装的是 8.08.0 默认的 sql_mode 更严格比如 TIMESTAMP 默认值不允许为空、部分废弃语法直接报错。解决先看报错行属于哪种类型。数据库不存在就按前面第 3 章的命令手动建库字段默认值报错就临时执行SET sql_mode ;再导入如果报的是认证插件相关错误说明客户端版本和服务器认证方式不匹配优先升级客户端而不是去改服务器认证。不建议为了导一份 SQL 就去降级 MySQL改脚本或调 session 参数更可控也更符合实际维护场景。5.5 论文里的表结构对不上代码版本漂移现象论文里的 E-R 图没有 openid 字段代码里却有或者论文说有考勤统计表SQL 脚本里找不到。原因这类源码包的论文和工程常常不是同一版本导出的论文写完后代码又迭代了几轮最后打包时只同步了代码和脚本论文没跟着改。解决以 SQL 脚本和代码为准交付前把论文的数据库设计章节对着实际脚本改一遍缺的表补进去字段说明跟着更新。答辩时被评委问你论文里这个字段在哪定义的会非常被动提前对一遍是值得花的半小时。6. 把源码变成能交付自己的版本三个改造与双端验证6.1 改造一baseUrl 抽离区分开发与生产环境源码包里 baseUrl 散落在 app.js 和各页面里是常态交付前我建议把它收敛到 config 文件里一份 JS 维护所有接口前缀// utils/config.js module.exports { env: dev, // 切换环境只改这里 baseUrl: https://you-domain.com/api, // 生产环境地址 devBaseUrl: http://192.168.1.100:8080/api // 开发环境地址 };request.js 里按 env 取值const baseUrl config.env dev ? config.devBaseUrl : config.baseUrl;。改造的价值是以后换环境只改一个字段也方便在演示时证明这套系统可以平滑切换到服务器部署。注意这只是前端侧的开关后端跨域配置和微信合法域名仍然要配套别以为前端切了地址就万事大吉。6.2 改造二打卡加定位与时间水印做出自己的亮点答辩时最容易被问你做了哪些差异化的位置就是打卡。一个投入产出比很高的改造是打卡时记录经纬度和时间水印用来防止代打卡。小程序端用 wx.getLocation 拿经纬度需要先在 app.json 里声明 permission{ permission: { scope.userLocation: { desc: 定位将用于记录打卡位置 } } }用户拒绝授权时回退为仅记录时间不能因为定位把整个打卡流程卡死。后端打卡表加两个可空字段 latitude、longitude前端提交时带上导师端列表展示打卡位置。这样做的增量代码量不大但把打卡从纯记录变成了带校验逻辑的功能也自然引出一段我如何设计防作弊的答辩输出。6.3 双端验证清单模拟器通一次真机再通一次交付前我习惯按场景列一张清单整体过一遍登录注册、任务查看与状态流转、打卡签到、周报提交与审核、评分查看、管理员对用户和部门的增删改查。先走微信开发者工具模拟器再切真机预览走一遍重点验证两个地方权限隔离实习生账号能不能访问导师接口、导师能否看到其他导师名下的学生真机能力定位授权弹窗是否正常弱网环境下请求超时是否给了友好提示而不是白屏。这套源码包的最终形态不应该是解压即用而是我清楚每一张表、每一个接口为什么这么设计。我自己的习惯是拿到这类包先花一个晚上把数据库和核心接口画成关系图再动手改代码后面所有调试都快很多。把 baseUrl 抽离、打卡加点自己的逻辑、权限再收紧一层这套系统才真正从别人的作品变成你的交付物。希望帮到你。本文还有配套的精品资源点击获取