我从培训机构的宿管Excel台账说起吧。那会儿宿管老师最怕的是“调宿舍”三个字，改一张表要联动床位、入住记录、水电费账单，手动改完总能漏一处，月底收缴对不上账，吵到管理员办公室去。后来我们把那套台账流程抽出来，用一套基于Python + Vue的学生宿舍管理系统重新实现，前后端分离，有源码、有数据库、有文档，跑通了之后宿管老师才松口气：终于不用抱着Excel到处找人核对。这篇文章我就按完整项目开发的顺序来写，从业务拆解、技术选型、环境搭建、数据库设计到后端接口、前端页面、联调部署，一步步讲清楚每个环节为什么这么做，适合正在做课程设计、毕业设计，或者想替学校、机构做一套可用宿舍管理系统的朋友参考。
1. 宿舍管理系统到底要管什么：业务模块与角色权限的梳理
我每接到一个类似的管理系统项目，第一件事不是建工程开IDE，而是找实际业务方聊一遍日常流程。宿舍管理系统表面看很简单，实际牵扯的状态信息非常多：一个学生从入学登记、申请入住，到分配楼栋、房间、床位，中间可能经历调换、休学退宿，再叠加上每月水电费抄表、日常报修维护，任何一个环节漏记，后面的数据就会越来越乱，直到完全没法用。
1.1 用户角色：管理员、宿管员、学生的权限差异
这套系统的角色按真实场景拆成三类。管理员负责全局配置，比如楼栋信息维护、宿管员账号开通、全校学生档案导入；宿管员是日常操作最多的人，负责办理入住、退宿、调换，录入每月水电费，处理学生提交的报修单；学生通过自己的账号只能查看宿舍信息、提交报修、查看个人缴费记录。角色不同，前端看到的菜单完全不同，后端接口也需要做对应的权限校验，不能让学生账号直接去调管理员的接口，不然系统就失去意义了。
1.2 五大核心业务模块
我梳理下来，宿舍管理系统的核心业务大致可以分成五块：
- 学生档案管理：维护学生基本信息，包括学号、姓名、性别、学院、班级、联系方式，最好支持Excel批量导入，不然几百个学生一个个手工录入得累死。
- 宿舍资源管理：楼栋、房间、床位三级结构，每个房间记录容量、楼层、朝向、是否含独立卫生间等属性，每个床位独立维护占用状态。
- 住宿业务管理：入住、退宿、调换三个核心动作，这是系统里最费工夫的部分，因为涉及床位状态、房间人数、入住流水三个维度必须同时更新。
- 水电费管理：以房间为单位按月抄表录入，生成应缴费用，学生端可以查看自己的历史缴费记录。
- 报修管理：学生提交报修单（问题描述、图片），宿管员收到后更新处理状态。
这五块之间有依赖关系：学生档案和住宿记录关联，宿舍资源和住宿记录关联，水电费和房间关联，报修单和房间、学生关联。把模块边界确定清楚，后面的表结构设计和接口划分才有依据。
1.3 以入住登记为例，看业务状态如何流转
拿最典型的“新生入学分配宿舍”场景来说：学生先被导入系统建立档案，管理员通过查询确认可用的空床位，宿管员执行入住登记。系统要同时完成三件事：把床位状态置为占用、给对应房间的当前人数加一、生成一条入住记录。这三件事必须在一个数据操作里完成，不能只改床位忘了改人数，也不能只改了人数没记录流水。
本质上这个系统就是一组状态机在流转：床位在“空闲、占用、维修”之间变化，学生在“未入住、已入住、已退宿”之间变化。把这条主线想清楚，后面的代码实现就是顺水推舟的事。很多人数据库设计翻车，就是因为在第一步没把状态和流水分开，最后只能靠各种临时字段去补漏洞。
2. 技术选型的真实逻辑：Python后端、Vue前端、MySQL数据库为什么搭得顺手
网上很多课程设计项目一上来就推荐SpringBoot加Vue，企业级开发那确实没毛病，但学生项目、机构内部小系统，用Python真的能省掉一半时间。开发效率第一位，Python写后端接口代码量比Java少差不多一半，尤其Flask这种微框架，把路由、请求、响应这几件事搞清楚就足够开工了。
2.1 Flask与Django的选择
我这里用的后端框架是Flask，配合SQLAlchemy ORM。为什么不选Django？Django自带Admin后台、ORM、模板引擎，能力全面，但Django对于纯接口开发来说偏重，而且Django的版本升级会牵动不少第三方库的兼容性，很多同学在部署阶段踩过Django版本和Python版本打架的坑。Flask路由自由，蓝图模块化清晰，返回JSON非常自然，和Vue这种纯前端框架搭配特别利落。
我给的选型对比表，大家可以直接看：
| 对比项 | Flask + Vue | SpringBoot + Vue |
|---|---|---|
| 接口代码量 | 少，一个接口几行 | 多，需要写大量的类 |
| 上手难度 | 低，几天能入门 | 中高，要理解IOC、AOP |
| 中文资料 | 多 | 非常多 |
| 性能 | 够用 | 更强 |
| 部署 | 轻量，一个Python进程 | 较重，需要Java环境 |
| 适合场景 | 课设、毕设、内部小系统 | 企业级项目 |
2.2 前端为什么选Vue 3而不是其他框架
前端这块，Vue已经是国内前后端分离项目的事实标准。相比React，Vue的模板语法更贴近传统HTML思维，中文资料也多，Element Plus组件库开箱即用，表格、表单、对话框、分页这些后台管理系统最常用的控件直接拿来就能用。我用一个下午就能把宿舍列表页、分配对话框、水电费录入页这些页面拼出来。Vue 3的Composition API配合setup语法糖写起来比Vue 2的Options API紧凑不少，加上Vite做开发服务器，热更新速度比Vue CLI快一截，改完代码浏览器几乎秒刷新。
2.3 MySQL与ORM的配合
数据库选择MySQL 8.0，理由不是它功能多强，而是它太普及了，遇到任何问题网上都能搜到答案。宿舍管理这种数据量级的系统，MySQL性能绰绰有余。表关系相对简单，用SQLAlchemy定义模型类，建表、迁移、查询都在Python代码里完成，比直接写原生SQL好维护得多。连接上搭配PyMySQL驱动，纯Python实现，Windows环境下不会像mysqlclient那样出现编译报错。
整套选型的核心思路是：选资料多、社区大、上手快、排错容易的技术，把精力留给业务逻辑本身，而不是花大量时间在框架底层的踩坑上。对绝大多数课程设计和中小型内部系统来说，这套组合已经非常稳了。
3. 开发环境的搭建细节：Python版本、虚拟环境、Node版本这些坑我一个个说
很多人项目做不出来，第一步就卡在环境搭建上，而且往往是那种最基础的错误，报错信息明明写在终端里，但因为看不懂所以无从下手。我在这一章把环境准备的过程完整过一遍，包括我自己踩过的坑。
3.1 Python与虚拟环境准备
Python版本不要追最新，我用的是3.9系列。许多第三方库对3.11以上版本的C扩展支持没有那么快，比如mysqlclient在Windows上编译经常挂。3.9兼容性稳，PyMySQL是纯Python驱动，安装几乎没坑，连MySQL 8.0默认的caching_sha2_password认证也已经支持了。
Python装好之后一定养成建虚拟环境的习惯。命令行执行：
python -m venv venvWindows下激活命令是venv\Scripts\activate，macOS和Linux下是source venv/bin/activate。虚拟环境把项目依赖和系统Python隔离开，避免不同项目之间包版本冲突，这是非常重要但最容易被忽略的一步。我见过太多人图省事直接用全局Python，结果另一个项目的依赖被升级，整个环境崩掉重装。
激活后安装依赖：
pip install flask flask-sqlalchemy flask-cors pymysql pyjwt嫌弃下载慢就先把pip源换成国内镜像：
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple3.2 Vue前端工程初始化
前端环境要特别注意Node.js版本。Vue 3 + Vite推荐Node 16或18，Node版本过高（比如21+）或过低（12以下）都会出现编译异常，有时候一个莫名其妙的Error: not supported就是版本问题。装完Node之后用Vite创建项目：
npm create vite@latest dormitory-front -- --template vue cd dormitory-front npm install npm install element-plus axios vue-router piniaVite生成的项目目录很克制，src/views放页面组件，src/router放路由配置，src/api放请求封装。对比之前的Vue CLI，Vite没有那么多初始化选项，几秒钟就能跑起一个项目，对新手非常友好。
3.3 前后端目录结构与启动验证
后端如果跟着Flask走，目录结构我是这样分的：
dormitory-backend/ ├── app.py # 入口，注册蓝图 ├── config.py # 数据库配置 ├── models/ │ ├── __init__.py │ ├── user.py │ └── dorm.py ├── apis/ │ ├── __init__.py │ ├── auth_api.py │ └── dorm_api.py └── utils/ ├── jwt_utils.py └── response.py前后端分两个目录独立管理。前端开发服务器默认端口5173，后端监听5000，避免冲突。后端启动命令很简单：
python app.py跑起来之后先访问http://127.0.0.1:5000/api/ping，确认后端在线，再处理前端页面。我的习惯是在接任何业务接口之前，先做一个健康检查接口，把整个请求链路从浏览器到后端再到数据库走通，之后再往里堆业务代码就踏实很多。
4. 数据库表结构设计：床位状态、入住流水、缴费台账不能写成一张大表
数据库设计是整个项目的重头戏。我见过不少同学把学生信息和宿舍信息直接怼在一张表里，想着“反正一个学生就一间房”，结果一旦涉及调换宿舍、查询历史入住，整张表就被各种冗余字段搅成一锅粥。宿舍管理的数据是不断流动的，所以“资源”和“记录”必须分开建模。
4.1 核心表一览
我把核心表结构先列出来，大家可以先扫一遍，后面再讲细节：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| t_user | 登录账号与角色 | id, username, password_hash, role |
| t_student | 学生档案 | id, user_id, student_no, name, gender, phone, college |
| t_building | 宿舍楼栋 | id, building_name, address, manager |
| t_room | 房间 | id, building_id, room_no, floor, capacity, current_count |
| t_bed | 床位 | id, room_id, bed_no, status |
| t_checkin_record | 入住/退宿流水 | id, student_id, bed_id, status, check_in_time, check_out_time |
| t_fee_record | 水电费账单 | id, room_id, billing_month, electricity_fee, water_fee, status |
| t_repair_record | 报修工单 | id, room_id, student_id, description, status, create_time, handle_time |
4.2 四张关键表的设计细节
t_user和t_student一定要分开。账号体系归账号体系，学生档案归学生档案，两者通过user_id字段关联。这样设计的理由是：登录相关的字段（密码、角色）和业务字段（学号、学院）混在一起的话，改密码时要连带学生信息表，角色变化时又会污染学生档案数据。
t_bed床位表单独成表是很多简单实现最容易忽略的。有的系统只在房间表里放一个“剩余床位”数字，但实际入住时必须具体到“几楼几号房几号床”，而且维修中的床位需要单独标记。床位表维护id、room_id、bed_no、status四个字段就够了，查询空床位的SQL写起来非常清爽。
t_checkin_record入住记录表是审计追溯的关键。每次入住生成一条status=1的记录，退宿时把对应记录置为status=0，并写入check_out_time。任何时候都能回答“这个床住过哪些人”“这个学生住过哪几间房”这类问题。千万不能只在t_bed上改状态，那样历史信息全部丢失。
t_fee_record水电费表按月、按房间记录，状态字段区分“未缴费”和“已缴费”。缴费台账和住宿状态解耦开，哪怕学生中途换了宿舍，历史缴费记录也不会乱套，宿管员月底对账时只需要按楼栋、按月份筛一遍就行。
4.3 表关系与事务边界
从关系上讲：一个楼栋包含多个房间，一个房间包含多个床位，一个学生可以有多条入住记录（分布在不同的时间段），一条入住记录对应一个学生和一个床位。这种关系在SQLAlchemy里通过relationship配合ForeignKey配置非常方便。
事务边界要划清楚。前面说的“入住操作”用一个事务覆盖：床位状态更新、房间current_count加一、生成入住流水，这三步要么全部成功，要么全部回滚。退宿是逆操作：床位释放、房间人数减一、把对应入住记录置为失效。调换宿舍本质是“先退宿再入住”，同样包在一个事务里。
写一个典型查询示例，查某栋楼的空床位：
SELECT b.id, r.room_no, b.bed_no FROM t_bed b JOIN t_room r ON b.room_id = r.id JOIN t_building bl ON r.building_id = bl.id WHERE bl.building_name = '三号宿舍楼' AND b.status = 0 ORDER BY r.room_no, b.bed_no;只要表结构拆得清楚，这类业务查询写起来毫不费劲。很多同学喜欢用“房间人数 < 容量”这种隐式判断，临时用一下可以，但作为核心逻辑风险太大，一旦并发入住两个学生就可能超员。用独立的床位状态字段，配合事务控制，才是稳妥的做法。
5. 后端接口设计实战：JWT登录鉴权、角色权限控制与宿舍分配事务
后端接口我按“接口即功能”的原则设计，所有接口统一返回JSON结构，我用一个utils模块封装响应格式。核心接口包括登录、学生管理、楼栋管理、房间管理、床位查询、入住登记、退宿、调换、水电费录入、报修处理。这里挑最有代表性的几个展开讲。
5.1 登录接口与JWT签发
登录接口接收账号密码，校验通过后签发一个JWT token。token里包含用户id、用户名、角色，后续所有接口都在请求头带Authorization: Bearer <token>，后端通过PyJWT解析token拿到当前登录人身份。JWT的优点是服务端不需要保存session，横向扩展方便，对课设来说省掉session管理那一套逻辑，代码量大幅减少。
from flask import Blueprint, request, jsonify from models import User from utils.jwt_utils import generate_token auth_bp = Blueprint('auth', __name__) @auth_bp.route('/login', methods=['POST']) def login(): data = request.get_json() username = data.get('username') password = data.get('password') if not username or not password: return jsonify({'code': 400, 'msg': '账号密码不能为空'}), 400 user = User.query.filter_by(username=username).first() if not user or not user.check_password(password): return jsonify({'code': 400, 'msg': '账号或密码错误'}), 400 token = generate_token({'id': user.id, 'role': user.role}) return jsonify({'code': 200, 'data': {'token': token, 'username': user.username, 'role': user.role}})密码绝对不会以明文存储在数据库里，这里用check_password方法做校验，底层是werkzeug的generate_password_hash和check_password_hash，这是Flask生态里很成熟的密码处理方案。
5.2 权限装饰器怎么用
在Flask里做权限控制，最直接的方式是写装饰器。我定义两个装饰器：
from functools import wraps from flask import request, jsonify import jwt def login_required(f): @wraps(f) def wrapper(*args, **kwargs): auth_header = request.headers.get('Authorization') if not auth_header or not auth_header.startswith('Bearer '): return jsonify({'code': 401, 'msg': '未登录'}), 401 try: payload = jwt.decode(auth_header[7:], SECRET_KEY, algorithms=['HS256']) request.user_id = payload['id'] request.user_role = payload['role'] except jwt.ExpiredSignatureError: return jsonify({'code': 401, 'msg': '登录已过期'}), 401 except jwt.InvalidTokenError: return jsonify({'code': 401, 'msg': '无效的token'}), 401 return f(*args, **kwargs) return wrapper def admin_required(f): @wraps(f) def wrapper(*args, **kwargs): result = login_required(f)(*args, **kwargs) if getattr(request, 'user_role', None) != 1: return jsonify({'code': 403, 'msg': '无权限操作'}), 403 return result return wrapper业务接口上只需要加一行装饰器，权限逻辑不会散落到各个Controller里，维护起来非常舒服。比如宿舍分配接口只允许管理员和宿管员调用，学生在源码层面就无法触达这个操作。
5.3 宿舍分配接口的完整实现
这是整个系统最核心的一个接口，也是最能体现后端设计功力的地方。来看代码：
from datetime import datetime from flask import Blueprint, request, jsonify from models import db, Room, Bed, CheckinRecord dorm_bp = Blueprint('dorm', __name__) @dorm_bp.route('/assign', methods=['POST']) @admin_required def assign_sleep(): data = request.get_json() student_id = data.get('student_id') bed_id = data.get('bed_id') if not student_id or not bed_id: return jsonify({'code': 400, 'msg': '参数不完整'}), 400 active = CheckinRecord.query.filter_by( student_id=student_id, status=1 ).first() if active: return jsonify({'code': 400, 'msg': '该学生已有在住记录'}), 400 bed = db.session.get(Bed, bed_id) if not bed or bed.status != 0: return jsonify({'code': 400, 'msg': '床位不存在或已被占用'}), 400 try: bed.status = 1 room = db.session.get(Room, bed.room_id) room.current_count += 1 record = CheckinRecord( student_id=student_id, bed_id=bed_id, status=1, check_in_time=datetime.now() ) db.session.add(record) db.session.commit() except Exception: db.session.rollback() return jsonify({'code': 500, 'msg': '服务器内部错误'}), 500 return jsonify({'code': 200, 'msg': '分配成功'})这里有三处提前返回的业务校验：学生是否已有在住记录、床位是否存在、床位是否可用。之后三步操作被包在同一个try...commit里，一旦中间任何一步抛异常，rollback会把之前改动的数据全部回滚，保证数据库不会出现“床位被占了但入住流水没生成”这种不一致状态。
分配宿舍前最好加一层性别和房间类型的匹配校验，别让男生账号把床位分进女生楼，这类业务校验放在接口开头，和上面的参数校验并列。
5.4 退宿、调换、水电费、报修接口要点
退宿接口是分配宿舍的逆操作，同样需要事务：床位状态置为0、房间人数减一、把当前有效的入住记录置为0。调换接口是“退宿+入住”的组合，校验逻辑更严格：新床位必须空闲、新房间所属楼栋和学生性别匹配、目标房间当前人数未满。水电费录入相对简单，按房间号加月份确保唯一，重复录入直接返回提示，这里用一个唯一索引就能防止并发问题。报修工单则是一个状态流转表，学生提交后状态为“待处理”，宿管员处理完毕改为“已完成”。
5.5 分页查询与条件筛选
宿舍列表接口必须支持分页和条件筛选。Flask-SQLAlchemy的paginate方法很好用：
@dorm_bp.route('/rooms', methods=['GET']) @login_required def room_list(): page = request.args.get('page', 1, type=int) per_page = request.args.get('per_page', 10, type=int) building_id = request.args.get('building_id', type=int) status = request.args.get('status', type=int) query = Room.query if building_id: query = query.filter_by(building_id=building_id) if status is not None: query = query.filter_by(status=status) pagination = query.paginate(page=page, per_page=per_page, error_out=False) data = { 'list': [room.to_dict() for room in pagination.items], 'total': pagination.total, 'page': page, 'per_page': per_page } return jsonify({'code': 200, 'data': data})前端配合Element Plus的分页组件，滚动加载、翻页、条件刷新都非常顺滑。条件筛选传入楼栋、楼层、状态等参数，后端通过判断是否存在再拼接到查询链上，这种写法比把所有筛选条件都用if嵌套写出来清爽得多。
6. Vue前端页面开发：登录页、列表页、分配对话框的实现链路
后端接口设计好之后，前端要做的事情就是把这些接口串起来，变成可操作的页面。对宿管老师来说，页面好不好用比接口好不好看更重要。
6.1 路由设计与动态菜单
前端路由按页面维度拆分，整体嵌套在一个带侧边栏的Layout里面：
const routes = [ { path: '/login', component: Login }, { path: '/', component: Layout, meta: { requiresAuth: true }, children: [ { path: 'dashboard', component: Dashboard, meta: { title: '首页' } }, { path: 'students', component: StudentList, meta: { title: '学生管理', roles: [1, 2] } }, { path: 'rooms', component: RoomList, meta: { title: '宿舍管理', roles: [1, 2] } }, { path: 'fees', component: FeeList, meta: { title: '水电费', roles: [1, 2] } }, { path: 'repairs', component: RepairList, meta: { title: '报修管理' } } ] } ]菜单根据当前用户的角色动态渲染：管理员看到全部菜单，宿管员看不到系统管理相关入口，学生角色单独走一个精简布局，只显示“我的宿舍”“报修”“缴费查询”。我这边的实现是用meta.roles标记菜单允许访问的角色，路由守卫里做一次判断，不匹配就重定向到首页。
6.2 axios封装与拦截器
前端在src/api/request.js里封装一个axios实例，把请求拦截、响应拦截、错误处理统一放到一个文件里：
import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.msg) return Promise.reject(new Error(res.msg)) } return res }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error('请求失败') return Promise.reject(error) } ) export default request这样每个页面组件里只需要调用request.get('/rooms')，不用重复处理token、错误码、401跳转这些套路化逻辑。每次拿到返回结果，直接操作data字段即可。
6.3 登录页与路由守卫
登录页逻辑不复杂：表单收集账号密码，点击登录调用/auth/login，成功后将token写入localStorage，跳转到首页。容易被忽略的是路由守卫，没有登录的访问一律拦截，这里用了Vue Router的beforeEach钩子：
router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.meta.requiresAuth && !token) { next('/login') } else { next() } })路由守卫的核心价值在于：用户即使手打URL访问某个受保护页面，也会被重定向回登录页，不会看到白屏或者无权限的接口报错。
6.4 宿舍列表页与分配对话框
宿舍列表页是后台管理系统最典型的“表格 + 搜索 + 分页 + 操作按钮”组合。页面打开时调用分页接口拉取数据，表格展示楼栋、房间号、容量、当前人数、状态。操作栏放“分配宿舍”“查看详情”“退宿”三个按钮。
分配宿舍我用了一个嵌套的对话框，交互流程是这样的：
- 点击“分配宿舍”按钮，弹出对话框。
- 第一步选择学生，通过远程搜索接口按学号或姓名模糊匹配。
- 第二步选择楼栋，选中楼栋后联动加载该楼栋的空床位列表。
- 第三步确认床位，点击“确定”调用分配接口。
这个联动加载很适合练Vue 3的watch和异步处理，也是答辩时老师最喜欢问的功能点。表格状态用Element Plus的el-tag组件渲染，不同状态用不同颜色区分：空闲绿色、满员红色、维修黄色。整体视觉信息密度高，宿管员扫一眼就知道哪些房间还能安排人。
信息展示上记得处理空数据状态。用了Element Plus的el-empty组件，后端返回空列表时页面显示“暂无数据”而不是一整块空白，这个细节在演示时会加分。
7. 前后端联调和部署阶段：跨域、中文乱码与常见报错的排查
接口写完了，前端页面也拼完了，接下来进入联调。这个阶段的问题往往不是业务逻辑，而是一堆工程层面的事，跨域、编码、端口、序列化，虽然不复杂，但能把人折腾到怀疑人生。我把高频问题集中整理出来。
7.1 跨域问题的两种解法
前端跑在5173端口，后端跑在5000端口，浏览器默认会拦截跨域请求。两个解决方案：后端开启flask-cors放行，或者前端用Vite的proxy做代理。我在开发环境推荐代理法，更优雅也更接近生产环境的行为：
// vite.config.js export default defineConfig({ server: { proxy: { '/api': { target: 'http://127.0.0.1:5000', changeOrigin: true } } } })前端代码里请求路径写成/api/...，开发服务器自动转发到后端的5000端口，浏览器看到的是同源请求，跨域问题直接消失。后端还是建议加上flask-cors，以备将来直接域名访问或者第三方调试工具调用。
7.2 中文乱码与时间序列化
中文乱码几乎每个项目都会遇到一次，原因通常是两个：MySQL建表时没有指定utf8mb4字符集，以及数据库连接串里没有写charset=utf8mb4。解决办法是建库时明确指定：
CREATE DATABASE dormitory DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;连接串写成：
SQLALCHEMY_DATABASE_URI = 'mysql+pymysql://root:password@localhost:3306/dormitory?charset=utf8mb4'时间序列化是另一个高频问题。SQLAlchemy返回的datetime对象直接放进jsonify会抛TypeError: Object of type datetime is not JSON serializable。解决方式有两个：在模型类里写一个to_dict()方法，把时间字段统一转成字符串，或者自定义一个JSONEncoder。我推荐前者，代码更直观：
def to_dict(self): return { 'id': self.id, 'room_no': self.room_no, 'create_time': self.create_time.strftime('%Y-%m-%d %H:%M:%S') if self.create_time else None }7.3 启动顺序与部署要点
本地跑这套系统，推荐的启动顺序是：先启动MySQL服务，确认数据库连接正常，再启动后端Flask，最后启动前端Vite。后端连不上数据库时，请求日志里会一直报Can't connect to MySQL server，优先排查MySQL服务是否启动、账号密码是否正确、端口是否为3306。
生产部署的建议是后端用gunicorn启动：
gunicorn -w 4 -b 0.0.0.0:5000 app:app前端在项目目录执行npm run build生成dist静态文件，用nginx托管。这样做出来的系统，局域网里其他电脑也能访问，宿管老师就不用在自己的电脑上跑开发服务器了。当然，课程设计答辩一般用Vite开发模式就足够，但知道生产构建流程会让印象分高不少。
7.4 联调高频问题排查表
我把实际调试中最常遇到的现象、原因和方向整理成表，完全可以当排查手册用：
| 现象 | 常见原因 | 解决方向 |
|---|---|---|
| 前端请求报404 | 代理路径或后端蓝图前缀不一致 | 核对/api前缀和蓝图url_prefix |
| 前端请求报500 | 后端代码异常或数据库连接断开 | 看后端终端堆栈日志，优先处理第一行 |
| 登录成功但页面空白 | 路由守卫拦截或token未写入 | 检查localStorage是否存了token |
| 表格时间显示错误 | 时区或格式化问题 | 前端用dayjs统一格式化显示 |
| 列表中文乱码 | 建表或连接串字符集不对 | 统一改utf8mb4 |
| 分配床位后人数没变 | 事务只执行了部分步骤 | 检查事务提交位置，别把commit写在条件外 |
联调阶段最重要的技能就是看日志。后端终端会打印完整的堆栈信息，前端浏览器F12的Network面板能看到具体请求和响应内容，排查问题先看这两处，而不是凭感觉瞎猜。我见过太多人在没看日志的情况下改代码，越改越乱，最后改了一晚上结果问题出在端口占用上。
最后分享一点个人的实际体会：这类管理系统，技术本身没有多高的门槛，真正的价值在于把业务状态流转梳理清楚。如果你正在做课程设计或者毕业设计，建议先把第一章的业务流程和第四章的表结构设计想明白，代码反而是水到渠成的事情。这整套“资源 + 流水 + 状态”的建模思路，换到图书管理、实验室设备管理、仓库管理，逻辑都是一样的，完全可以复用。踩坑不怕，日志里都有答案，静下心来看一行的报错，比自己埋头瞎试一下午有效得多。
