简介：这份资源面向计算机专业学生与微信小程序初学者，提供一套可直接参考的宿舍管理系统完整项目源码，用于解决校园宿舍签到、卫生评分、留言沟通与晚归申请等管理场景的落地实现问题。压缩包共约2000个文件，整体8.4MB，以769个js与393个ts脚本承载业务逻辑与依赖库，258个json与236个md用于配置和说明文档，另有wxml、wxss页面文件及proto、yml等辅助配置，目录结构完整，便于按模块检索。资源已有1958人学习下载，具备一定的参考基础。读者可从中获取宿管与学生双端登录的页面组织方式、GPS定位签到、卫生积分评分、留言回复与晚归申请等功能的实现思路，以及预留MySQL数据库接口进行密码校验的设计参考，适合作为课程设计、毕业设计或小程序入门练手的对照范例。
1. 宿舍管理这件小事，为什么值得用小程序重做一遍
每年开学季，宿管阿姨桌上那本翻烂的登记册、群里刷屏的“谁还没交住宿费”、报修单在楼层间来回传递最后不知道丢在哪——这些场景在很多高校宿舍区依然真实存在。基于微信小程序的宿舍管理系统，瞄准的就是这类高频但低效的事务：学生查宿舍、报修、请假、看通知，管理员分配房间、审批、统计入住率。它不需要装 App，扫码即用，天然贴合学生使用习惯。这份源码适合两类人：一是想拿一个完整业务闭环练手小程序全栈开发的学生或转行者，二是被纸质流程折磨、想低成本上线一套内部工具的开发者。技术栈围绕微信开发者工具展开，前端是小程序原生框架，后端常见做法是 Node.js 或云开发，数据落在 MySQL 或云数据库。下面按“能干什么、怎么跑、怎么改”的顺序拆开讲。
2. 项目定位与技术选型：为什么是原生小程序而不是跨端框架
2.1 业务边界先划清楚
拿到一份宿舍管理系统源码，第一件事不是急着npm install，而是看它到底覆盖了哪些角色和动作。这类项目通常有三类角色：学生端、宿管/管理员端、系统管理员。学生端的核心动作是查自己的宿舍信息、提交报修、发起请假、接收通知；管理员端负责房间分配、报修派单、请假审批、入住统计；系统管理员管账号和基础数据（楼栋、楼层、房间）。源码里如果pages目录下能对应上这几组页面，说明业务闭环是完整的。
我一般会先翻app.json的pages数组，它等于项目的路由地图。一个典型的宿舍管理系统页面清单大致长这样：
{ "pages": [ "pages/login/login", "pages/index/index", "pages/dorm/dorm", "pages/repair/repair", "pages/repair/detail", "pages/leave/leave", "pages/notice/notice", "pages/admin/room/room", "pages/admin/repair/repair", "pages/admin/leave/leave" ], "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/dorm/dorm", "text": "我的宿舍" }, { "pagePath": "pages/repair/repair", "text": "报修" }, { "pagePath": "pages/notice/notice", "text": "通知" } ] } }这段配置里，pages决定哪些页面能被路由到，tabBar决定底部导航。注意tabBar的pagePath必须同时出现在pages里，否则开发者工具会直接报错。很多新手改页面时只加文件不改app.json，结果页面白屏，这是最常见的翻车点之一。判断业务是否完整，就看报修有没有“提交—派单—完成”的状态流转，请假有没有“申请—审批—销假”的闭环，光有列表页没有详情页和状态字段的，多半是半成品。
2.2 技术选型背后的取舍
为什么这类项目普遍用小程序原生框架而不是 uni-app 或 Taro？原因很实际：宿舍管理系统的用户全在微信生态内，不需要上其他端，原生框架的调试链路最短，微信开发者工具里改完直接真机预览，云开发还能省掉服务器。跨端框架的优势在多端复用，这里用不上，反而多一层编译，出问题时排查成本更高。
后端选型上，源码常见两种形态。一种是纯云开发，cloudfunctions目录下放云函数，数据库用云数据库，好处是零运维、上线快，缺点是复杂查询和事务能力弱；另一种是独立后端，Node.js + Express 或 Koa，数据库 MySQL，接口走 HTTPS，小程序端用wx.request调用。看目录里有没有server或backend文件夹、有没有package.json里的express依赖，就能判断属于哪种。如果是云开发，重点看cloudfunctions下每个函数的index.js和config.json；如果是独立后端，重点看路由文件和数据库连接配置。
提示：两种形态的部署方式完全不同，先确认再动手，别把云开发项目当独立后端去配域名，也别把独立后端项目往云函数里塞。
3. 跑起来：从开发者工具到第一个可登录的页面
3.1 环境准备与项目导入
跑通这个项目需要三样东西：微信开发者工具（稳定版即可）、一个已注册的小程序 AppID（没有的话可以用测试号，但云开发和部分接口会受限）、以及后端运行环境（Node.js 或云开发环境）。导入项目的步骤不复杂，但顺序错了会卡很久。
第一步，用微信开发者工具打开源码根目录，工具会自动识别app.json并加载项目。如果根目录下没有project.config.json，工具会提示新建，这时要手动填 AppID。第二步，检查project.config.json里的miniprogramRoot字段，它指向小程序代码的实际目录，有些源码把小程序放在miniprogram/子目录下，根目录只放后端，这个字段填错会导致“找不到 app.json”。
{ "miniprogramRoot": "miniprogram/", "cloudfunctionRoot": "cloudfunctions/", "appid": "你的AppID", "setting": { "urlCheck": false, "es6": true, "postcss": true } }miniprogramRoot是小程序代码根目录，cloudfunctionRoot是云函数目录，只有用云开发时才需要。urlCheck设为false是为了在开发阶段跳过合法域名校验，方便本地调试接口；上线前必须改回true并在小程序后台配置服务器域名，否则真机请求会失败。es6开启后工具会自动把 ES6 转 ES5，老版本基础库也能跑。
3.2 后端启动与数据库初始化
如果是独立后端形态，进入server目录执行依赖安装和启动。常见做法是npm install后npm run dev，用 nodemon 热重载。数据库初始化一般会附带一个.sql文件，导入 MySQL 后得到用户表、宿舍表、报修表、请假表等。
cd server npm install # 导入数据库结构，假设文件名为 dorm.sql mysql -u root -p dorm_db < dorm.sql # 修改数据库连接配置后启动 npm run dev启动前务必改config/db.js或.env里的数据库地址、用户名、密码，源码默认值通常是localhost和root，直接跑大概率连不上。接口启动后，把后端地址填进小程序的utils/request.js或config.js里的baseUrl，注意开发者工具里要勾选“不校验合法域名”，否则本地http://localhost会被拦截。云开发形态则简单些，在工具里开通云开发环境，把环境 ID 填进app.js的wx.cloud.init，再右键cloudfunctions下每个函数选择“上传并部署”，数据库在云开发控制台手动建集合或导入 JSON。
3.3 登录链路的第一道坎
登录是跑通项目的分水岭。小程序端调wx.login拿code，传给后端换openid，后端查用户表，存在则返回 token，不存在则走注册或绑定学号流程。这段逻辑通常写在pages/login/login.js里。
// pages/login/login.js Page({ data: { studentNo: '', password: '' }, onLogin() { const { studentNo, password } = this.data; if (!studentNo || !password) { wx.showToast({ title: '请填写学号和密码', icon: 'none' }); return; } wx.login({ success: (res) => { // code 只能使用一次，五分钟内有效 wx.request({ url: `${getApp().globalData.baseUrl}/api/login`, method: 'POST', data: { code: res.code, studentNo, password }, success: (resp) => { if (resp.data.code === 0) { wx.setStorageSync('token', resp.data.token); wx.switchTab({ url: '/pages/index/index' }); } else { wx.showToast({ title: resp.data.msg, icon: 'none' }); } } }); } }); } });wx.login返回的code是临时凭证，后端用它调微信接口换openid，这个code只能用一次且五分钟过期，所以不能缓存复用。登录成功后把token存进wx.setStorageSync，后续请求在header里带上。wx.switchTab只能跳tabBar页面，跳普通页面要用wx.navigateTo，这里跳首页所以用switchTab。如果登录一直失败，先看后端有没有收到code，再看换openid的接口是否配置了正确的appid和secret，这两个值填错是最常见的静默失败原因。
4. 核心模块拆解：报修、宿舍分配与权限控制怎么落地
4.1 报修模块的状态机设计
报修是宿舍管理系统里状态流转最典型的模块，也是最能看出代码质量的地方。一个合格的报修流程至少有四个状态：待处理、已派单、维修中、已完成，可能还有“已取消”。状态字段一般叫status，用数字或枚举存。前端列表按状态筛选，详情页根据状态显示不同操作按钮。
// pages/repair/repair.js 提交报修 submitRepair() { const { type, desc, images } = this.data; if (!type || !desc) { wx.showToast({ title: '请选择类型并填写描述', icon: 'none' }); return; } wx.request({ url: `${getApp().globalData.baseUrl}/api/repair`, method: 'POST', header: { Authorization: wx.getStorageSync('token') }, data: { type, // 报修类型：水电/门窗/网络等 description: desc, // 问题描述，建议限制 200 字 images, // 图片临时路径数组，需先上传到服务器 dormId: this.data.dormId // 当前学生所在宿舍 ID }, success: (res) => { if (res.data.code === 0) { wx.showToast({ title: '提交成功' }); wx.navigateBack(); } } }); }这里有个容易忽略的点：images拿到的是本地临时路径，直接存数据库没有意义，必须先调wx.uploadFile传到服务器换成永久 URL 再提交。很多源码在演示阶段直接存临时路径，真机重启后图片全裂，这是血泪经验。状态流转在后端做校验，比如只有管理员能把“待处理”改成“已派单”，学生只能取消自己“待处理”的单子，前端按钮显隐只是体验层，真正的权限判断必须在接口里做。
4.2 宿舍分配的数据模型
宿舍分配的核心是几张表的关联：楼栋表、房间表、床位表、学生住宿记录表。常见做法是房间表存building_id、floor、room_no、capacity，床位表存room_id、bed_no、status，住宿记录表存student_id、bed_id、check_in_time、check_out_time。分配动作本质是找一张空闲床位，写入住宿记录，把床位状态改为占用。
-- 查询某楼栋某房间的空闲床位 SELECT b.id, b.bed_no FROM bed b JOIN room r ON b.room_id = r.id WHERE r.building_id = ? AND r.room_no = ? AND b.status = 0; -- 分配床位：先更新床位状态，再插入住宿记录 UPDATE bed SET status = 1 WHERE id = ? AND status = 0; INSERT INTO accommodation (student_id, bed_id, check_in_time) VALUES (?, ?, NOW());UPDATE语句里的AND status = 0是乐观锁的简化写法，防止两个管理员同时分配同一张床。如果UPDATE影响行数为 0，说明床位已被占，要回滚并提示重新选择。住宿记录表用check_out_time为空表示在住，退宿时补上时间并把床位状态改回空闲，这样历史记录可追溯，统计入住率时按时间区间查即可。这套模型不复杂，但字段设计错了后期改起来很痛，比如把床位信息直接塞进学生表，换宿舍就没法留痕。
4.3 权限控制的两层实现
权限控制分前端和后端两层。前端在app.js的onLaunch里根据登录返回的角色决定tabBar显示哪些项，或者用自定义tabBar动态渲染。后端则在每个接口入口校验 token 和角色，常见做法是写一个中间件。
// server/middleware/auth.js module.exports = (roles = []) => { return async (req, res, next) => { const token = req.headers.authorization; if (!token) return res.json({ code: 401, msg: '未登录' }); try { const payload = jwt.verify(token, process.env.JWT_SECRET); req.user = payload; // roles 为空表示只校验登录，不限制角色 if (roles.length && !roles.includes(payload.role)) { return res.json({ code: 403, msg: '无权限' }); } next(); } catch (e) { return res.json({ code: 401, msg: '登录已过期' }); } }; }; // 路由中使用 router.post('/api/repair/assign', auth(['admin']), assignRepair);auth接收允许的角色数组，jwt.verify解析 token 得到用户信息挂到req.user，后续接口直接用。JWT_SECRET必须放环境变量，硬编码在代码里等于把钥匙插在门上。前端隐藏按钮只是减少误操作，真正拦住越权请求的是这层中间件。我见过不少源码前端判断写得挺全，后端接口裸奔，改个请求参数就能替别人审批请假，这种在二次开发时必须补上。
5. 避坑与排查：跑不起来时先看这几处
5.1 页面白屏但控制台无报错
现象是点击某个页面后白屏，控制台没有红色错误。原因多半是app.json的pages里注册了页面，但对应目录下缺.js、.json、.wxml、.wxss四个文件中的某一个，或者文件名大小写不一致。解决方式是逐个核对页面路径与文件名，Windows 下大小写不敏感，真机和部分工具环境敏感，Dorm.js和dorm.js会被当成两个东西。
5.2 接口请求全部失败但浏览器能访问
现象是开发者工具里wx.request全部报“不在以下 request 合法域名列表中”，但用浏览器打开接口地址正常。原因是小程序默认校验域名，本地http://localhost或 IP 地址不在白名单。解决方式是在开发者工具“详情—本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，上线前再到小程序后台把正式域名加进 request 合法域名。
5.3 云函数调用报环境不存在
现象是云开发项目里调云函数返回-501000或“环境不存在”。原因是app.js里wx.cloud.init的env填的环境 ID 和实际开通的不一致，或者根本没开通云开发。解决方式是到云开发控制台复制准确的环境 ID，确认cloudfunctions下每个函数都已“上传并部署”，本地调试时还要在工具里选中正确的环境。
5.4 登录后刷新又回到登录页
现象是登录成功跳转首页，但重新编译或切后台再回来，又要求登录。原因是 token 只存在内存里没落盘，或者app.js的onLaunch没有读取缓存。解决方式是在登录成功时wx.setStorageSync('token', ...)，在onLaunch里先读缓存判断是否已登录，再决定跳转页面。注意onLaunch是异步的，跳转逻辑要放在读取缓存之后。
5.5 图片上传后真机显示裂图
现象是开发者工具里图片正常，真机上图片裂开。原因是存了wx.chooseImage返回的临时路径，临时路径只在当前会话有效。解决方式是选图后立即调wx.uploadFile上传到服务器，拿到永久 URL 再存库和渲染。上传接口的name字段要和后端接收字段名一致，否则后端收不到文件。
6. 二次开发：从能跑到好用，我一般改这三处
第一处是登录态续期。源码里 token 过期后直接踢回登录页，体验很差。我一般会在utils/request.js里统一拦截 401，用wx.login静默换新 token 后重放原请求，用户无感知。第二处是报修模块加消息通知。学生提交报修后，管理员端没有实时提醒，只能靠手动刷新。常见做法是用云开发的数据库监听watch，或者后端加一个轮询接口，管理员端每 30 秒拉一次待处理数量，在tabBar上做角标。第三处是统计页面。入住率、报修完成率这类数据，源码往往只给列表不给汇总，我一般会在后端加一个聚合接口，用GROUP BY按楼栋统计，前端用简单的柱状图展示，不引入重型图表库。
改造时有个验证习惯值得坚持：每改一个接口，先用工具里的“网络”面板看请求参数和返回结构，再改前端渲染，顺序反了容易把前端改乱还找不到问题。数据库改动一定先备份，加字段用ALTER TABLE而不是删表重建，住宿记录这种历史数据丢了就补不回来。这份源码的价值在于业务闭环完整、结构清晰，适合当二次开发的底座，把上面几处补上，基本就能在真实宿舍场景里跑起来。希望帮到你。
本文还有配套的精品资源，点击获取
