企业官网建设流程全解析

1. 校园平台的边界在哪里：先划清功能域再动手

1.1 智慧校园不等于“把OA搬到手机上”

接手这类项目之前，我建议大家先想清楚一件事：智慧校园综合服务平台到底要解决谁的什么问题。很多第一次做校园系统的开发者，最容易犯的毛病是照着网上某个“校园管理系统”的截图列功能，学生管理、教师管理、课程管理堆了一大堆菜单，结果做出来只是一个CRUD大杂烩，没有任何一个角色觉得好用。

我自己的理解是，校园平台的核心价值在于把学校里离散的业务串起来。学生在移动端查课表、选课、查成绩、扫码吃饭，老师在后台录入成绩、审批请假、发布作业，教务处要能拿到各种统计报表，宿管要能管寝室调换和报修，财务要能对账。这些角色需要的不是一堆孤立的功能页面，而是几个完整的业务闭环。所以设计开始前，我花了两天时间把所有能想到的角色和业务场景列了一张大表，再对照学校实际的组织架构去重合并，最后才落到功能清单上。

这张表本身也建议你保留着，后面无论是做数据库设计、写接口文档，还是被甲方或者导师追问“为什么有这个功能”，都用得上。

1.2 选型决策：单体优先，别一上来就拆微服务

技术选型上，我强烈建议这一类项目直接走SpringBoot单体应用，最多按模块拆包。原因很现实：校园平台的特点是业务广、并发量没那么极端、开发周期紧，微服务引入的注册中心、配置中心、链路追踪、分布式事务，对三五个人甚至一个人开发的项目来说是纯粹的负担。

版本选择上，SpringBoot 2.7.x搭配JDK 8其实是这类项目最稳妥的组合，不要为了追新用SpringBoot 3强行上JDK 17，很多老教材、老依赖对不上号，排错的时间远大于收益。配套的持久层框架MyBatis-Plus足够应付绝大多数CRUD和分页需求，权限用Spring Security或者Sa-Token，缓存Redis，定时任务用Spring自带的@Scheduled就够，消息通知先用数据库表模拟站内信，这些都已经是很成熟的组合。

技术栈确定之后，项目结构我习惯按业务域分包，而不是按技术层分包。也就是说，把controller、service、mapper放在同一个业务包下面，比如student包、course包、approval包，而不是传统的controller包、service包分层。这个习惯在业务多的项目里找代码特别顺手，改一个业务模块不用在四个包之间跳来跳去。

1.3 角色模型必须先于代码存在

校园系统的角色划分要比一般企业系统复杂。常见的有学生、教师、辅导员、院系教务员、教务处管理员、宿管、财务、系统管理员八大类，而且同一类角色不同层级权限也不一样，比如辅导员只能管自己带的学生，院系教务员能管整个学院，教务处能管全校。

权限模型我建议老老实实用基于角色的访问控制，五张核心表：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户和角色多对多，角色和菜单多对多就够了，不要一开始就上数据权限框架，那玩意儿在毕设和中小型真实项目中基本用不上。数据权限（比如辅导员只能看到本院学生）完全可以在SQL层面手动加一个条件，用一个上下文工具类从登录态里取出当前用户的归属院系和角色，然后拼到查询条件里，比引入复杂框架容易理解得多。

这里要特别注意：登录功能不能只存用户名密码然后顺手put进session就完事。Token的生成、过期、续期、注销、多端登录互踢，这套逻辑要提前想清楚。我用的是Sa-Token，它对这类单体项目支持很友好，注解式鉴权一行搞定，比Spring Security的配置门槛低不少。

2. 数据模型是这类系统真正的护城河

2.1 主数据表设计：学号、工号与人员状态的几种做法

人员主数据是整个系统的地基，学号、职工号既是业务标识，也是很多查询条件的索引。这里有个设计分歧值得说：到底以学号作为主键，还是用自增ID主键加学号唯一索引？我的习惯是自增ID做主键，学号加唯一索引，理由有两点：一是很多业务表需要引用人员ID，自增整数做外键比字符串更省空间；二是万一学校学号规则调整（这种事真实发生过），改业务主键的代价远大于改唯一索引。

学生表里除了基础字段，一定要预留学院ID、专业ID、班级ID这几个组织归属字段，并且单独建组织架构表（school_org），用parent_id自关联维护层级。这样后面统计“某学院男生人数”“某专业不及格率”这类报表时，一条递归SQL或者内存里先构建树再统计就够了，否则只能靠字符串like去猜，又慢又容易错。

人员状态字段我也建议单独给一个整型status，0表示在读/在职，1表示休学或离校，2表示毕业/离职。很多业务（比如选课、宿舍入住）都依赖状态过滤，有个干净的字段比到处判断时间区间可靠得多。

2.2 选课、成绩、课表这类核心业务的表关系

选课表是这门系统的第一个核心，它承担了三件事：记录学生选了哪门课、记录教学班归属、记录选课状态。表结构建议这样设计：id、student_id、course_id、teacher_id、semester、选课时间、状态字段。这里course_id不要直接指向课程基础表（课程名称、学分、学时），而是指向教学班表（teaching_class），因为同一门课程可能由不同老师开多个平行班，学生选的是某个具体的班次，这个细节前期搞错了后面课表、成绩全都会对不上。

成绩表设计上，我吃过一次亏：最开始只有一张score表，一个学生一门课一条记录，存总评成绩。后来老师要求录入平时分、期末分、补考成绩，还得算加权占比，只能推倒重来。第二次设计我把成绩拆成两层：成绩明细表存储每一次考核项（平时作业、期中、期末）的类型、满分、实际得分；成绩汇总表按学期和教学班存储总评结果。这样无论老师按什么比例算总评，都能在前端灵活设置，明细数据也方便学生查看。

课表其实不建议单独建一张大宽表，而是通过选课关系自动生成：学生选完课，根据教学班的time_slot字段（星期几、第几节、单双周、上课地点、起止周）就能在日历视图上渲染出来。这样数据一致性天然有保障，不会出现选了课但课表里没有的尴尬。

2.3 一卡通消费与余额：被很多设计忽略的幂等

一卡通消费模块是整个系统里最容易出bug的地方。余额表一张、流水表一张，这个好理解，关键是出账逻辑。每次消费操作必须在一个事务里完成：先查余额，判断充足，扣减余额，插入流水，任何一个环节失败都回滚，这个最简单也最可靠。但还有一个隐藏问题：如果网络抖动，客户端没收到扣款成功响应就重试了一次，就会重复扣钱。解决办法是消费接口接收一个全局唯一的流水号（比如请求方生成的UUID），在流水表上建立唯一索引，如果同一个流水号重复插入，数据库直接报唯一键冲突，业务捕获后返回“该笔订单已处理”，这就叫接口幂等。

同样思路的还有充值。在线支付回调接口要允许重复通知，所以支付回调的处理也依赖订单号唯一索引。这个模式建议写到团队开发规范里：所有涉及资金、库存、状态的变更接口，都必须支持幂等。

2.4 避免“万能字段”的诱惑

很多开发者在设计表的时候偷懒，要么是一张表加二十个可空字段，要么把什么扩展信息都往remark字段里塞。校园系统业务多，字段经常变，确实很诱惑人去搞一个“扩展属性”JSON字段一劳永逸，但我经验是：复杂的、需要参与查询和统计的数据一定要独立成字段或子表，单纯作为展示的附属信息可以塞JSON。

举个例子：宿舍报修单需要记录上报人、寝室号、故障描述、报修类型、预约时间、处理人、处理结果、评分。故障描述和处理结果属于文本信息放主表没问题，但报修类型、预约时间这种未来要拿来筛选统计的数据必须单独字段。至于评分，如果你打算做“维修满意度排行”，就得有一张评分明细表，记录评分人、被评人、订单ID、分数、评价内容，否则后面想做数据挖掘也没有素材。

3. 四个典型业务闭环的实现细节

3.1 选课并发：教务系统最怕的抢课场景

选课是校园系统里并发压力最极端的场景，几百人同时抢同一门热门课，如果代码写得糙，数据库行锁等待、死锁、超时全都来了。我的做法分几种情况讨论。

第一种情况，选课人数不多（几百人操作），直接依赖数据库事务就行。逻辑是：在事务里先对教学班的剩余名额进行条件更新：

UPDATE teaching_class SET selected_count = selected_count + 1 WHERE id = #{classId} AND selected_count < max_student

如果影响行数为1，说明名额还有余，可以继续插入选课记录；如果影响行数为0，说明已经满员，直接给前端返回“课程已满”。这条UPDATE语句会锁定对应行，后续请求排队，保证不会超卖。

第二种情况，如果你预计并发量很大（比如全校同一时刻选课），建议引入Redis做预扣减。在Redis里维护key为course:stock:{classId}的库存值，选课时先用DECR命令尝试扣减，返回值大于等于0才继续走数据库落库。这里要用Lua脚本把“检查库存并扣减”做成原子操作，不用Lua的话在并发下还是会有超卖风险。MySQL里库存只是最终一致性兜底，实际判断以Redis为准。

选课还有一个业务细节需要注意：互斥课程。比如某些专业课，选了A课和B课其中一门就不能选另一门。实现方案是在排课表里维护一个conflict_group字段，同一组编号内的课程不能同时选择。校验放在选课事务的最前面，查一次conflict_group，然后查选课表里有没有同组记录，有就拒绝。

3.2 审批流：不引入Flowable也能做出好用的流程

搜“springboot使用flowable”的人很多，但说句实在话，校园系统里最常见的审批场景也就是请假、活动申请、场地申请、设备借用，流程深度普遍只有两到三层。为了这点业务直接上Flowable，带来的表数量、概念复杂度、流程设计器集成成本，对单体项目来说性价比不高。我的方案是用一张流程实例表加一张审批任务表搞定。

核心思路是这样的：每个审批业务都关联一个process_instance记录，包含业务类型、业务ID、当前节点、流程状态。审批任务表每次生成一条待办记录，包含审批人ID、任务节点名称、可否通过/驳回、审批意见、审批时间。每完成一个节点，代码里根据业务类型和当前节点判断下一个节点是谁，生成下一条待办，同时更新流程实例的当前节点。

拿请假举例：学生提交请假申请，创建流程实例，节点为“辅导员审批”，待办给辅导员；辅导员通过后，判断请假天数，小于等于3天流程自动结束，大于3天则创建“院系领导审批”节点；被驳回则流程状态变为“已驳回”，学生端看到驳回意见后可修改重新提交。

这套方案的优点是：表结构简单、流程逻辑完全由代码控制，调试直观，改流程只需要改一套节点路由方法。缺点是需要自己维护流程节点，如果业务方明确说要可视化流程设计器、要支持运行中改流程，那还是老老实实引入Flowable。但从我的项目经验看，90%的校园场景用这套轻量方案就够了，而且面试被问到流程引擎时反而更容易展示你对原理的理解。

3.3 消息通知：从站内信到模板化触达

校园平台的通知场景基本是：流程审批结果通知、成绩发布通知、活动报名成功通知、系统公告。数据库表分notification（通知主表：接收人、标题、内容、类型、是否已读）和notification_template（模板表）就够了。

模板表的意义在于减少重复造字符串。比如成绩通知模板可以写成：“{studentName}同学，您本学期课程《{courseName}》的总评成绩为{score}分，如有疑问请于{date}前联系任课教师。”代码里用占位符替换，模板存在数据库里还能支持管理人员在后台修改措辞，不用改代码重新部署。

发送时机上，审批完成、成绩录入成功这类事件由业务代码同步插入通知；定时提醒（比如明日课程提醒、未提交作业提醒）用Spring的@Scheduled每天定时扫描生成。我当时还加了一个微信扫码绑定手机号的功能，但发现企业微信或钉钉的群机器人推送在学校环境里更实用，这个看对接方的开放平台支持情况，没有统一标准。核心原则是：通知要做到已读回执，读没读是两种产品逻辑，教务老师最关注的是“学生到底看没看到通知”。

3.4 数据看板：别让统计接口拖垮业务库

首页大屏和统计报表是这类系统特别吸睛的功能，但它也是最容易把数据库搞挂的元凶。如果每个图表都实时跑一遍全表聚合SQL，五六张图同时刷新，业务库基本就卡死了。

我的做法是引入一张报表聚合表，比如每日统计课程选课人数、各院系学生人数、本月消费总额，由定时任务每半小时或者每天凌晨跑一次，把聚合结果写进表里。前端接口只查聚合表，不接触业务明细。这样统计数据和实时数据可能有半小时以内的延迟，在校园场景完全够用，换来的却是业务库的绝对安全。

如果某个图表确实需要实时性（比如当前在线人数），那就用Redis的计数器实时增减，定时把快照刷进聚合表，前端查快照就行，没必要实时查库。

4. 安全与权限：多方角色下最容易漏的地方

4.1 越权漏洞：比登录绕过更隐蔽的坑

校园平台角色多，接口也多，越权漏洞是我在代码审查里重点关注的问题。越权分两种：水平越权和垂直越权。垂直越权好理解，学生会去调一个只有管理员能用的接口，用Sa-Token的@SaCheckRole注解就能挡住，但水平越权非常隐蔽：学生A登录后，把请求里的studentId改成学生B的ID，就能查别人的成绩、看别人的消费记录，因为接口没有校验“当前登录人是否有权操作这个ID”。

我推荐的防御方式是两层校验。第一层在接口层用注解确认角色，第二层在Service层拿到当前登录人的上下文，判断请求参数里的ID是否属于本人或者本人管辖范围。比如查询成绩接口，代码逻辑是：

public ScoreVO getScore(Long studentId) { // 从Sa-Token上下文中拿到当前登录学生 Long currentStudentId = StpUtil.getLoginIdAsLong(); if (!currentStudentId.equals(studentId)) { throw new BizException("无权访问他人成绩"); } // 继续业务 }

辅导员查学生成绩的场景则是反方向校验：先取出当前用户归属的班级ID列表，再过滤查询条件里的学生必须归属这些班级。这种校验逻辑写起来不复杂，但很容易漏，建议review时把每个接口的入参都过一遍“这个ID能不能被当前角色操作”。

4.2 文件上传：类型检查不能只信前端

校园系统要传的东西太多了：学生证件照、作业附件、活动海报、报修图片。文件上传功能如果没做好防护，轻则被传一堆垃圾文件占磁盘，重则被人上传可执行脚本直接打穿服务器。后端校验至少要三道：扩展名白名单、文件内容头（Magic Number）检查、上传大小限制。

Content-Type不能作为判断依据，因为请求头可以随便伪造。扩展名也不要只做黑名单，因为你根本堵不全，要做白名单——图片就是jpg、png、webp，文档就是pdf、doc、docx、xlsx。更稳妥的办法是服务端用第三方库读文件头，比如图片文件的头是FF D8 FF，PDF是%PDF，对不上就拒绝。SpringBoot里配置文件上传大小限制：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

这些只是第一层，代码层面还要防止路径穿越，用户传上来的文件名一律不要直接拼到存储路径里，用系统生成的UUID重命名文件，扩展名单独取。我一般都是生成/yyyy/MM/dd/uuid.ext这种结构的存储路径，既避免重名冲突又方便按月归档清理。

存储方式上，如果项目部署在单机或内网环境直接存本地磁盘就行，配好Nginx静态映射对外访问；如果学校有对象存储的资源（MinIO或云OSS），优先接对象存储，好处是文件服务和业务服务分离，后面就算重新部署不影响已有文件。MinIO和SpringBoot集成成本很低，SDK封装得好，半小时能跑通。

4.3 配置与密钥：大多数项目交付时的硬伤

一个我们反复踩过的坑：数据库密码、Redis密码、第三方密钥直接明文写在application.yml里，然后项目代码传Git库。如果课题是毕业设计还好，真实交付项目这么干是要出事的。整理下来我的习惯是这样：

一是敏感配置外置。配置文件通过SpringBoot的--spring.config.additional-location指定外部文件路径，或者直接用环境变量引用，比如${DB_PASSWORD}。程序里不出现任何真实密码。

二是引入jasypt做配置项加密。数据库密码用jasypt加密后写在配置里，启动时通过密钥解密，密钥从部署机器环境变量读取。这样就算代码泄露，别人拿到加密串没有密钥也解不开。

三是协作库处理。Git库里只放application-dev.yml这种开发配置，测试和生产环境的配置由运维在服务器上维护，通过启动参数覆盖。这个习惯能少很多交付之后的扯皮。

5. 性能、部署与联调中的真实槽点

5.1 本地能跑不代表接口快：N+1与分页性能

这类系统列表页特别多：学生列表、课程列表、审批列表、消费流水，开发初期数据量小，随便一对多查出来循环里再查一次也不觉得慢。等学期结束数据量上来，几百个学生的列表页转圈转十几秒，才开始着急。

典型的N+1问题就是查列表时先查主表，再循环查关联表。解决方法很简单：MyBatis-Plus里用selectBatchIds批量查出关联数据，在内存里组装，或者直接写联表SQL一次查出来。JOIN的代价在千万级以下的数据量上完全可控，校园系统单表撑死几十万条，大胆用联表查询比折腾什么宽表、搜索引擎实际得多。

分页也遇到过坑：MyBatis-Plus的Page默认会执行count查询，数据量大了count很慢。我们的优化是重写count SQL，去掉多余的LEFT JOIN，只count主表，因为列表查询里JOIN只是为了取名称字段，不会改变记录条数。这个改动在一些大表上效果立竿见影，从两秒多降到几十毫秒。

5.2 大批量操作：Excel导入和成绩导出

教务老师最喜欢的一招是给你一个Excel表说“把这些学生导进去”“把这学期成绩导进去”。如果按单条循环insert，几千条数据也能跑完就是慢，而且中途失败不好处理。我的方案是：

• 服务端用EasyExcel解析文件，它流式读取，不会像POI一次性把整个工作簿加载进内存把JVM撑爆；
• Excel的行数据先做校验（学号格式、是否重复、学院是否存在），错误行收集起来生成错误提示Excel返回给前端；
• 合法数据分批批量插入，MyBatis-Plus的saveBatch默认1000条一批，事务拆成多段，避免单事务过大锁表时间过长。

导出也有讲究，如果导出量大直接同步写文件会让HTTP请求长时间无响应。我常常用异步任务加消息提示的方案：用户点导出，后台起一个线程生成Excel，生成完写入服务器临时目录，同时插一条通知消息“导出的文件已生成，点击下载”，用户不用傻等页面转圈。这个体验在真实交付里非常加分。

5.3 私有化部署：一套Docker Compose解决大部分问题

校园系统最终的部署环境非常多样，有时是学校机房一台老旧服务器，有时是虚拟化平台开出来的两台云主机，甚至可能要求装在一台Windows Server上。为了让交付不因为环境差异翻车，我一般会准备一套Docker Compose编排文件，把MySQL、Redis、Nginx、应用服务全部编排好，一台机器一条命令启动。

这里有几个环境差异的细节必须提前处理：

• MySQL的字符集要显式指定utf8mb4，否则中文和emoji会有乱码，排序规则用utf8mb4_general_ci就够了；
• MySQL 8的认证插件默认caching_sha2_password，老项目JDBC驱动版本不匹配会连不上，要么驱动升到8.x，要么建用户时指定mysql_native_password；
• Redis如果没有特殊需求不要开持久化，校园场景里缓存丢失最多就是重新查库，开了RDB反而会有启动时fork主线程卡顿的问题；
• Nginx配置中client_max_body_size要调大，默认1MB会直接导致上传图片失败，还会返回一个让人摸不着头脑的413错误。

JVM参数也要给够，我一般给应用容器设置-Xms512m -Xmx1024m，如果是4核8G的机器，这个配置能让系统在高峰期选课和日常业务同时跑都很从容。

6. 项目汇报或面试回顾时，这些点一定要能讲透

做这类SpringBoot系统，技术本身不是难点，难的是把每个设计决策背后的理由讲清楚。不管是毕设答辩还是找工作面试，一定有人追着问“为什么这么设计”，最容易被问到的几个问题我这几年几乎每次都遇到。

第一个：“为什么选SpringBoot而不是SSH”。这个问题意在考察你有没有横向对比过技术方案。我说的是：校园系统的核心诉求是快速交付和稳定运行，SpringBoot的自动装配大幅减少了配置模板代码，内嵌Tomcat让部署从装容器变成直接跑jar，配合Spring生态的组件能很快把模块搭起来；SSH时代的XML配置和依赖管理成本，在这个项目里没有收益。

第二个：“SpringBoot的自动配置原理”。这题几乎是必考，不止面试，自己写系统遇到诡异的bean冲突问题也得靠它排查。关键是理解@SpringBootApplication三个注解的作用，其中@EnableAutoConfiguration会通过AutoConfigurationImportSelector加载META-INF/spring.factories里的自动配置类，配合@ConditionalOnClass、@ConditionalOnMissingBean这些条件注解实现按需装配。完整链路能从注解讲到加载机制，面试官基本会认可。

第三个：“事务失效的场景”。事务是校园系统里最容易出问题的一环，我踩过的坑包括：方法被final修饰导致代理失效、同类内部方法调用绕过代理、异常被catch吞掉导致事务不触发回滚、@Transactional加在非public方法上。每一类我都建议准备一个实际出过的例子，比背概念强得多。

第四个：“缓存和数据库一致性问题”。选课场景里Redis和MySQL都有同一门课的数据，一旦Redis更新失败就会出现数据不一致。我的方案是优先更新数据库，然后删除缓存而不是更新缓存，下次请求再回源数据库加载。这个方案叫Cache Aside Pattern，虽然是老方案，但胜在简单可靠，面试时倒是能和面试官聊聊延迟双删、binlog订阅方案为什么更复杂，什么时候才值得上。

第五个：“你的系统是怎么处理并发选课的”。这个问题实际上在考察并发控制和幂等。把我前面讲的条件UPDATE方案讲出来，再补充一句“为了避免重复选课，选课记录表建了studentId加teachingClassId的唯一索引”就够了。能把并发选课这类业务问题讲得清楚，比背十个Redis八股文拿分多。

最后分享一个我在这类项目里反复想明白的道理：所谓“系统设计实现”，真正值钱的不是在多少个库里建了多少张表，而是每一个业务场景背后你都想清楚了它为什么存在、异常情况下系统会怎么表现、数据出错了怎么兜底。做一个智慧校园平台，学到的写码技术是一部分，更重要的是养成一种思维方式——拿到一个业务需求，先问边界、再设计数据、最后才写代码。这套思考习惯，不管以后做什么系统都用得上。