企业官网建设流程全解析

简介：基于Web的任务管理系统设计与实现论文，面向软件工程、计算机相关专业学生及需要完成同类毕业设计课题的开发者，聚焦任务分配、权限控制、文档管理、变更追踪等项目管理难题。文档从开发背景、系统架构、功能特点、配置管理到持续改进，完整呈现了基于B/S模式、采用JSP与SQL Server 2000实现的设计思路与实现方案；前台界面简洁实用，后台数据库保障数据安全性与完整性，同时支持日报周报智能化管理、自动化任务分配提醒、不同角色权限控制，以及变更申请、审批、实施与回滚，提高团队协作与办公自动化水平。资源包仅1个doc文件，大小935KB，包含论文正文、摘要、关键词及完整章节论述，结构清晰、内容翔实，可直接用于毕业设计论文参考、系统模块规划与答辩准备。已有164人学习下载，适合需要撰写相关论文或了解Web任务管理系统设计流程的读者，凭借完整框架与细致分析，可为实际课题提供扎实支撑。

1. 基于web的任务管理系统，毕业设计里最不该低估的一类项目

很多选这个题目的同学第一反应是“不就是增删改查吗”，真正动手才发现，基于web的任务管理系统是典型的“业务逻辑比界面多”的Web项目：任务要创建、分配、流转、逾期、催办，每个状态背后都有权限和通知问题。这篇笔记会从业务建模、数据库设计、Spring Boot + Vue实现到论文.doc写作，给你一条能照着做完毕业设计的完整路径。适合正在做Web课程设计或毕设、以及想用最小成本看懂任务类系统怎么落地的人。

2. 先把业务模型定住：状态机、权限、通知，三件事决定系统复杂度

2.1 “任务”不是一张表：先分清楚业务对象，再建库

做任务管理系统，第一个翻车点不是代码，而是数据库设计。很多人把任务的所有属性都塞进一张表：任务名、描述、优先级、创建人、负责人、参与者、附件路径、评论内容……结果评论和附件多的时候，表里出现大量冗余字段，后面写查询SQL还要反复拼接字符串，改一个字段就牵一发动全身。

正确的做法是先列业务对象。一个典型的Web任务管理场景里，对象有用户、任务、评论、操作日志、通知记录。用户和任务之间存在两种关系：创建关系、分配关系。任务和评论是一对多，任务和操作日志是一对多，任务和通知记录也是一对多。把这层关系理清，写论文画ER图时才不会乱。

落成SQL时，任务表先只放核心字段：

CREATE TABLE sys_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, description TEXT, priority TINYINT DEFAULT 2 COMMENT '1低 2中 3高', status VARCHAR(20) DEFAULT 'TODO', creator_id BIGINT NOT NULL, assignee_id BIGINT, due_time DATETIME, created_time DATETIME DEFAULT CURRENT_TIMESTAMP, updated_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_status (status), INDEX idx_assignee (assignee_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

创建人和负责人分开，是为了后面统计“我创建的”和“我负责的”两类列表。评论单独建表，任务表不存评论内容；操作日志单独建表，任务表不存历史上谁改过状态。这里要特别说明一下状态字段的类型：我一般用VARCHAR存状态名，而不是TINYINT，理由是毕业设计演示时数据库里直接看到“DOING”比看到“2”直观，写论文数据字典时也少一层映射。

2.2 状态流转设计：把“待办→进行中→已完成”做成显式状态机

任务系统最容易让人翻车的地方是状态流转。只有三个状态时好像很简单，一旦加上“逾期”“取消”“暂停”，问题就来了：已完成的任务被重新打开，取消的任务还能被修改，逾期任务没有自动触发提醒。

我建议用一个枚举类把状态钉死，再单独写一个校验类管理“能从哪个状态到哪个状态”。这个设计模式很朴素，但能直接在论文里推导出UML状态图，也方便回答答辩老师的追问。

public enum TaskState { TODO, DOING, DONE, OVERDUE, CANCELLED }

更新接口里调用校验方法：

private static final Map<String, Set<String>> ALLOWED_TRANSITIONS = new HashMap<>(); static { ALLOWED_TRANSITIONS.put("TODO", Set.of("DOING", "CANCELLED")); ALLOWED_TRANSITIONS.put("DOING", Set.of("DONE", "CANCELLED", "OVERDUE")); ALLOWED_TRANSITIONS.put("OVERDUE", Set.of("DOING", "DONE")); } public boolean canTransition(String from, String to) { Set<String> allowed = ALLOWED_TRANSITIONS.get(from); return allowed != null && allowed.contains(to); }

这个写法的核心价值在于把状态规则集中到一张静态表里，接口、前端下拉框、论文状态图共用同一套逻辑。如果前端把“已完成”选项开放给待办状态，后端口径还能兜住。要注意OVERDUE的进入方式：常见做法是用Spring的@Scheduled定时任务，每分钟扫一次任务表，把due_time早于当前时间且状态是TODO或DOING的数据批量更新为OVERDUE。

@Scheduled(fixedRate = 60000) public void markOverdueTasks() { // UPDATE sys_task SET status='OVERDUE' // WHERE due_time < NOW() AND status IN ('TODO','DOING') }

定时任务的SQL里必须限定原状态，否则已完成的任务会被反复改成逾期，这也是测试用例里值得写的一条异常路径。

2.3 权限模型：先做角色和数据范围两层，别急着上全套框架

很多同学看到项目教程就上Spring Security + JWT + RBAC全家桶，结果写论文时光授权表就画了三张，答辩还说不清楚。任务管理系统的权限其实没那么重，我一般用最简方案：登录后返回一个Token（UUID或JWT都行），后端用拦截器解析Token，拿到当前用户ID和角色。

Token生成和校验的常见做法是登录成功后把用户信息放进Redis，key就是Token，请求头带Authorization进来时查Redis。拦截器代码不依赖额外框架：

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || !redisTemplate.hasKey(token)) { response.setStatus(401); return false; } User currentUser = (User) redisTemplate.opsForValue().get(token); request.setAttribute("currentUser", currentUser); return true; } }

有了当前用户之后，权限分两层控制。接口级权限：管理员才能调用用户管理和任务删除接口，在Controller里判断角色。数据级权限：普通用户只能看到自己是创建人或负责人的任务，管理员看全部。数据级权限必须在SQL层过滤，不要查全表再内存过滤。

MyBatis-Plus里这样写：

LambdaQueryWrapper<Task> wrapper = Wrappers.lambdaQuery(Task.class); if (!isAdmin) { wrapper.and(w -> w.eq(Task::getCreatorId, currentUser.getId()) .or().eq(Task::getAssigneeId, currentUser.getId())); }

这里最容易出错的是or和and的括号关系，很多人拼成“创建人是自己，并且（负责人是所有人）”，导致数据漏掉。写论文时可以把接口级权限画成用例图，数据级权限画成时序图，比贴源码更有说服力。

2.4 通知机制：用一张通知表和定时扫描，别做轮询炸弹

通知是任务管理里常被忽略但实际很要命的功能：任务被分配时，负责人要收到提醒；任务逾期时，创建人和负责人要看到。新手最容易写成一个JS setInterval每秒请求一次未读通知接口，这叫轮询炸弹，浏览器一开，数据库查询量直接翻倍，演示时还会把接口拖慢。

我建议把通知做成一张独立的记录表，任务事件触发后插一条通知记录，标记接收人ID和是否已读。前端每次切换页面或点击铃铛时请求一次即可，不要轮询。如果确实想实时，可以用WebSocket推送一条轻量提示，而不是把整个列表推过去。

定时扫描逾期任务时，在标记OVERDUE之后往通知表插入：

INSERT INTO sys_notification (user_id, content, is_read, created_time) SELECT creator_id, CONCAT('任务【', title, '】已逾期'), 0, NOW() FROM sys_task WHERE status = 'OVERDUE' AND due_time < NOW();

通知表的意义不止是提醒，它也是论文里“系统事件驱动设计”的佐证。答辩时老师问“逾期怎么处理”，你把这个INSERT逻辑讲出来，比讲一百行业务代码都直观。

3. 用Spring Boot + Vue跑通最小闭环：表结构、接口、页面

3.1 项目初始化：后端用Spring Boot，前端用Vue3 + Element Plus

常见的做法是后端一个Spring Boot工程，前端一个Vue工程，前后端分离。后端Controller、Service、Mapper、entity四层结构，前端用Vite创建Vue3项目，装Element Plus做表格和弹窗。这个组合是目前毕业设计出现频率最高的，也是评阅老师最容易接受的技术栈。

后端核心依赖只需要：spring-boot-starter-web、mybatis-plus-boot-starter、mysql-connector-java、lombok。如果要做登录Token，再加一个spring-boot-starter-data-redis。前端依赖就是element-plus和axios。启动端口固定为后端8080，前端Vite使用5173，并通过代理把/api开头的请求转发到8080，这样开发阶段完全不用处理CORS。

// vite.config.js export default { server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

这个代理配置有三个参数要留意：port决定前端启动端口，target是后端地址，changeOrigin必须设为true，否则后端拿到的Host还是5173，某些框架会识别成跨域请求。如果后端接口本来就带/api前缀，后端Controller的RequestMapping也要对应调整。

3.2 建表与初始化数据：任务管理至少要两张表打底

第2章已经给了任务表结构，这里补上用户表，并插入测试账号。用户表字段不要贪多，id、username、password、real_name、role就够，角色区分USER和ADMIN。

CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(64) UNIQUE NOT NULL, password VARCHAR(128) NOT NULL, real_name VARCHAR(64), role VARCHAR(20) DEFAULT 'USER' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO sys_user (username, password, real_name, role) VALUES ('admin', '123456', '管理员', 'ADMIN'), ('zhangsan', '123456', '张三', 'USER');

密码在演示项目里可以直接存明文，但论文里最好写一句“生产环境使用BCrypt加密”，不然答辩容易被问。任务表里的用户关系我用逻辑外键，也就是不建物理外键约束，只存用户ID。这个选择的好处是分页查询和删除不受外键约束拖累，坏处是论文里要解释一句“通过代码维护数据一致性”。

任务表初始数据也要准备几条，状态分别给TODO、DOING、DONE、OVERDUE，这样前端列表颜色和状态按钮能展示完整效果。插入数据时记得让due_time有近有远，方便观察逾期定时任务的效果。

3.3 后端三个核心接口：创建任务、状态流转、分配负责人

先看创建任务接口。Controller只负责接收参数和返回统一结果，业务逻辑放到Service。

@PostMapping("/tasks") public Result<Task> createTask(@RequestBody TaskDTO dto, HttpServletRequest request) { User user = (User) request.getAttribute("currentUser"); Task task = taskService.createTask(dto, user.getId()); return Result.ok(task); }

Service里要做三件事：非空校验、设置创建人ID、把状态初始化为TODO。标题和描述必填，负责人可空。如果传了负责人ID，要检查用户是否存在，创建成功后给负责人插入一条通知记录。

public Task createTask(TaskDTO dto, Long creatorId) { Task task = new Task(); task.setTitle(dto.getTitle()); task.setDescription(dto.getDescription()); task.setPriority(dto.getPriority()); task.setDueTime(dto.getDueTime()); task.setCreatorId(creatorId); task.setAssigneeId(dto.getAssigneeId()); task.setStatus("TODO"); taskMapper.insert(task); if (dto.getAssigneeId() != null) { Notification notification = new Notification(); notification.setUserId(dto.getAssigneeId()); notification.setContent("你有一条新任务：" + task.getTitle()); notificationMapper.insert(notification); } return task; }

这里有一个参数坑：TaskDTO接收前端的时间字段，如果前端传的是带T的ISO格式或者时间戳，后端需要统一处理。常见做法是字段类型用LocalDateTime，并让前端按yyyy-MM-dd HH:mm:ss传，可以在实体字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。

更新状态接口是任务系统的核心接口，也是答辩必问的地方。这里把DTO里的状态字符串交给状态机校验，不合法直接抛业务异常。

@PutMapping("/tasks/{id}/status") public Result<Task> updateStatus(@PathVariable Long id, @RequestBody StatusDTO dto, HttpServletRequest request) { Task task = taskMapper.selectById(id); if (task == null) { throw new BizException("任务不存在"); } if (!stateTransition.canTransition(task.getStatus(), dto.getStatus())) { throw new BizException(String.format("不允许从%s流转到%s", task.getStatus(), dto.getStatus())); } task.setStatus(dto.getStatus()); taskMapper.updateById(task); return Result.ok(task); }

参数上要注意状态字段大小写，前端统一传大写，或者后端接收后调用toUpperCase()转一下。否则“done”和“DONE”会被当成不同状态，状态校验直接拦截。

分配负责人接口本质上是更新assignee_id，但它和普通更新不一样，因为分配动作要记录操作日志“谁把任务分配给了谁”。所以我单独写一个接口，Service里先校验任务存在，再校验新负责人存在，更新后再插入操作日志：

@PutMapping("/tasks/{id}/assignee") public Result<Void> assign(@PathVariable Long id, @RequestBody AssignDTO dto, HttpServletRequest request) { User operator = (User) request.getAttribute("currentUser"); taskService.assign(id, dto.getAssigneeId(), operator.getId()); return Result.ok(); }

这个接口的价值在论文里体现得很直接：任务管理不只是改字段，而是“追踪每一次关键操作”，操作日志表的来源就在这里。

3.4 前端页面：任务列表和状态按钮不要写死

前端页面我建议只做一个任务列表页加上一个新建任务弹窗，演示时足够。列表用Element Plus的el-table，状态用el-tag显示颜色。状态到颜色映射放在一个常量对象里：

const statusMap = { TODO: { label: '待办', type: 'info' }, DOING: { label: '进行中', type: 'primary' }, DONE: { label: '已完成', type: 'success' }, OVERDUE: { label: '已逾期', type: 'danger' }, CANCELLED: { label: '已取消', type: 'warning' } }

获取列表时调用后端接口，前端拿到数据后用statusMap渲染。更新状态时，按钮的可点击项要由后端返回的“允许下一步状态”决定，而不是前端拍脑袋。简单做法是后端列表接口返回每个任务时附带一个nextStatus字段，比如taskStatus为DOING时nextStatus可能是DONE。

创建任务的弹窗里，负责人选择器用el-select，选项来自用户列表接口。日期选择用el-date-picker，提交前要做格式化：

const formatTime = (date) => { if (!date) return null return dayjs(date).format('YYYY-MM-DD HH:mm:ss') } const handleCreate = async () => { const payload = { title: form.title, description: form.description, assigneeId: form.assigneeId, dueTime: formatTime(form.dueTime) } await axios.post('/api/tasks', payload) await loadTasks() }

如果前端不格式化，直接把Date对象传给后端，常见翻车是后端收到的时间比实际时间少了8小时，这就是时区问题。前端页面不追求复杂，先做列表、创建、状态流转三个功能，已经覆盖任务管理系统的核心。很多同学花两周做炫酷看板，最后论文没有篇幅写，答辩还因为组件版本问题跑不起来，不值得。

4. 论文.doc的写法：从系统设计到测试章节，让评审老师看出工作量

4.1 论文大纲：按“需求分析、系统设计、系统实现、系统测试”四段走

“基于web的任务管理系统的设计与实现”这个题目，论文.doc的目录基本是按软件工程经典流程走。我见过最高效的骨架是：

这个结构最贴近大多数学校的模板，不要自己独创结构，否则格式审查会打回。需求分析章节最容易写空，建议用usecase图表达四种操作：登录、创建任务、更新任务状态、查看任务列表。每个用例配一个描述表格：参与者、前置条件、主流程、异常流程。

非功能需求里要提跨浏览器支持，因为这是web项目。论文里写“系统在Chrome、Edge、Firefox下均可正常使用”就好，不要写成“所有浏览器都兼容”，那是给自己挖坑。实际测试时你测了哪几个浏览器就写哪几个，测试记录要和系统测试章节保持一致。

4.2 设计章节：把状态机、ER图、时序图画清楚

设计章节最容易被扣分，因为很多同学直接从网上截一张架构图。我建议画四张图，全部用draw.io导出PNG，不要用屏幕截图截代码。

第一张是系统功能结构图，分前台和后台两个模块目录。第二张是ER图，表之间关系用crow's foot标识。第三张是任务状态图，就是第2章的状态机，正方形框代表状态，箭头代表流转方向。第四张是“创建任务”时序图，按第3章的Service逻辑画：用户请求→Controller→Service→Mapper→数据库→通知表。

图的质量比数量重要，四张图画对已经足够。画图时注意实线和虚线的含义，依赖关系不要乱用。如果老师要求源码，可以用PlantUML写图，但论文里只贴生成的PNG，不要贴源码。

4.3 实现章节：关键代码怎么贴才能让老师觉得有水平

实现章节不需要把整个项目源码贴进去，只贴核心模块的关键代码。我一般选三块：任务状态机校验类、创建任务Service、前端状态渲染组件。每段代码后面跟一段文字，讲这段代码解决了什么问题、和哪个模块对接。

代码排版要注意：单行代码不要超过70个字符，中文注释用宋体，代码用等宽字体。Word里用带边框的代码块，不要截图，否则打印出来模糊。论文查重时代码一般不查，但注释也不要整句抄网络教程，尽量用自己的话写。

这里有一个容易被忽略的点：设计模式。任务管理系统里，状态机校验类是策略模式的简化版，创建任务Service里“任务创建后通知负责人”是一种事件触发的思路。在论文里明确写出用了哪种设计模式，并画对应的类图，能给设计章节加分。设计模式java实现这个词背后，其实就是把一层if判断说成模式，但前提是代码真的这样做了，不是贴一个名词上去。

4.4 测试章节：别写“测试全部通过”，要给数据和结果

测试章节最好写也最容易被看出造假。很多同学的测试表格只有“测试模块、测试内容、结果”，没有输入输出数据，评阅老师一眼看出是编的。功能测试表至少包含：用例编号、测试项、前置条件、操作步骤、输入数据、预期结果、实际结果。

给一个具体的表格示例：

性能测试写一个能够解释的数据：系统在100个并发用户同时查询任务列表时，平均响应时间低于500毫秒，无错误请求。这个数据要来自你的实际压测，不要直接抄。第6章会讲怎么压测，先把表格留好，数据跑完再填上去。

5. 常见问题与避坑：为什么你的系统总是“能跑，但答辩时经不起问”

5.1 前端请求接口报跨域错误，页面白屏

现象：浏览器控制台出现CORS error，Vite开发服务器能打开页面，但所有接口请求失败。

原因：前后端分离项目，如果没有配置代理或全局CORS，浏览器会拦截跨域请求。很多同学只配置了axios的baseURL，忘掉后端加CORS配置。

解决：开发阶段推荐用Vite proxy，把/api代理到8080；如果部署时前后端分开，后端要加CorsFilter。一个稳定的做法是后端定义WebMvcConfigurer：

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

注意allowedOrigins和allowedOriginPatterns的区别：allowCredentials为true时，allowedOrigins不能写“*”，但allowedOriginPatterns可以配通配符。这个细节能卡住很多人。

5.2 状态更新后，前端列表不刷新

现象：点击“开始处理”后，页面上的状态标签没变，只有刷新页面才看到新状态。

原因：前端把更新前的列表保存在内存里，调用更新接口成功后只改了后端，没有重新拉取或修改本地数据。

解决：在状态更新成功的回调里重新调用获取列表接口。如果列表数据量不大，直接重新fetch，代码量最少。

const handleStatusChange = async (row) => { await updateTaskStatus(row.id, row.nextStatus) await loadTasks() }

如果接口响应慢，可以改成先更新本地row对象的status属性，但要注意把statusMap对应的type一起更新。我推荐直接重拉列表，逻辑简单，也避免状态不一致。

5.3 任务分配后，负责人看不到任务

现象：管理员把任务分配给张三，张三登录后列表里看不到。

原因：查询逻辑里数据级权限拼SQL条件时，or和and的括号错了。常见写法被拼成WHERE creator_id = ? OR assignee_id = ? AND status = ?，导致权限条件作用域错乱。

解决：用MyBatis-Plus的LambdaQueryWrapper时，or条件要放在独立的and里面，见2.3节的代码。不要手写字符串拼接SQL，很容易出错。

另一个原因是业务逻辑上，张三登录时Token没问题，但后端把解析出来的userId当成了creator_id去查，而不是同时查assignee_id。排查时先打印日志看当前用户ID，再检查SQL条件。

5.4 论文里的数据库表和实际代码不一致

现象：论文里的ER图有5张表，代码里却只写了3张；论文里的字段名和实际实体类不一致。

原因：先写论文后补代码，或者改数据库没同步更新论文。这是毕业设计最常见的翻车。

解决：从数据库导出SQL文件，论文里的数据字典直接从SQL生成，不要手敲。写论文实现章节前，把项目里的实体类字段和数据库表结构打印出来对照一遍。评阅老师可能不逐行看代码，但会对比ER图和数据字典，一处对不上就会被质疑。

5.5 时间戳和状态大小写问题

现象：前端提交日期后，数据库里时间少了8小时；状态传“done”后端报错。

原因：前端没做时间格式化，后端没有统一状态大小写。时间少了8小时是JSON序列化时没带时区，状态大小写不一致是字符串比较没统一。

解决：前端用dayjs格式化后再传，后端DTO里给LocalDateTime字段加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")。状态字段统一在DTO里加校验注解，比如@Pattern(regexp = "TODO|DOING|DONE|OVERDUE|CANCELLED")。

这些坑单独看都不大，但串起来会让整个演示过程非常难看。我的习惯是答辩前把“建用户→建任务→分配→流转→逾期”完整流程跑一遍，每跑一步截图，留存测试记录。

6. 验证和进阶：让系统在答辩时经得起追问的三个小技巧

第一个技巧是压测。任务管理系统如果只做增删改查，答辩时老师问一句“并发场景下性能怎么样”就可能卡住。用JMeter做一个简单压测：线程数100，循环次数10，请求GET /api/tasks，然后看聚合报告。平均响应时间超过1秒就排查慢查询，打开MySQL慢查询日志：

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;

压测完成后查mysql.slow_log表，看哪些SQL没走索引。任务列表的SQL一般要确认idx_status和idx_assignee两个索引生效，否则数据量到几百条就会明显变慢。

第二个技巧是给系统加一个操作日志查询页面。任务管理系统要证明自己有价值，不能只有任务表，得有日志表记录“谁在什么时间把任务从什么状态改成了什么状态”。答辩时老师问“系统怎么保证可追溯”，你直接打开日志页面给他看，比任何解释都有说服力。

第三个技巧是整理演示环境和初始化脚本。我见过很多人的项目里全是脏数据，一演示就露馅。我的习惯是收尾前清掉测试数据，把初始化脚本放在项目根目录的sql/文件夹里，包含建库、建表、插入测试用户和任务数据的完整流程。启动项目时先执行这个脚本，保证任何评委拿到项目都能一分钟跑起来。

这三个技巧不需要增加任何论文篇幅，但能让答辩的实感强很多。基于web的任务管理系统看起来普通，能做到“状态流转有规则、权限过滤有边界、操作过程可追溯”，就已经是一个完成度很高的毕业设计。希望帮到你。

本文还有配套的精品资源，点击获取