企业官网建设流程全解析

做这类管理系统的时候，我每天都能收到类似的提问：Java和Python到底选哪个？SSM是不是过时了？Django为什么也要掺一脚？这套基于SSM+Django的学生公寓管理系统把整个闭环走下来之后，我想通了一个道理——这类问题本来就不该有“二选一”的答案。双技术栈不是炫技，而是让每个工具去做它最擅长的事。这套系统的源码、LW（毕业论文/课程设计文档）、调试文档和经验记录我完整整理过，本文不打算罗列下载入口，而是把这套系统的设计思路、数据库结构、核心实现和排查链一次性讲透，帮你真正能独立复现和交付。

1. 为什么学生公寓管理系统偏偏是SSM+Django双栈组合

1.1 学生公寓管理系统为什么总绕不开Java+SSM

打开任意一个毕业设计选题库，学生公寓管理系统、图书馆管理系统、教务管理系统这几类永远在榜单前列。原因很简单：它们的业务模型足够典型——有明确的角色权限、有标准的多表关联、有增删改查之外的事物流程。而Java+SSM在这类系统里的统治地位，靠的不是时髦，是三点：

第一，教学链路成熟。从Java基础到JDBC再到MyBatis，再到Spring和SpringMVC，教材和网课都按这个路线排，课程设计季一到，教室里的屏幕几乎全是同一套结构。

第二，SSM的搭配边界非常清晰。Spring负责对象管理和事务，SpringMVC负责请求路由，MyBatis负责SQL映射。三层各管一摊，出了问题定位很快，特别适合一两个人独立开发的项目。

第三，它是面试高频区。你把这个项目写进简历，面试官大概率会问Spring的Bean生命周期、MyBatis的动态SQL、SpringMVC的请求流程。做一遍系统等于把这些考点亲手撸了一遍。

所以选Java+SSM做主语言，在做这个决策的时候我就没犹豫过。核心目标很明确：稳定、可控、能讲清楚。

1.2 Django在这里的真实角色，不是让你写两套系统

很多人一看标题里有Django，第一反应是“是不是要用Python把系统重写一遍”。我一开始也差点这么干，后来做技术选型的时候做了一个关键决定：Django不参与核心业务，它作为辅助服务承担数据清洗、报表生成、定时任务这类Java端写起来比较啰嗦的活。

为什么这样分？举个例子，学生入住数据经常需要从Excel批量导入。Java写POI解析Excel，代码量不小，还得处理各种单元格格式。而用Python的pandas加Django的ORM，十行脚本解决问题。再比如课设验收需要一份入住率统计报告，Java端生成Excel要调Apache POI，模板还特别难调；Python这边openpyxl生成格式漂亮的报表也就是几句话的事。

所以最终架构是这样：

两套程序跑在同一个MySQL上，各用各的端口，互不阻塞，这是整个方案能跑通的前提。

1.3 整体架构视图，先建立坐标再谈细节

动手之前先在脑子里画了一张大图，整个过程所有的编码、调试、写文档都是围绕这张图展开的：

核心链路是：浏览器（Bootstrap + JSP页面） → SpringMVC控制器 → Service业务层 → MyBatis操作MySQL → 结果原路返回。权限控制用Shiro，拦截器校验登录态和角色。Django这一侧独立跑一个8000端口服务，提供两个能力：一是面向管理员的后台命令（批量导入、报表生成），二是暴露少量REST接口给SSM端调用（比如宿舍入住率实时查询）。

这张图的价值在于它界定了边界：Java不用管Excel解析，Python不用管权限鉴权。两边的代码互不侵入，出问题时各自排查，项目整体反而清爽。

2. 从业务流程反推功能模块与数据库设计

2.1 学生公寓要管哪些事，先列清单再建表

做管理系统的第一件事永远不是建表，而是把业务场景一条一条列出来。学生公寓的业务闭环是这样的：

新生报到要入住，入住前要确认宿舍和床位，住进去了要按月/按学期交住宿费，宿舍灯管坏了要报修，家长或朋友来访要做访客登记，学生毕业或退学要办理退宿并把床位释放。再加上公寓楼栋、宿舍管理员和公告通知，整个业务流就齐了。

顺着这条线拆功能模块，一共七个：

• 公寓与房间管理：楼栋、楼层、房间、床位信息的维护
• 学生与入住管理：学生档案，入住、换宿、退宿的流程操作
• 缴费管理：住宿费账单生成、缴费登记、欠费查询
• 报修管理：报修单提交、派单、维修结果回填
• 访客管理：访客登记、离开注销、访客记录查询
• 公告管理：公告发布、列表展示
• 系统权限：管理员、宿管员、学生三类角色的登录与权限控制

2.2 核心数据表的结构设计，一张表对应一个业务对象

数据库我用的MySQL 5.7，字符集直接指定成了utf8mb4——这个细节后面救了我一次，提前声明避免乱码。核心表大概十张左右，下面这七张是业务的骨架：

设计的时候着重考虑了一个问题：宿舍的容量和入住状态怎么保持同步？如果只维护room表的used_count，每次入住退宿都要手动加一减一，一个疏忽就数据错乱（下次入住统计就会出现负值）。所以我用了“从表推导主表”的思路：room.used_count不在入住流程里直接更新，而是通过一条SQL从occupancy表实时统计：统计status=入住中的记录数，再定时任务同步回room.used_count。这样查询快、写入不锁表、统计口径统一，这是整个数据库设计里最值得讲的一笔。

2.3 用唯一索引拦截重复入住，把校验下沉到数据库

业务层可以做校验，但如果两个人同时对学生A发起入住操作，业务层的if判断是拦不住并发冲突的。最可靠的办法是把约束下沉到数据库层。

我首先在bed表给bed_id加了一个“当前床位必须唯一”的约束，进一步在occupancy表里做了两个设计：一是加联合唯一索引uk_student_active(student_id, status)，只对status=1的进行唯一约束；二是给每个bed的active状态也加了唯一索引uk_bed_active(bed_id, status)。这样一来，同一学生同时有两张入住中的单据、同一床位同时被分配给两个人这两类数据错误，在数据库层面直接被拒绝。

CREATE TABLE occupancy ( occupancy_id INT PRIMARY KEY AUTO_INCREMENT, student_id INT NOT NULL, bed_id INT NOT NULL, check_in_date DATE NOT NULL, check_out_date DATE, status TINYINT NOT NULL DEFAULT 1 COMMENT '1-入住中 0-已退宿', UNIQUE KEY uk_student_active (student_id, status), UNIQUE KEY uk_bed_active (bed_id, status), CONSTRAINT fk_occ_student FOREIGN KEY (student_id) REFERENCES student(student_id), CONSTRAINT fk_occ_bed FOREIGN KEY (bed_id) REFERENCES bed(bed_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里MySQL的InnoDB引擎对于唯一索引是天然支持并发控制的，就算同一个瞬间来了两个事务，也只有一个能提交成功，另一个会报Duplicate entry异常。业务层把这个异常捕获起来，转成“该学生已存在有效入住记录”的提示即可。这套设计帮我挡掉了后续测试阶段大量的人工脏数据。

3. SSM端核心实现与踩坑记录

3.1 统一返回体与全局异常，是给所有接口定的规矩

写SpringMVC接口的时候，如果每个Controller各自返回不同的Map结构，前端联调很快就会失控——一会儿取data，一会儿取rows，出错了还不知道该判断哪个字段。我第一天的第一件事，就是定了一个统一返回体Result。

public class Result { private int code; // 200成功，500业务异常，401未登录 private String message; private Object data; public static Result success(Object data) { ... } public static Result error(String message) { ... } }

所有Controller统一返回这个对象，再配合@RestControllerAdvice做全局异常捕获，业务里只管抛出自己定义的BusinessException，异常消息自动塞进Result返回给前端。后续写调试文档时，只需要一句话就能说清楚接口规范：凡是非200的code，message字段就是给用户的提示，data永远是null。

3.2 MyBatis动态SQL处理多条件查询，宿舍筛选的核心依赖

学生公寓系统的列表页几乎全都是组合查询：按公寓筛选、按状态筛选、按日期范围筛选、按关键词模糊搜索。如果每个组合都写一条独立SQL，那SQL数量会膨胀到一个不可维护的状态。MyBatis的<where>和<if>标签就是为此设计的。

<select id="findStudentWithFilter" resultType="com.example.vo.StudentVO"> SELECT s.*, b.bed_code, r.room_code, ap.apartment_name FROM student s LEFT JOIN occupancy o ON s.student_id = o.student_id AND o.status = 1 LEFT JOIN bed b ON o.bed_id = b.bed_id LEFT JOIN room r ON b.room_id = r.room_id LEFT JOIN apartment ap ON r.apartment_id = ap.apartment_id <where> <if test="studentNo != null and studentNo != ''"> AND s.student_no LIKE CONCAT('%', #{studentNo}, '%') </if> <if test="apartmentId != null"> AND ap.apartment_id = #{apartmentId} </if> <if test="status != null"> AND o.status = #{status} </if> <if test="checkInDateStart != null"> AND o.check_in_date &gt;= #{checkInDateStart} </if> <if test="checkInDateEnd != null"> AND o.check_in_date &lt;= #{checkInDateEnd} </if> </where> ORDER BY s.create_time DESC </select>

关键点有两个。第一个：入住表用LEFT JOIN且带ON过滤条件，不满足条件时学生依然会出现在列表里（只是床位为空），这符合“查学生档案”的语义。第二个：动态条件的值全部来自封装的Query对象，前端传一个空的查询对象时，SQL自动退化为全表查询，不会因为缺少某个条件而报错。

这个查询在入住办理页面用得最多——宿管员输入学号模糊查询、勾一个公寓筛选、或者看某天之后入住的学生，一次查询全搞定。

3.3 登录鉴权与权限控制，选Shiro还是拦截器

学生公寓系统的角色就三类：管理员、宿管员、学生。权限粒度不需要到按钮级，控制到URL和页面菜单级别就够用。我用了Apache Shiro，因为它在SSM项目里集成成本低，而且自带Session管理，比手写拦截器稳定得多。

核心配置拆成三部分：

<!-- shiro配置核心：匿名访问、认证后访问、角色权限区分 --> <bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean"> <property name="securityManager" ref="securityManager"/> <property name="filterChainDefinitions"> <value> /login = anon /static/** = anon /api/auth/** = anon /admin/** = roles[ADMIN] /manager/** = roles[MANAGER] /** = authc </value> </property> </bean>

配置里面最值得说的是/admin/** = roles[ADMIN]这一条。它是严格按照“URL前缀匹配”来做的：以admin开头的URL，必须是管理员角色才能访问。所以Controller的写法从一开始就要有意识地按角色分目录：AdminController、ManagerController、StudentController，而不是全部混在同一个HomeController里。这是后期非常省心的一件事——加接口的时候只要确认路径前缀写对了，权限就自动兜底，潜意识里根本不用再去翻权限配置。

3.4 三个容易翻车的地方，代码本身反而最简单

SSM这套体系里，最坑的往往不是业务逻辑，而是外围的杂活。我按踩坑顺序记三笔：

一是Maven依赖冲突。典型的场景是引入了Druid连接池之后，又单独引入了com.alibaba.fastjson，再引入其他第三方组件时，连带拉进来的依赖版本互相打架，启动时直接报冲突。解决手段就一句话：在pom.xml里统一用dependencyManagement把常用组件的版本写死，包括Spring、MyBatis、Shiro、Druid，其他依赖一律不写version，让父子工程统一管。

二是MyBatis的Mapper接口和XML映射文件绑定失败。报错通常是Invalid bound statement (not found)。排查链路是固定的：检查namesapce是否和Mapper接口全限定名一致；检查XML文件是否编译到classes目录（Maven默认只编译src/main/resources下的XML，如果你的XML放在java目录下，需要额外在pom里配置resource）；检查接口方法名和XML的id是否一致。90%的问题出在第一和第三项。

三是SpringMVC拦截了静态资源。JSP页面里引个CSS/JS，浏览器直接404。原因是DispatcherServlet把/static/**也当成了Controller路由，需要在spring-mvc.xml里放行静态资源：

<mvc:resources mapping="/static/**" location="/static/"/>

这三处每一条都让我在调试上花掉大半天。写调试文档的时候，我把它们全放了进去，后来照着文档走的人基本没在环境配置上卡过壳。

4. Django模块的定位与实际落地

4.1 Django在这套系统里负责的几件具体事

定位在前面已经说清楚了：它是辅助工具链，不是与SSM平行的第二套系统。具体到代码层面，它做四件事：

第一，学生数据批量导入。管理员拿到一份Excel，里面几百行学生档案，按学号、姓名、班级、电话直接解析后写入student表。

第二，入住率统计报表。自动计算每个公寓、每栋楼层当前已入住床位、剩余床位、入住率百分比，按模板生成Excel报表。

第三，缴费账期检查。每天跑一次定时任务，把到期未缴费的学生名单推送到公告接口。

第四，Django自身管理后台。超级管理员可通过Django admin直接查看辅助任务的执行记录和日志。

4.2 用Django Command代替Web页面，减少不必要的接口

如果这些定时任务做成Web页面，又要加Controller又要加页面，完全是往复杂里做。Django更优雅的姿势是使用Command模块，随用随调，不需要任何页面：

# 创建一个名为stats的app，在app下新建management/commands/occupancy_report.py python manage.py occupancy_report --apartment-id 3

核心Command代码大致长这样：

from django.core.management.base import BaseCommand from django.db.models import Count, Q from stats.models import Room, Bed, Occupancy class Command(BaseCommand): help = "按公寓生成入住率统计报表" def add_arguments(self, parser): parser.add_argument("--apartment-id", type=int, required=True) def handle(self, *args, **options): apt_id = options["apartment_id"] rooms = Room.objects.filter(apartment_id=apt_id).annotate( occupied=Count("bed", filter=Q(bed__occupancy__status=1)) ) # 生成Excel的逻辑，略去细节

这种设计带来的好处是：定时任务或手动调用都方便，而且Command天然自带日志出口，配合crontab就能定时跑。不需要为辅助功能加一堆Web页面，验收演示时用命令行执行反而更有“工程感”。

4.3 让Django直接读MySQL里SSM建的表

Django默认会用自己的ORM建表，但在这套系统里，核心表已经被SSM侧管理了。Django要做的事情是“只读映射”，不做迁移，更不去碰表结构。这个需求在Django里非常容易实现：在model的Meta里显式声明managed = False，同时指定db_table。

class Student(models.Model): student_id = models.AutoField(primary_key=True) student_no = models.CharField(max_length=32) name = models.CharField(max_length=50) class_name = models.CharField(max_length=100) phone = models.CharField(max_length=20) class Meta: managed = False db_table = "student"

managed = False的意思是：Django不会对这张表做migrate，不会改动任何字段，只负责读取。这是两种技术栈共享同一数据库时最安全的姿势。我用Django侧读到的数据只做统计和报表，写入操作一律回写SSM提供的HTTP接口，避免了双写数据源带来的脏数据风险。

4.4 双系统和写安全，一份自检清单

在一个项目里同时跑Java和Python，最担心的就是两边写同一张表然后互相锁死。我执行了一套强制纪律，列成自检清单：

• 核心业务表（occupancy、payment、repair、bed）只允许SSM写入，Django只读
• Django需要写入的只有自己生成的报表、任务日志这两类附属表
• 两边对MySQL使用不同的账号，Java用读写账号，Python用只读账号加独立的统计库账号，在数据库层把权限隔开
• 定时任务打日志，每次执行都输出开始和结束时间、影响行数，方便回溯

执行完这套纪律，两套系统在整个开发期没有发生过一次数据竞争。默认不信任双方的自觉性，用账号权限在物理上隔离开，是最省心的做法。

5. 源码、LW与调试文档的完整交付

5.1 源码目录的组织方式，比想象中重要

源码组织这个细节很少有人认真写，但对使用者来说，目录结构就是第一印象。我最终采用的目录结构是：

student-apartment-system/ ├── backend-ssm/ # Java SSM核心系统 │ ├── pom.xml │ ├── src/main/java/... │ └── src/main/resources/... ├── tool-django/ # Django辅助模块 │ ├── manage.py │ ├── stats/ # 统计相关app │ └── reports/ # 报表导出相关app ├── sql/ │ ├── init.sql # 建库建表脚本 │ └── test_data.sql # 演示用测试数据 ├── docs/ │ ├── 需求分析.md │ ├── 设计文档.md │ └── 调试文档.md └── README.md # 一页纸部署说明

README.md里用一页纸把环境要求（JDK 1.8、Maven 3.6+、MySQL 5.7+、Python 3.8+）、初始化步骤（导入sql、修改配置文件、启动两个服务）讲完。给源码的人不需要猜，照着跑就行。这一点我强烈建议复制过去用，因为实际上大多数人拿到的源码，第一件事永远是寻找“怎么跑起来”。

5.2 LW文档怎样配合源码，才算一份合格的课设说明

LW（课程设计/毕业论文）的写法，重点在于逻辑链完整：从背景、到需求、到设计、到实现、到测试，每个环节都是上一环节的自然延伸。我的建议是LW的每一章都要能对应到源码里的具体位置：

• 需求分析章节里提到的每条功能，都能在某个Controller或页面菜单里找到对应实现
• 数据库设计章节列出的每张表，都能在sql/init.sql里找到建表语句
• 核心流程（入住、退宿）章节，能用一张程序流程图把Service层调用的逻辑走一遍

还要注意一个很现实的点：测试章节部分要给出真实跑出来的结果，推荐用表格呈现。比如并发校验测试可以写“对同一床位并发提交两次入住请求，第一次返回成功，第二次返回床位已被占用”，然后附上两张浏览器页面截图。这种有据可查的测试描述，比空泛写“系统测试通过”有说服力得多。

5.3 调试文档要写什么，菜鸟最需要的排错地图

调试文档我写成了“症状 → 原因 → 解决方案”的对照表形式。做一个基础环境可分三步走，对照着排错即可：

这页表格我建议打印出来放在手边，因为所有学生公寓管理系统的调试流程基本都能浓缩成这五类问题。把环境跑通这件事做好了，身在项目中的实际感受体验会瞬间好起来。

5.4 讲解演示怎么准备，讲逻辑而不是背代码

最后的答辩或交付演示，最容易犯的错是背代码。评审人真正想听的，是三个层面的东西：系统能做什么、为什么这么设计、遇到问题怎么解决。

我准备了一套固定的演示动线：用测试数据演示一次完整的入住流程 → 演示一次退宿流程 → 打开数据库展示occupancy表的数据状态变化 → 展示一次多条件查询 → 展示Django的统计报表命令。全程讲业务逻辑和设计理由，代码只在被问到的时候局部展示。这套动线我用下来非常顺，推荐直接采用。

6. 部署联调中的实际问题排查链路

6.1 中文乱码，从哪一层查起

乱码问题几乎每个做系统的人都会遇到，而且坑点分散在三层：数据库、JDBC连接、页面。我的排查链路是这样的：

第一步，查数据库本身。执行SHOW VARIABLES LIKE 'character_set%';，如果database和connection的值不是utf8mb4，说明库的字符集建错了。修正方法是在建库时指定CREATE DATABASE dorm DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。

第二步，查JDBC连接串。如果连接串里没有CharacterEncoding参数，立刻补上：

jdbc:mysql://localhost:3306/dorm?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai

第三步，查页面编码。JSP页面顶部必须声明<%@ page contentType="text/html;charset=UTF-8" %>。三层排查完，90%的乱码都能解决。剩下那10%是重新导入数据时数据源本身就已经乱掉的，直接清表重新导入即可。

6.2 Tomcat端口占用与并发连接数，一个容易被忽略的坑

Tomcat默认8080端口，如果机器上装了多个Java项目，或者之前开的Tomcat没正常关闭，启动就会报端口占用。解决方式无外乎两步：查占用、换端口。

# Windows下查占用 netstat -ano | findstr 8080 taskkill /F /PID 进程号 # Linux下查占用 lsof -i:8080

还有一个容易忽略的点是Tomcat的并发连接数。默认的maxThreads是200，但很多课设项目用的是SpringBoot内嵌Tomcat，没注意过这个参数。做压力演示时如果一次性并发加载很多图片资源，可能出现部分请求失败。前期就把server.tomcat.max-threads=400和server.tomcat.accept-count=200写在配置文件里，演示时会稳很多。

6.3 Django和SSM同时操作同一张表，锁表问题排查链路

在一开始我设计了口径：Django只读SSM的库表。但在早期开发时没有严格执行，出现过一次锁表现象。场景是这样的：Django的定时统计任务对payment表做了一次全表聚合查询，查询期间SSM端恰好对payment表执行批量写入，然后写入操作一直卡着不动。

排查链路是这样的：先用SHOW PROCESSLIST;看到有一长串的Waiting for table metadata lock；进一步定位是Django的聚合查询事务迟迟没有提交，把元数据锁捏在手里不放。解决完这次问题，我做了三件事：把聚合查询的SQL改成SELECT COUNT(*)取代全表扫描；给所有Django查询显式加了只读事务设置；彻底执行了账号读写分离。

这个案例值得单独说，是因为它说明了一个原则：共享数据库不等于共享写权限，边界的清晰程度决定了稳定性。

6.4 静态资源404，半天排查结论原来是拦截器搞的鬼

在JSP时代写页面，静态资源的路径踩坑率极高。SpringMVC的DispatcherServlet默认会拦截所有URL包括js/css，如果没有显式放行，页面引用的/static/js/app.js就会被当成Controller请求去匹配，找不到就404。

配置放行之后又出现一个更隐蔽的问题：页面里写的是static/js/app.js，但项目目录下实际路径和引用路径大小写不一致，在某些区分大小写的Linux系统上直接404。排查时先按Ctrl+F5硬刷新，排除浏览器缓存因素，再用开发者工具Network面板看请求URL和实际文件路径的差异。这一步往往就能把问题锁定。

6.5 部署方案对比，从本地到云服务器的取舍

这套系统最终的交付形式一般有两种：Windows本地演示，或者部署到云服务器供远程访问。本地部署最简单，装好JDK、MySQL、Python和Tomcat，按README跑脚本即可。云服务器部署我推荐用Docker Compose，把MySQL、SSM应用、Django服务三段撑起来：

version: "3" services: mysql: image: mysql:5.7 command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci environment: MYSQL_ROOT_PASSWORD: 123456 MYSQL_DATABASE: dorm ports: - "3306:3306" ssm-app: build: ./backend-ssm ports: - "8080:8080" depends_on: - mysql django-service: build: ./tool-django ports: - "8000:8000" depends_on: - mysql

这个Compose配置里最关键的是MySQL的command参数，一定要带上utf8mb4字符集设置，否则即使代码里全部用了utf8mb4，容器的默认字符集还是latin1，一切白搭。部署完成之后自测一遍：登录、入住、退宿、导出报表、定时任务，全链路走通再交付。

最后再分享一个交付小细节：不管项目用什么技术栈，交给别人的时候一定要附一个部署自检清单.md，照着一条条打勾。因为源码能跑起来是第一位的，文档写得再漂亮，环境起不来就都是零。这套系统从需求分析、数据库设计到双端联调、文档整理，全程走下来，我最想保留的经验其实就是这一句话：把给别人的东西，当成自己第一次拿源码时最希望拥有的东西来准备。愿这套系统也能帮你少走几步弯路。