企业官网建设流程全解析

每年到选题季，教务处的表格满天飞，学生群里“谁帮我看看还有哪个题能选”刷屏，老师们在邮箱里翻学生发来的选题申请。我做过好几个版本的选题系统，这个基于 Java + Python + MySQL 的 Web 版是最满意的一个。不是说它功能多华丽，而是它把三方分工做得特别清楚：Java 扛住 Web 交互和业务规则，Python 负责批量数据处理和自动化任务，MySQL 存住所有状态。整套东西跑下来，稳定、省心，而且源码不复杂，改起来很快。

这套系统适合几类人参考：正在做课程设计或者毕业设计的计算机专业学生，想给院系搞一个内部选题工具但不想买商业系统的教务老师，以及刚接触 Web 全栈、想看看 Java 和 Python 怎么在一个项目里配合的开发者。我会把整体设计思路、数据库怎么建模、核心业务怎么落地、踩过哪些坑，全部拿出来说。

1. 内容整体设计与思路拆解

1.1 为什么要用 Java + Python + MySQL 三个技术栈

很多人在做一个 Web 系统时习惯一套技术走到底，比如全 Java 或者全 Python。我这次刻意没用单一语言，原因是选题系统这个场景天然分成两条线。

第一条线是在线业务：学生登录、浏览题目、提交选题、教师审核、管理员管理。这条线要求稳定、并发可控、事务可靠，Java 的 Spring Boot 生态在这块非常成熟，尤其是事务控制和权限框架，写起来心里踏实。

第二条线是离线数据处理：学期开始时要导入大量学生名单和教师信息，通常是以 Excel 形式存在；学期结束时要把选题结果导出成各种统计报表，还要给没选上题的学生发通知。这种工作 Python 的 pandas、openpyxl 处理起来太顺手了，而且写一些自动化脚本（定时统计、生成报表）比 Java 轻量太多。

MySQL 则是整个系统的数据底座，不管是 Java 写入的业务数据还是 Python 处理后的结果数据，都统一落在 MySQL 里。三者各司其职，没有谁在硬扛自己不擅长的活。

1.2 角色权限与核心业务流程

我在设计这个系统时没有一上来就写代码，而是先认认真真梳理了业务场景里的角色和流程。选题系统实际涉及三类角色：

• 管理员：维护基础数据，包括学期设置、专业班级、教师账号、学生账号；审核教师提交的题目；监控选题进度；手动处理异常情况。
• 教师：申报题目（包括题目名称、方向简介、可选人数、面向专业）、审核学生选题、查看自己名下的选题名单、录入评分或评语。
• 学生：浏览可选题目、查看每个题目的剩余名额实况、提交选题（通常有一轮正选和一轮补选）、查看最终结果。

核心流程是这样一条链：教师申报题目 → 管理员审核开放 → 学生在规定时间内选择 → 教师确认或拒绝 → 管理员协调调剂。这个流程看着简单，落到系统里就会牵扯出一个关键问题：状态机设计。每个题目有状态（草稿、待审核、已开放、已满员、已关闭），每条选题记录也有状态（待确认、已通过、已拒绝、已调剂），如果状态设计不好，后面查数、统计全是坑。

我最终用的状态流转方式是：题目的所有状态变化都记录在日志表里，JS 端只允许按照预定义的流转方向操作，后端再校验一次。这样可以避免“教师把已满员的题目又打开”这种逻辑混乱。

1.3 为什么选 MySQL 而不是别的数据库

关于 MySQL 的选择，网上讨论很多。我的实际感受是：对于这种中等规模（几百个题目、几千个学生）的 Web 应用，MySQL 是性价比最高的选择。它上手容易、文档丰富、主从部署也不复杂，而且 Java 的 MyBatis/JPA 和 Python 的 SQLAlchemy/PyMySQL 都原生支持得很好。相比 PostgreSQL，MySQL 在安装、运维和容器化部署上对新手更友好；相比 NoSQL，选题系统的数据关联性强、事务要求高，根本不适合用文档型或 KV 型数据库。

2. 核心细节解析与实操要点

2.1 数据库表结构设计：先想清楚再动手

这套系统的表结构我迭代过两版。第一版把教师和学生的信息全塞在一张 user 表里，用一个 role 字段区分，结果后期要为不同角色加字段时，表变得非常臃肿。第二版拆成了多表设计，清爽了很多。核心表如下：

用户相关：

• user：主账号表（id, username, password_hash, role, status, created_at），统一存登录凭据
• student_profile：学生扩展表（user_id, student_no, name, major, class_name, grade, email），存学生学籍信息
• teacher_profile：教师扩展表（user_id, teacher_no, name, department, title, email），存教师信息

业务相关：

• topic：题目表（id, teacher_id, title, description, capacity, selected_count, status, audit_status, created_at, deadline）——selected_count是已选人数，capacity是上限
• selection：选题记录表（id, student_id, topic_id, status, selection_time, confirm_time, note）
• semester：学期设置表（id, semester_name, start_time, end_time, is_current）
• operation_log：操作日志表（id, user_id, action, target_type, target_id, detail, created_at）

加粗的字段都是查询和统计的高频字段，在真实环境里必须建索引。我吃过一次亏：一开始表数据量不大没在意，后面学生选课时一拥而入，系统开始变慢，才发现少了联合索引。哪些地方需要建立索引？我在实践中的规则很简单：

• 高频查询条件字段（如 student_no、topic_id）
• 外键字段（如 selection 表的 student_id 和 topic_id）
• 状态字段加上时间字段的联合查询（如 index(status, created_at)）

索引不是越多越好，写多读少的表（比如日志表）就尽量少建索引，避免写入变慢。

2.2 把并发控制在数据库这一层

回到刚才提到的selected_count字段。这个字段听起来简单，但它是整个系统并发问题的核心。给学生开放选题那一刻，会出现一个非常典型的场景：某个题目只剩最后一个名额，同时有 10 个学生在点“选这个题”，如果系统写的代码是先查数量、判断没满、然后再更新，那这 10 个请求有可能全部通过判断，最后把名额爆掉。

我采用的方案是数据库乐观锁 + 事务补偿。

具体做法分三步：

1. 在topic表增加一个version字段，每次更新时带上版本号。
2. 更新语句写成原子操作，在一条 UPDATE 中同时判断capacity是否还有富余：

UPDATE topic SET selected_count = selected_count + 1, version = version + 1 WHERE id = #{topicId} AND selected_count < capacity AND status = 'OPEN'

通过受影响行数判断是否抢到名额。受影响行数为 0，说明题目已满或状态不对。

3. 在selection表插入记录时，用数据库唯一约束防止同一学生同学期重复选课：

ALTER TABLE selection ADD UNIQUE KEY uk_student_semester (student_id, semester_id);

这个组合拳打完，再也没有出现超选或者一人选多题的情况。很多网上代码喜欢在 Java 层用 synchronized 或者分布式锁控制，我强烈建议你把锁下沉到数据库，这样不仅代码简单，而且天然支持多实例部署。

2.3 Java 后端：接口设计尽量贴合业务流转

因为我做的是选题系统，不是纯 CRUD，接口设计要对应业务动作。我在这个项目里没有把一个实体简单暴露成五个接口，而是按业务动作命名，比如：

• POST /api/topic/create（教师申报题目）
• POST /api/topic/{id}/audit（管理员审核）
• POST /api/student/selectTopic（学生提交选题，内部走事务）
• POST /api/student/cancelSelection（学生在未确认前可取消）
• POST /api/teacher/confirmSelection（教师确认或者拒绝）
• GET /api/student/availableTopics（学生查看可选题目，并且实时显示剩余名额）

每个接口都做三件事：参数校验、权限校验、业务处理。

对了，权限校验这里有个经验教训，千万不要只在 Controller 里写一套 if-else 判断角色。项目里我用的是 Spring Security + 自定义注解，直接在 Controller 方法上标注@PreAuthorize("hasRole('TEACHER')")，代码干净得多。

还有参数的校验，选题系统的参数不算复杂，但是容易踩坑的是一些“数字边界”问题：比如教师填了一个负的容量、忘记填截止时间等。我引入了javax.validation，在实体字段上用@NotNull、@Min(1)这类注解，省下大量冗余判断代码。

2.4 Python 脚本：批量导入导出与自动通知

说句实话，选题系统中不少让人头疼的活都是靠 Python 这个副手搞定的。我的项目里有三个 Python 脚本非常实用。

第一个是批量导入脚本import_data.py。每学期开始，管理员手里是教务处的 Excel 名单，如果靠人工往系统里录，几千个账号录到怀疑人生。脚本用 pandas 读 Excel，把学号、姓名、专业、班级、邮箱逐行校验，然后批量生成加密密码（用 werkzeug 库的 generate_password_hash，保证和 Java 端存储格式兼容），最后批量插入 MySQL。几千条数据几十秒就搞定，而且脚本里做了重复学号检查，不会把数据库搞脏。

第二个是截止自动处理脚本close_selection.py。选题窗口一到，系统要自动关闭未确认的题目，给未选题的学生发提醒邮件。Python 端用 APScheduler 定时任务，每天调用一次，查询当前学期所有处于开放状态的题目，如果超过截止时间就更新状态，并且找出还没有有效选题记录的学生，调用邮件接口发提醒。

第三个是结果统计脚本export_report.py。学期末管理员要交一份全校选题统计表（各专业选题率、各教师题目热度、未选题学生名单），这个脚本直接用 SQL 跑几个聚合查询，pandas 处理成 DataFrame，再 openpyxl 写入 Excel，格式、字体、列宽都调好了，导出就能写报告。

很多做 Java 的人一听到要写 Python 就反感，其实这种配合完全可以做成进程外的方式：Java 系统只负责业务操作，Python 脚本独立部署在定时任务里，两边不直接函数调用，而是通过数据库和文件系统协作。这样互不干扰，Java 挂了也不影响 Python 清数据。

3. 实操过程与核心环节实现

3.1 环境搭建与项目结构

我的标准开发环境是三件套：JDK 17、Python 3.10、MySQL 8.0。项目是标准的 Spring Boot 多模块结构，我习惯把前后端干干脆脆地分开：

course-select-system/ ├── backend-java/ # Spring Boot 后端 │ ├── src/main/java/com/example/courseselect │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务层 │ │ ├── mapper/ # MyBatis Mapper 接口 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 安全配置、跨域配置 │ │ └── common/ # 统一返回体、异常处理 │ └── src/main/resources/mapper/ # XML SQL ├── frontend-web/ # 前端，我是用的 Vue3 ├── scripts-python/ # Python 辅助脚本 │ ├── import_data.py │ ├── close_selection.py │ ├── export_report.py │ └── requirements.txt └── docs/ # 数据库设计文档和部署文档

前端用 Vue3 + Element Plus 开发，通过 axios 调后端接口，JWT 做登录态。前端不是这篇文章的重点，但如果想快速跑起来，可以让 Java 后端直接返回模板页面（用 Thymeleaf），牺牲一点交互体验，但开发和部署会简单很多。

3.2 数据库脚本：建表 DDL 参考

因为篇幅有限，我挑最重要的三张表给你看一眼，完整 DDL 我放到项目文档里。

user 表

CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(64) NOT NULL COMMENT '登录账号', `password_hash` varchar(255) NOT NULL COMMENT '密码哈希', `role` varchar(20) NOT NULL COMMENT 'STUDENT / TEACHER / ADMIN', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1正常 0禁用', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

topic 表

CREATE TABLE `topic` ( `id` int NOT NULL AUTO_INCREMENT, `teacher_id` int NOT NULL, `title` varchar(200) NOT NULL, `description` text, `capacity` int NOT NULL DEFAULT '5' COMMENT '可选人数上限', `selected_count` int NOT NULL DEFAULT '0' COMMENT '已选人数', `version` int NOT NULL DEFAULT '0' COMMENT '乐观锁版本号', `status` varchar(20) NOT NULL DEFAULT 'DRAFT' COMMENT 'DRAFT/PENDING/OPEN/FULL/CLOSED', `audit_status` varchar(20) NOT NULL DEFAULT 'PENDING' COMMENT '待审核/通过/驳回', `semester_id` int NOT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_teacher` (`teacher_id`), KEY `idx_semester_status` (`semester_id`, `status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

selection 表

CREATE TABLE `selection` ( `id` int NOT NULL AUTO_INCREMENT, `student_id` int NOT NULL, `topic_id` int NOT NULL, `semester_id` int NOT NULL, `status` varchar(20) NOT NULL DEFAULT 'PENDING' COMMENT 'PENDING/APPROVED/REJECTED/REASSIGNED', `selection_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `confirm_time` datetime DEFAULT NULL, `note` varchar(500) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_student_semester` (`student_id`, `semester_id`), KEY `idx_topic` (`topic_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

建表的时候有两个细节值得提醒：第一，所有表都用utf8mb4字符集，避免生僻字、数学符号存进去变成问号。第二，外键约束我故意没有加，物理外键在读写频繁场景下会影响插入性能，业务层去保证数据一致性就够了。

3.3 Java 核心逻辑：事务内完成选题

选题接口是全系统最核心的代码，我贴一下 Service 层的关键逻辑：

@Transactional(rollbackFor = Exception.class) public SelectionResult selectTopic(SelectTopicRequest request) { Long studentId = request.getStudentId(); Long topicId = request.getTopicId(); Long semesterId = request.getSemesterId(); // 1. 校验学生是否已经选过 int count = selectionMapper.countByStudentAndSemester(studentId, semesterId); if (count > 0) { throw new BusinessException(400, "你本学期的选题已经提交，不能重复选择"); } // 2. 原子抢占名额 int rows = topicMapper.decrCapacityIfAvailable(topicId); if (rows == 0) { throw new BusinessException(400, "该题目名额已满或已关闭"); } // 3. 插入选题记录 Selection selection = new Selection(); selection.setStudentId(studentId); selection.setTopicId(topicId); selection.setSemesterId(semesterId); selection.setStatus("PENDING"); selectionMapper.insert(selection); // 4. 记录操作日志 logMapper.insert("STUDENT_SELECT", studentId, "topic", topicId, "学生提交选题"); return SelectionResult.success(selection); }

这段代码最重要的就是@Transactional和update ... where selected_count < capacity配合。没有事务，前面 UPDATE 成功了，后面 INSERT 万一失败，名额就被白白扣掉了。没有原子更新，并发场景直接超卖。

3.4 Python 脚本：Excel 数据清洗与入库

再贴一个 Python 导入脚本的核心逻辑，你感受一下它做数据清洗有多顺手：

import pandas as pd from sqlalchemy import create_engine, text from werkzeug.security import generate_password_hash engine = create_engine("mysql+pymysql://root:password@localhost:3306/course_select?charset=utf8mb4") def import_students(excel_path, semester_id): df = pd.read_excel(excel_path, dtype={"学号": str}) default_password = "123456" # 校验：学号必须唯一，18位 if df["学号"].duplicated().any(): raise ValueError("Excel中存在重复学号") rows = [] for _, row in df.iterrows(): student_no = row["学号"].strip() name = row["姓名"].strip() major = str(row.get("专业", "")).strip() class_name = str(row.get("班级", "")).strip() # 统一处理邮箱，缺失的生成默认邮箱 email = str(row.get("邮箱", "")).strip() if not email or email == "nan": email = f"{student_no}@school.edu.cn" rows.append({ "username": student_no, "password_hash": generate_password_hash(default_password), "role": "STUDENT", "status": 1, "student_no": student_no, "name": name, "major": major, "class_name": class_name, "email": email, "semester_id": semester_id, }) # 事务插入 with engine.begin() as conn: # 先插 user 表拿 id for r in rows: result = conn.execute(text(""" INSERT INTO user (username, password_hash, role, status) VALUES (:username, :password_hash, :role, :status) """), r) user_id = result.lastrowid conn.execute(text(""" INSERT INTO student_profile (user_id, student_no, name, major, class_name, email, semester_id) VALUES (:user_id, :student_no, :name, :major, :class_name, :email, :semester_id) """), {**r, "user_id": user_id}) print(f"成功导入 {len(rows)} 名学生") if __name__ == "__main__": import_students("students_2025_spring.xlsx", semester_id=1)

有个小细节：pandas 读 Excel 时，学号这种数字列很常被读成 float，比如20210001变成20210001.0，所以读取时一定要指定dtype={"学号": str}，否则后期匹配账号全是坑。

4. 常见问题与排查技巧实录

4.1 并发选课出现“超选”和“回滚失败”

我第一版上线的时候没有用乐观锁，结果第三天就出事了。某个抢手题目容量是 3，最后实际选了 5 个学生，把老师和学生全搞炸了。

第一次修复我加的是 Java 层的synchronized，但只对单机有效，而且锁粒度太大，体验很差。后来才改成数据库原子更新 + 版本号。这里有个排查小技巧：你可以通过慢查询日志看到多条UPDATE topic SET selected_count = selected_count + 1的语句在同一秒执行，如果发现UPDATE影响了多行（正常应该最多一行），那就说明原子条件没起作用。

4.2 中文乱码：字符集问题从根源上解决

中文乱码几乎每个新人都会遇到。我之前排查一个 bug：Java 后端写入数据库的名字正常，但 Python 读出来是乱码；或者反过来，Python 导入的数据在 Java 界面显示乱码。最后定位到三个环节必须保持一致：

• 数据库连接：Java 的 JDBC URL 加characterEncoding=utf8mb4，Python 的 SQLAlchemy URL 加charset=utf8mb4
• 建表字符集：统一CHARSET=utf8mb4
• HTTP 响应头：Content-Type: application/json; charset=utf-8

只要这三处统一，乱码基本绝迹。还有一个侧面试探法：如果乱码表现为“???”这种问号，说明字符在传输过程中直接丢了；如果表现为“温æ±åº¦”这种乱码形态，说明字符编码被错误转换了，往往是 Connector 的编码参数问题。

4.3 MySQL 8.0 认证插件和 SQL 模式差异

用 MySQL 8.0 时，caching_sha2_password认证插件经常让旧版客户端连不上，Python 的 PyMySQL 如果版本太旧，会遇到Authentication plugin 'caching_sha2_password' cannot be loaded。这个问题可以在连接串里指定mysql+pymysql://然后升级 PyMySQL 版本解决，也可以创建一个使用mysql_native_password的账号。

另外 8.0 的默认sql_mode比 5.7 严格，常见的情况是ONLY_FULL_GROUP_BY导致聚合查询报错。如果遇到Expression #N of SELECT list is not in GROUP BY clause，不要只想着加ANY_VALUE()，先把 SQL 逻辑调整对，再考虑放宽模式。

4.4 选题时间窗口控制失败

系统上线时我用 Java 判断当前时间是否在选题窗口内，但测试发现总有学生能在非窗口时间提交成功。排查后发现是管理员把服务器时区设成了 UTC，导致时间偏移了 8 小时。我后来做了两处修正：统一所有环境（数据库、Java JVM、服务器）的时区为Asia/Shanghai，并且不在代码里写死时区，而是从配置中心读取；关键的时间判断逻辑必须在后端校验，不能只在前端做。定时任务脚本close_selection.py也加了一次兜底检查，发现非窗口时间的提交直接回滚。

4.5 数据库连接池耗尽

选题开始时流量突增，某天下午系统突然出现大量Connection pool exhausted报错。我检查了配置，默认的 HikariCP 最大连接数是 10，对一个小系统来说平时够用，但在高并发窗口期完全扛不住。我把maximum-pool-size调到了 50，同时给接口层加了简单的限流（针对单用户：一分钟最多选 5 次），双管齐下后没有再出现这个问题。排查连接池情况有一条命令很实用：

SHOW STATUS WHERE Variable_name LIKE 'Threads_connected';

如果这个数字长期接近最大连接数，说明池子不够用，或者有连接泄漏。连接泄漏往往是事务里执行业务代码太慢，或者异常分支没走完释放连接导致的，排查时重点看日志里是否有大量长时间未提交的事务。

4.6 前后端点不了名：跨域问题

本地开发时前端跑在 5173，后端跑在 8080，每次请求都被浏览器拦腰截断，报CORS policy错误。我一开始在 Controller 上加@CrossOrigin注解解决，后来觉得过于零散，就统一加了一个 CORS 配置类，允许指定前端域名。上线后我直接把跨域配置去掉，用 Nginx 把前后端放在同一个域名下面，彻底避免跨域。如果你用 Nginx，在 server 块里加一段反向代理配置：

location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

4.7 问题速查表

5. 一些部署和运维层面的经验

这个话题本来不在原计划里，但每次部署这套系统都会遇到同样的问题：打包、启动、守护进程。Spring Boot 的 jar 包打出来就能跑，Python 脚本扔到 crontab 里就能定时执行，但怎么把 MySQL 配置好、怎么管理环境变量、怎么做好日志，这些细节往往决定系统的稳定性。

我自己的部署方案是：服务器用 Ubuntu，Java 服务通过 systemd 注册成守护进程，Python 脚本用虚拟环境隔离依赖，MySQL 用 Docker 配合数据卷管理。三个服务都配了独立的日志输出文件，日志滚动策略统一按天切割。这样即使系统出问题，查日志也很快就能定位。

文件上传路径（比如教师上传的题目附件）不要写在项目源码里，应该放到独立的目录或对象存储，Java 服务的配置里只写相对路径，启动时通过环境变量注入绝对路径。Python 脚本的数据库连接信息也不能硬编码，我从环境变量读取，这样不同环境（开发、测试、生产）切换不用改代码。

还有一个容易忽略的点：Java 服务启动脚本里要设置JAVA_OPTS="-Xms256m -Xmx102m"，不然默认堆大小会根据物理机内存自动分配，小内存机器上容易出现内存抖动。Python 定时任务如果处理的数据量大，建议使用分批次读取和提交，避免内存暴涨。

6. 一点总结和实操心得

做到这里，这套选题系统的轮廓已经完全清晰了。它不是一个纯 Java 项目，也不是纯 Python 项目，而是一个“Java 负责在线业务 + Python 负责离线数据 + MySQL 统一存储”的组合型 Web 应用。如果你打算照着做一个，我的建议是先把业务规则列清楚（谁在什么时间能做什么事），再设计表结构，最后再编码。因为表格和规则一旦定错，后面改起来成本极大。我第一版就是没想清楚状态流转，数据库都建好才开始梳理角色，结果推翻了小半个数据库设计。

我个人在实际操作中最大的体会是：不要把技术栈当成包袱，每个环节用最适合的工具。以后如果再扩展积分制选题、跨专业选课或者移动端适配，这套架构依然有足够的扩展余地；Java 有丰富的生态，Python 有灵活的数据处理能力，MySQL 有可靠的存储和事务保障，三者配合起来是一个很稳定的组合。

最后再分享一个小技巧：如果你在开发时经常被“账号密码忘了”“测试数据不对”这些琐事干扰，可以让 Python 脚本顺带生成一批模拟数据（学生、题目、选择记录），用真实数据量的百分之一做压测，这比手动造数高效得多。系统上线后，这批脚本收敛好权限，交给管理员使用，就是一套很实用的运维工具。