企业官网建设流程全解析

做毕设或者课程设计选“模特公司活动组织系统”这个题目，配合 Spring Boot + Vue 前后端分离，其实挺聪明的。这个题目光从字面看就给人“业务很具体、功能会很清晰”的好印象。相比于做“通用管理系统”“网上商城”这种千篇一律的题目，模特公司的活动组织场景离真实业务更近，数据模型、状态流转、权限管理都有东西可以写，又不会复杂到超出学生阶段的能力边界。这篇文章我就从开题报告怎么写、技术选型为什么这么定、数据库怎么设计，到前后端如何一步步搭起来、联调时容易踩什么坑，把整个题目的关键节点完整拆开讲一遍，希望能给正在写这个题目的同学一些能直接抄作业的参考。

1. 开题报告怎么定方向：先想清楚系统到底解决什么问题

很多同学一上来就急着写功能列表，活动管理、模特管理、合同管理、工资管理、消息通知、数据报表全往上堆，结果开题答辩时老师一句“你这个系统跟别的管理系统有什么区别？”就有点答不上来。开题报告的核心不是罗列功能，而是把业务痛点、系统定位、核心价值这三个事说明白。

1.1 模特公司到底有什么业务痛点值得用系统解决

传统的模特公司活动组织，大多靠微信群、Excel 表格、甚至本子记录来完成。一场演出要准备什么物料、模特几点到现场、上一个人结束之后几分钟换装上场、活动结束之后出场费用是多少、模特有没有档期冲突，这些信息通常分散在经纪人和工作人员手里。临时到场发现模特和另外一场通告撞了，这个场面在很多小型公司根本不罕见。

用系统化的思路来做，核心是解决三个层面的问题。

一是活动安排的可视化。策划人员创建一个活动之后，需要明确活动的时间（几号到几号、几点到几点）、地点、类型（走秀、商演、车展、平面拍摄），以及需要的模特人数和具体要求。有了系统，这些信息集中维护，不用再靠群聊刷屏找信息。

二是档期冲突的自动化检测。模特的本质是“资源”，而且是时间排他性很强的资源。一个模特同一时间只能接一个通告。系统里有了活动时间之后，指派模特时自动比对已有安排，冲突的立刻弹提示，避免后期现场失控。

三是统计数据的沉淀。活动结束后，公司需要看这个月做了多少场活动、哪些模特出勤率最高、活动类型比例如何、总体成本是多少。手工统计一套数据要对着聊天记录和表格核对几个小时，有了数据库之后一个聚合查询就可以出结果。

开题报告里把这几个痛点写清楚，老师就会觉得你确实理解了这个业务，而不是在随便套一个管理系统的模板。

1.2 功能边界的把控：开题报告里要写“做什么”更要写“不做什么”

写开题报告最容易犯的错误就是贪大。模特公司活动组织系统听起来是“公司内部的信息化系统”，那是不是招聘管理、考勤管理、财务管理都要做？答案显然不是。

我的建议是把功能范围定在“以活动为核心的组织流程闭环”上。核心链路是这样：创建活动 -> 发布/指派模特 -> 模特确认或调整 -> 活动执行 -> 活动反馈与数据统计。

围绕这条链路，核心功能模块只需要四个：

• 活动管理：活动信息的 CRUD、活动状态流转（招募中/已排定/进行中/已结束/已取消）
• 模特管理：模特基本信息、从业资历、档期记录
• 活动分配：把模特与具体活动关联起来，记录该模特在该活动中的出场类型和费用
• 统计看板：按时间段统计活动数量、模特参与次数、各类活动占比

至于合同管理、薪酬管理、考勤管理这些，开题报告的“未来展望”或者“可扩展功能”部分提一嘴就行，千万别全都写进“核心功能”，不然到中期检查的时候你会发现连核心链路都还没做完。

1.3 开题报告里的技术路线怎么描述才显得专业

技术路线的写法不是简单写“前端用Vue，后端用Spring Boot，数据库用MySQL”就结束了。开题报告需要的是一句话把架构体系和关键点讲透。可以这样写：

“系统采用前后端分离架构，后端以 Spring Boot 为核心框架，集成 MyBatis-Plus 作为持久层工具，使用 MySQL 存储业务数据，通过 Spring Security + JWT 完成身份认证与接口权限控制；前端采用 Vue 3 组合式 API 进行页面开发，使用 Vite 作为构建工具，配合 Vue Router 实现前端路由，页面 UI 采用 Element Plus 组件库提升开发效率。前后端通过 RESTful API 进行数据交互，前端开发环境下通过 Vite 代理解决跨域请求问题，生产环境部署时将前端打包后的静态资源交由 Nginx 托管并配置反向代理。”

这段话信息密度足够高，并且每一层技术选型都有它要解决的问题。答辩的时候老师追问任何一句，你都有内容可以展开。

2. 技术选型的关键理由：为什么说 Spring Boot + Vue 是稳妥组合

关于技术选型，先给大家吃一颗定心丸：Spring Boot + Vue 这个组合在高校毕业设计、课程设计、简历项目里，就是最稳的答案之一。不是说它没有缺点，而是在这个场景下它的优点完全能盖过缺点。

2.1 后端选 Spring Boot 的核心原因：低门槛、生态全、学习成本可控

Spring Boot 最大的贡献是把原来 Spring 框架的“配置地狱”变成了“约定优于配置”。以前要搭一个 SpringMVC + MyBatis 的项目，XML 配置文件要写好几个，各个版本之间还可能互相冲突。而 Spring Boot 提供了 starter 机制，引入一个依赖就是一组功能集合，比如spring-boot-starter-web自带内嵌 Tomcat 和 Spring MVC，写完一个 Controller 直接启动就能跑，不用打 war 包再部署到独立的 Tomcat。

另外一个关键点是，Spring Boot 的开发模式在整个 Java 后端生态里是通用语言。你随便打开一个 Java 方向的招聘需求，十个里面有八个要求熟悉 Spring Boot。做这个题目的过程本身就是简历上一个值得聊的项目经验。

对于活动组织系统来说，Spring Boot 能满足全部需求点：接口开发（Spring MVC）、数据持久化（MyBatis-Plus）、权限认证（Spring Security + JWT 或 Sa-Token）、参数校验（Validation）、缓存（Spring Data Redis，如果要做可扩展）。这套技术栈学一遍，以后做别的项目也能直接迁移。

2.2 前端选 Vue 的核心原因：组件化开发太适合信息系统类页面

模特公司活动组织系统的页面长什么样，大概是可以想象出来的：左侧导航栏、顶部用户信息、中间区域是表格、表单和详情抽屉。这种“中后台管理界面”恰恰是 Vue 的舒适区。

为什么不用传统 jQuery + HTML 拼页面？因为页面一多了就会发现 DOM 操作特别杂乱，数据一变页面就要手动更新，逻辑维护成本高。Vue 的核心优势是响应式机制，数据变了页面自动更新，开发者只需要关注数据层，不用关心 DOM 怎么改。

这套题目前端建议直接用 Vue 3。原因也很简单：Vue 3 组合式 API 写业务逻辑更清晰，setup语法糖配合ref、reactive、computed、watch，能很好地把数据请求和交互逻辑组织起来。如果你学校课程教的是 Vue 2，也不用慌，Vue 2 的选项式写法做这个项目也完全没有问题，只是注意组件库要选对应版本的（Vue 2 配 Element UI，Vue 3 配 Element Plus）。

2.3 前后端分离架构带来的实际变化

很多人只是听说过“前后端分离”，但实际上手的时候还是容易绕晕。用大白话解释就是：后端项目只负责输出 JSON 数据，前端项目负责渲染页面发请求。两个项目独立运行、独立部署。

开发阶段最简单的理解方式是这样的。后端启动在本地 8080 端口，前端启动在 5173 端口（Vite 默认）。前端页面里用 Axios 发一个请求到http://localhost:8080/api/activity/list，在没有做任何配置的情况下，浏览器会报跨域错误，因为页面的域名和接口的域名不一样。这时有两种解决办法：一是在后端配置跨域过滤器，二是在前端配置开发代理。前者把后端的 CORS 策略放开，后者让前端开发服务器把请求转发给后端。

生产部署阶段，前端项目执行npm run build之后，得到一个 dist 目录，里面全是静态文件。把这些静态文件放到 Nginx 的 html 目录下，再把接口请求路径通过 Nginx 的location /api/反向代理到后端的端口上，这样前后端就在同一个域下面了，也不存在跨域问题。这部分内容在答辩中属于亮点，如果你能口头给老师讲清楚，技术分肯定不会低。

3. 系统功能设计与数据库建模：把“业务”翻译成“表结构”

如果说框架选型是骨架，那么数据库设计就是血脉。很多项目做到后期发现各种功能改不动、查不出来，根子都在数据库设计阶段没想清楚。

3.1 核心模块的数据流转逻辑

模特公司活动组织系统的基础角色可以分成三类：系统管理员、经纪人/策划人员、模特。管理员管账号和全局配置，经纪人和策划人员创建活动、分派模特，模特查看自己的通告和档期。开题阶段的用例图建议就围绕这三个角色来画。

核心业务链路中的数据流大概是这样的：

经纪人创建一个活动，系统生成一条活动记录，状态为“招募中”。经纪人在活动详情页里选择“添加模特”，从模特列表中筛选出档期空闲并且符合活动风格要求的模特，选定之后系统创建一条“活动-模特”关联记录，状态为“待确认”。模特登录系统之后看到待确认的通告，点击同意或者拒绝，关联记录状态变为“已确认”或“已拒绝”。如果拒绝，经纪人再另行安排。活动日期过后，经纪人可以把活动状态更新为“已完成”，系统自动记录这次活动的实际参与情况，用于统计报表。

这条链路上有三个关键数据对象：活动、模特、活动-模特关联。围绕这三个对象去建表，数据模型就清晰了。

3.2 核心表结构的具体设计建议

先给出一份可以直接用的核心表结构，字段命名风格是小写加下划线，类型尽量结合实际业务选。

用户表（t_user）：id、username、password（存 BCrypt 加密后的值）、real_name、role（admin/agent/model）、model_id（如果角色是模特，关联模特表）、status、create_time。用户表和技术认证绑定，模特表和业务绑定，两者通过 model_id 关联，这样结构上更干净。

模特表（t_model）：id、name、gender、age、height、bust/waist/hip，这是一个很“模特行业”的字段组、phone、style_preference（擅长风格，比如 走秀/平面/车模）、city（常驻城市）、status（空闲/档期中）、remark。

设计模特表的时候有一件事值得注意：“档期”不推荐放在模特表里，而应该体现在活动分配表里。一个模特能不能接某个活动，要去关联表里查这个活动时间范围内有没有重叠的已确认记录。所以“档期状态”字段更多是一个冗余缓存，靠相关表数据计算并更新。

活动表（t_activity）：id、activity_name、activity_type（走秀/商演/车展/平面）、start_time、end_time、location、need_model_count、status（0招募中/1已排定/2进行中/3已结束/4已取消）、contact_person、contact_phone、remark。

时间字段用datetime类型。这里建议不要拆成“开始日期、开始时间、结束日期、结束时间”多个字段，直接两个 datetime 字段最简单，后端做时间比较和前端展示都容易。

活动-模特关联表（t_activity_model）：id、activity_id、model_id、assign_time、confirm_status（0待确认/1已确认/2已拒绝/3已完成）、fee_amount、fee_unit（按场/按天）、remark。

这张表是整个系统里查询最频繁的一张表。按活动查模特、按模特查通告、档期冲突检测，全部依赖这张关联表。设计时一定要加上 activity_id 和 model_id 的联合索引，数据量一上来，没有索引的查询会明显变慢。

表关系总结成一句话就是：活动和模特是多对多关系，通过 t_activity_model 关联表建立起联系，一次关联就是一次“活动-模特通告”。

3.3 时间冲突检测的逻辑能不能放在数据库里

档期冲突检测是标书最核心的业务规则，具体点：模特 A 已经有 1 号 09:00 到 18:00 的活动，现在要做一个新活动 1 号 14:00 到 20:00，这两段时间重叠了，系统要提示冲突。

实际上不用写太高级的 SQL，用很基础的重叠判断逻辑就行。两个时间段分别是 [a_start, a_end] 和 [b_start, b_end]，只要满足“新活动开始时间 < 已有活动结束时间 且 新活动结束时间 > 已有活动开始时间”，说明两者重叠。转化成 SQL 就是：

SELECT COUNT(*) FROM t_activity_model am INNER JOIN t_activity a ON am.activity_id = a.id WHERE am.model_id = #{modelId} AND am.confirm_status IN (1, 3) AND a.status NOT IN (4) AND #{newStartTime} < a.end_time AND #{newEndTime} > a.start_time

这个查询能查出这个模特有没有重叠的已确认活动，如果 count 大于 0 就说明冲突。判断逻辑写在 Service 层，把两个时间作为参数传入，前端传活动开始和结束时间，后端统一校验，是最直接的做法。

4. 实操过程：从零搭建项目并跑通“创建活动->指派模特”主链路

这个章节是拿来直接“抄作业”的，我会还原整个搭建和编码过程的关键步骤。开发工具用 IDEA，JDK 用 1.8 或者 11 都可以，如果你担心 JDK 版本太高会碰见一堆奇怪的 Maven 依赖问题，老老实实用 JDK 1.8 最稳。

4.1 后端工程初始化：Spring Initializr 选型细节

打开 IDEA，选择 Spring Initializr 创建项目。Group 填com.example，Artifact 填model-activity-system，项目类型 Maven，语言 Java，Java 版本选 8 或者 11。

依赖选择上，只勾选几个必需的：

• Spring Web：提供 MVC 和内置 Tomcat
• Spring Security：用于登录认证（如果时间紧也可以先不集成，后面再补）
• MySQL Driver：数据库驱动
• Lombok：简化实体类代码
• Spring Boot DevTools：开发热重启

注意不要在 Spring Initializr 页面勾选 MyBatis 相关依赖，因为它的选项中通常没有 MyBatis-Plus，需要后手动在pom.xml中加入。加入时一定要注意版本选择，建议不要用阿里最新的大版本，而是用稳定版本：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency>

JWT 库先加上，业务逻辑里如果不需要 JWT 的话可以先不写过滤器。但一般来说登录功能还是要做的，不能让任何人直接打开接口访问数据。

application.yml的基础配置如下：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/model_activity?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的密码 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这里有两个经验值得说。第一，连接串里一定不要漏serverTimezone，否则本地时差会导致数据库时间差 8 个小时甚至直接报错。第二，map-underscore-to-camel-case打开之后，数据库字段activity_name能直接映射到 Java 实体属性activityName，这个在我第一次做项目时完全不知道，傻傻地写了很多 ResultMap，其实一行配置就能解决。

4.2 后端核心接口：以“创建活动”和“指派模特”为例

建好实体类，用 Lombok 简化 getter/setter 之后，直接在 Controller 中写接口。

创建活动的接口：

@RestController @RequestMapping("/api/activity") public class ActivityController { @Autowired private ActivityService activityService; @PostMapping("/create") public Result createActivity(@RequestBody ActivityVO activityVO) { // 1. 参数校验：活动名称不能为空，开始时间不能晚于结束时间 // 2. 保存活动，默认状态为招募中 // 3. 返回活动 id return Result.success(activityService.createActivity(activityVO)); } }

实现类里要注意一个细节，前端传过来的时间通常是"2025-06-01T09:00:00"这种带 T 的字符串，后端用@RequestBody接的时候有可能解析失败或者丢掉精度。更好的做法是用一个ActivityVO对象接收前端传参，时间字段用 String，然后在 Service 中用LocalDateTime.parse转成需要的时间类型。

指派模特的接口，这是整个系统中业务逻辑最集中、最能体现设计思路的接口：

@Transactional public Result assignModelToActivity(ActivityModelDTO dto) { // 1. 查询活动是否存在且状态为“招募中” Activity activity = activityMapper.selectById(dto.getActivityId()); if (activity == null || !activity.getStatus().equals(0)) { throw new BizException("活动不存在或不在招募中状态"); } // 2. 检测模特是否有档期冲突 Integer conflictCount = activityModelMapper.selectConflictCount( dto.getModelId(), activity.getStartTime(), activity.getEndTime() ); if (conflictCount > 0) { throw new BizException("该模特在这个时间段已有通告，无法指派"); } // 3. 创建关联记录 ActivityModel record = new ActivityModel(); record.setActivityId(dto.getActivityId()); record.setModelId(dto.getModelId()); record.setConfirmStatus(0); activityModelMapper.insert(record); return Result.success(); }

这个方法整体加了@Transactional，保证“检测冲突”和“插入关联记录”要么都成功、要么都失败，不会出现检测的时候没有冲突，插入的时候却因为并发插入了一条冲突记录，导致数据不一致。

4.3 前端工程初始化：Vite 创建 Vue 3 项目并配置代理

前端部分用 Vite 创建项目是最省心的方案。命令行执行：

npm create vite@latest model-activity-web -- --template vue cd model-activity-web npm install npm install axios element-plus vue-router@4

安装完依赖之后，先把vite.config.js里面的开发代理配好，这样前端发出的/api请求都会自动转发到后端 8080 端口：

import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

创建完项目之后，我强烈建议先做两件事再写业务页面。第一，把 Element Plus 按需引入配好，不然全量引入会让项目首次加载特别慢；第二，封装一个统一的 axios 实例，拦截器里统一处理 token 添加和 401 跳转，避免每个页面里重复写这些逻辑。

axios 封装的大体结构是这样：

import axios from 'axios' import { ElMessage } from 'element-plus' 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 => response.data, error => { if (error.response?.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } ElMessage.error(error.response?.data?.message || '请求失败') return Promise.reject(error) } ) export default request

4.4 活动列表页与指派模特的完整联调逻辑

活动列表页用 Element Plus 的el-table展示。为了控制篇幅，我重点说指派模特这个交互怎么实现。

页面加载活动列表之后，每一行“操作”列里有“指派模特”按钮。点击这个按钮，弹出一个对话框，里面是模特列表和一个多选框，同时显示模特姓名和“擅长风格”信息。用户勾选完点击确定，前端把activityId和选中的模特 id 数组发给后端。

这里有一个很常见的坑：很多同学会把“批量指派”设计成循环调接口，一次指派一名模特，然后等着响应。我建议改成后端提供一个批量指派接口，一次请求把选中的多个模特 id 作为数组传过去。这样既能减少网络请求次数，也方便后端在同一个事务里做所有模特的时间冲突校验，一个模特冲突就直接回滚全部。

前端的调用代码大致长这样：

const handleAssign = async () => { const res = await request.post('/activity/assign/batch', { activityId: currentActivityId, modelIds: selectedModelIds }) if (res.code === 200) { ElMessage.success('指派成功') loadActivityList() } }

到这里，最核心的“创建活动 -> 指派模特 -> 模特查看通告”这条链路就完全跑通了。前面所有工作都是为这条链路服务的，之后加统计模块、登录权限、审批流程都是在这个骨架上继续添砖加瓦。

5. 常见问题与排查技巧：我实际踩过的坑

做这类项目时最容易出问题的点，我都一一经历过了，下面直接列出来，大家开发的时候先有个数。

5.1 前端口请求接口报跨域，或者 404 404

如果你的请求从浏览器发出去报 404，基本是路径对不上。后端接口的完整路径是由类上的@RequestMapping和方法的@RequestMapping拼接而成。前端 axios 的baseURL如果是/api，那么请求的最终路径应该是/api/activity/list，后端类上写@RequestMapping("/activity")，方法上写@GetMapping("/list")。这三段加起来是/api+/activity+/list，就通了。

如果报了跨域但路径是对的，多半是后端没配置 CORS。写一个WebMvcConfigurer的配置类，统一处理：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true); } }

在开发阶段配上这个基本就不会因为跨域发愁了。

5.2 表名和字段名踩了关键字

MySQL 的model不是奇怪的关键字，但有一些单词例如order、group、desc、rank是。如果你的表里出现这种名称，SQL 语句中不加反引号就容易报语法错误。我做过一个项目，表名叫order，每次查都出问题，最后一致改名带t_前缀才消停。

强烈建议给所有表都加一个业务前缀。这个项目里的t_model、t_activity、t_activity_model，一眼就能看出是一个业务域的，还能避免跟系统保留词冲突。

5.3 前后端时间格式不一致，测试的视力都要被磨没了

前端 Element Plus 的el-date-picker默认给出的是数组值，如果配了value-format="YYYY-MM-DDTHH:mm:ss"可以得到需要的字符串格式。但后端如果用java.util.Date接收，Spring默认解析 ISO 格式字符串有时会报格式错误。

我的经验是后端时间字段直接用LocalDateTime，前端传字符串2025-06-01T09:00:00，Spring Boot 默认的 Jackson 就能直接解析为LocalDateTime，不需要额外配置。

返回给前端的时候，application.yml中的 jackson 配置也会把时间输出成yyyy-MM-dd HH:mm:ss，前端表格里直接显示这个字符串即可，不用自带日期格式化函数。

5.4 MyBatis-Plus 分页插件没配置导致分页失效

MyBatis-Plus 的分页功能不是说引入依赖就自动可用的，它需要配置分页插件。我之前就吃过这个亏，以为只要调selectPage方法就能分页，结果查出来的数据永远是全部，因为插件没注册。

正确做法是加入以下配置：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

配好之后，在 Service 里调用page(new Page<>(current, size), queryWrapper)就能正确返回分页数据，返回的IPage对象里本身带有总条数total，前端分页显示没有任何问题。

5.5 Maven 依赖下载慢、版本冲突

国内环境直接 Maven 下载依赖速度慢，经常等到超时。IDEA 里打开settings.xml，配阿里云镜像：

<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

版本冲突最典型的场景是 Spring Boot 版本太高，导致MyBatis-Plus或其它 jar 包内部依赖不兼容。在做这类管理系统的项目里，我不建议一上来就选 Spring Boot 最新的 3.x 版本，因为 3.x 基于 Jakarta EE，包名从javax.*改成了jakarta.*，网上大量教程还是基于 2.x 的写法，直接照抄很容易编译不过。选一个 2.7.x 的稳定版本，配合 MyBatis-Plus 3.5.x，是这个组合最省心的版本组合。

5.6 档期冲突判断的边界条件不要忘了

在实现冲突检测逻辑时，最容易忽略的是“活动刚好在同一天首尾相接”的场景。比如模特 A 的活动时间是 9:00-12:00，新活动是 12:00-15:00。按照常见的重叠判断逻辑newStart < oldEnd AND newEnd > oldStart，这种情况不会被判定为冲突，因为 12:00 并不小于 12:00。这对业务来说其实是合理的，模特前一个活动 12:00 结束，赶下一场 12:00 开始，只要交通上没问题就可以。

但如果用人脑去判断，很容易在测试时多写一个边缘 case 把自己绕晕。建议在测试用例中专门列出三种情况：完全重叠、部分重叠、首尾相接不重叠。写一个简单的单元测试，把三个 case 都跑一遍，确认逻辑符合预期。

6. 这个题目还能怎么扩展：让答辩更出彩的加分方向

核心功能做完之后，如果时间来得及，有些扩展方向很值得做，能给答辩加分。

第一个方向是数据可视化大屏。活动组织系统天然有数据来源：活动类型分布、模特的月出勤次数、活动状态占比、月度活动数量趋势。用 ECharts 做一个统计页面，不同统计图组合展示，视觉效果很震撼，也符合“数据驱动决策”的表述，是一个很容易讲清楚的加分点。

第二个方向是消息通知。可以用 Spring Boot 整合 WebSocket，实现“模特被指派”时前端实时弹出通知。当然，如果不想搞 WebSocket，也可以做一个简单的站内消息表，模特登录之后查看未读消息。这个功能复杂度可控，而且能体现“闭环管理”的思路。

第三个方向是 Excel 导出报表。活动结束后，导出一份包含活动名称、时间、地点、参演模特、出场费的 Excel 表格，对实际业务场景来说非常实用。用 EasyExcel 实现导出的代码量不算大，但实操性很强，讲起来也有真实应用背景。

我个人的建议是：如果时间有限，优先做数据可视化页面，因为它是在核心链路之上最容易独立完成、最容易演示、也最容易当场讲清楚的模块。消息通知和 Excel 导出可以放在“展望”里提一下，表示你知道怎么做，只是时间不够。与其做三个半成品，不如把统计页面做得精致一点，留出时间整理项目文档和答辩 PPT。

最后再分享一个我做这个系统的真实体会：最花时间的其实不是写代码，而是梳理状态流转。第一次做的时候我把活动状态、关联记录状态、模特状态分成三套数字枚举，但代码里到处散落着魔法数字，一不留神就分不清status=0在某个表里到底是“待确认”还是“已取消”。后来我用 Java 枚举类把所有状态统一管理起来，并写清楚了每个状态下允许的转换动作，整个代码一下子就清晰了很多，调试和加功能都舒坦了。做这类系统，前期把状态和流转规则想明白，后面开发真的能少走很多弯路。