背景痛点：传统管理方式的效率瓶颈

每到毕业设计季，计算机系的老师们就要开始头疼了。过去几年，我们一直用 Excel 表格来管理毕设题目，学生通过邮件或者线下找老师沟通选题。这种方式在初期看起来简单直接，但随着学生数量增加，问题就暴露无遗了。

最典型的问题有三个：首先是选题冲突，经常出现多个学生同时看中同一个题目，先到先得全靠手速和运气，甚至出现过学生私下“交易”选题顺序的情况。其次是题目重复，老师们各自出题，缺乏统一的查重机制，导致相似甚至相同的题目反复出现，降低了毕设的质量。最后是流程混乱，从题目申报、审核、发布、选题到最终确认，整个流程状态分散在多个 Excel 表和聊天记录里，追踪进度非常困难，经常需要反复沟通确认。

这些问题不仅消耗了老师和学生大量的时间和精力，也影响了毕设工作的严肃性和公平性。我们需要一个系统化的解决方案。

技术选型：为什么是 Spring Boot + MyBatis-Plus？

在技术选型阶段，我们主要考虑了三个方向：基于 Python 的 Django、基于 JavaScript 的 Node.js 生态，以及基于 Java 的 Spring Boot。最终选择 Spring Boot，主要基于以下几点考虑：

1. 团队技术栈匹配：项目组核心成员都是 Java 背景，对 Spring 生态熟悉，学习成本和开发风险最低。
2. 企业级应用成熟度：对于管理类系统，事务管理、安全性、与各种中间件（如 Redis、消息队列）的集成方面，Spring Boot 的生态更为成熟和稳定，社区支持强大。
3. 性能与可维护性：Java 的强类型和 Spring Boot 的约定大于配置，使得项目结构清晰，后期维护和迭代更方便。虽然启动速度不如 Node.js，但运行期的性能对于我们的并发量（预计峰值百人同时选题）完全足够。

在持久层框架上，我们对比了 JPA 和 MyBatis-Plus。JPA 的自动建表、对象化操作非常优雅，但对于毕设题目管理这类业务，动态查询条件较多（如按导师、专业、难度、关键词等多维度筛选题目）。MyBatis-Plus 在提供类似 JPA 的便捷 CRUD 操作（通过 ServiceImpl 和 QueryWrapper）的同时，保留了编写复杂 SQL 的灵活性，并且在动态构建查询条件时更加直观。性能上，两者在常规操作上差异不大，但在涉及多表复杂关联查询时，MyBatis-Plus 通过手写优化 SQL 通常能有更好的表现。

核心实现：三大效率提升引擎

1. 题目标签化体系设计

为了精准匹配和高效去重，我们摒弃了传统的纯文本题目描述方式，引入了标签体系。每个毕设题目除了标题和详细描述，还关联一组标签。

数据库设计核心表：

CREATE TABLE `project_topic` (
  `id` bigint(20) NOT NULL COMMENT '主键',
  `title` varchar(200) NOT NULL COMMENT '题目名称',
  `description` text COMMENT '详细描述',
  `teacher_id` bigint(20) NOT NULL COMMENT '出题教师ID',
  `max_selected` int(11) DEFAULT '1' COMMENT '最大可选人数',
  `current_selected` int(11) DEFAULT '0' COMMENT '当前已选人数',
  `status` tinyint(4) NOT NULL COMMENT '状态：0-待审核，1-已发布，2-已被选满，3-已关闭',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CREATE TABLE `topic_tag` (
  `id` bigint(20) NOT NULL,
  `topic_id` bigint(20) NOT NULL COMMENT '题目ID',
  `tag_name` varchar(50) NOT NULL COMMENT '标签名，如：Java, SpringBoot, 机器学习, 算法',
  PRIMARY KEY (`id`),
  KEY `idx_topic_id` (`topic_id`),
  KEY `idx_tag_name` (`tag_name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务逻辑： 教师在提交题目时，需要从标签库中选择或创建标签。系统后台会基于标签进行相似度计算，实现智能去重推荐。例如，一个标签为 [Java, SpringBoot, 电商] 的题目，在审核时系统会提示与已有标签为 [Java, SpringCloud, 商城] 的题目可能存在较高相似度。

2. 基于 Redis 的分布式选题锁

并发选题是核心痛点。假设题目 A 剩余名额为 1，两个学生同时点击“选择”，如果没有锁机制，会导致超选。我们采用 Redis 实现了一个轻量级的分布式锁。

核心代码实现（选题服务层）：

@Service
@Slf4j
public class TopicSelectionServiceImpl implements TopicSelectionService {

    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    @Autowired
    private ProjectTopicMapper topicMapper;

    private static final String TOPIC_LOCK_PREFIX = "lock:topic:";
    private static final long LOCK_EXPIRE_TIME = 10L; // 锁过期时间10秒

    @Override
    @Transactional(rollbackFor = Exception.class)
    public boolean selectTopic(Long studentId, Long topicId) {
        String lockKey = TOPIC_LOCK_PREFIX + topicId;
        String requestId = UUID.randomUUID().toString(); // 唯一标识，用于安全释放锁

        // 1. 尝试获取分布式锁
        Boolean lockAcquired = redisTemplate.opsForValue()
                .setIfAbsent(lockKey, requestId, LOCK_EXPIRE_TIME, TimeUnit.SECONDS);

        if (Boolean.TRUE.equals(lockAcquired)) {
            try {
                // 2. 获取锁成功，执行核心业务逻辑
                ProjectTopic topic = topicMapper.selectById(topicId);
                if (topic == null || !topic.getStatus().equals(TopicStatus.PUBLISHED.getCode())) {
                    throw new BusinessException("题目不存在或不可选");
                }
                if (topic.getCurrentSelected() >= topic.getMaxSelected()) {
                    throw new BusinessException("该题目已被选满");
                }

                // 3. 检查学生是否已选过题目（业务规则）
                // ... 省略检查代码 ...

                // 4. 更新题目已选人数
                topic.setCurrentSelected(topic.getCurrentSelected() + 1);
                if (topic.getCurrentSelected() >= topic.getMaxSelected()) {
                    topic.setStatus(TopicStatus.FULL.getCode());
                }
                topicMapper.updateById(topic);

                // 5. 创建选题记录
                // ... 省略创建记录代码 ...
                log.info("学生[{}]成功选题[{}]", studentId, topicId);
                return true;

            } finally {
                // 6. 释放锁：使用Lua脚本保证原子性，避免误删其他请求的锁
                String luaScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
                DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>(luaScript, Long.class);
                redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId);
            }
        } else {
            // 获取锁失败，提示用户稍后重试
            log.warn("选题[{}]并发请求，学生[{}]获取锁失败", topicId, studentId);
            throw new BusinessException("当前选题人数过多，请稍后重试");
        }
    }
}

关键点说明：

• setIfAbsent 与过期时间：原子性操作加锁，并设置自动过期，防止死锁。
• 唯一请求 ID：释放锁时校验 value，确保只能删除自己加的锁，避免在业务执行时间超过锁过期时间后，误删后续请求的锁。
• Lua 脚本释放锁：保证判断和删除的原子性。

3. 状态机驱动的审核流程

我们将题目的生命周期抽象为一个状态机，清晰定义状态流转规则。

状态枚举定义：

@Getter
public enum TopicStatus {
    PENDING_REVIEW(0, "待审核"),
    PUBLISHED(1, "已发布"),
    FULL(2, "已被选满"),
    CLOSED(3, "已关闭");

    private final int code;
    private final String desc;
    // 构造方法等...
}

状态流转服务：

@Service
public class TopicStateMachine {
    // 使用一个Map来定义合法的状态转换
    private static final Map<TopicStatus, Set<TopicStatus>> STATE_TRANSITIONS = new HashMap<>();

    static {
        STATE_TRANSITIONS.put(PENDING_REVIEW, EnumSet.of(PUBLISHED, CLOSED));
        STATE_TRANSITIONS.put(PUBLISHED, EnumSet.of(FULL, CLOSED));
        STATE_TRANSITIONS.put(FULL, EnumSet.of(CLOSED));
        STATE_TRANSITIONS.put(CLOSED, EnumSet.of(PUBLISHED)); // 例如，重新开放
    }

    public boolean canTransition(TopicStatus from, TopicStatus to) {
        Set<TopicStatus> allowed = STATE_TRANSITIONS.get(from);
        return allowed != null && allowed.contains(to);
    }

    @Transactional
    public void transition(Long topicId, TopicStatus targetStatus, String remark) {
        ProjectTopic topic = topicMapper.selectById(topicId);
        if (topic == null) {
            throw new BusinessException("题目不存在");
        }
        TopicStatus currentStatus = TopicStatus.of(topic.getStatus());
        if (!canTransition(currentStatus, targetStatus)) {
            throw new BusinessException(String.format("无法从状态[%s]转换到[%s]", currentStatus.getDesc(), targetStatus.getDesc()));
        }
        // 执行状态更新和记录日志
        topic.setStatus(targetStatus.getCode());
        topicMapper.updateById(topic);
        // 保存审核日志，记录操作人、时间、备注等
        saveAuditLog(topicId, currentStatus, targetStatus, remark);
    }
}

这样，任何试图非法修改状态的操作（如直接将“待审核”改为“已选满”）都会被拦截，保证了流程的严谨性和可追溯性。

性能与安全考量

1. 缓存击穿防护：热门题目信息被高频查询。我们使用 Redis 缓存题目详情，并采用“逻辑过期”或“互斥锁”方案防止缓存失效瞬间大量请求打到数据库。
2. SQL 注入防范：坚持使用 MyBatis-Plus 的 QueryWrapper 进行参数化查询，或者使用 #{} 语法的 XML 映射文件，杜绝字符串拼接。
3. 幂等性保障：对于“选题”这类核心操作，我们在数据库层面为学生-题目组合设置了唯一索引。同时在接口层面，可以为每个选题请求生成一个唯一令牌（Token），第一次请求时处理业务并缓存结果状态，后续重复请求直接返回缓存结果。

生产避坑指南

1. 事务边界误用：注意 @Transactional 注解的范围。像上面“选题”方法，获取 Redis 锁的操作不能包含在数据库事务内，否则可能导致锁占用时间过长（等于整个事务执行时间）。我们只在操作数据库的核心步骤开启事务。
2. 冷启动延迟：系统首次部署或重启后，Redis 中无缓存，所有查询直接落库。我们通过启动后异步加载高频数据（如热门题目列表）到缓存，或使用分布式锁保证只有一个线程去加载缓存来缓解。
3. 学生刷题行为模拟测试：在压力测试阶段，不要只测接口响应时间。要模拟真实场景，用脚本并发执行“登录-查看题目列表-频繁点击选题-刷新”等一连串操作，这样才能发现前端的重复提交问题、按钮防抖是否生效，以及后端锁机制的真实承载力。

总结与展望

通过这套基于 Spring Boot 的毕设题目推荐管理系统，我们将老师从繁琐的重复劳动中解放出来，选题季的混乱局面得到了根本性改善。标签化管理和智能去重从源头提升了题目质量，状态机让流程一目了然，而 Redis 分布式锁则保证了高并发下的公平与数据一致性。

这个系统目前服务于单个学院。未来，可以考虑从两个方向扩展：一是多学院协同，需要引入租户（Tenant）概念，在数据层面进行隔离，并设计跨学院的题目共享与审核流程；二是集成智能推荐，可以尝试接入大语言模型（LLM），根据学生的历史成绩、兴趣标签和已学课程，为其生成个性化的题目推荐列表，让选题从“人找题”变成“题找人”，将效率提升到新的层次。

技术服务于业务，解决真实痛点才是最有价值的。希望这个系统的设计思路和实现细节，能给大家带来一些启发。