企业官网建设流程全解析

一说到“SSM+Vue任务管理系统”，很多人第一反应是“又是个老掉牙的选题”。但真把这个题目做完、吃透，你会发现它其实是毕业设计里最划算的投入：后端有Java企业级开发的经典三件套，前端有Vue的组件化思维，业务上又能把“任务创建—派发—执行—反馈—验收”这条全流程讲圆。这次我用一个完整的实战复盘，把从选题拆解、数据库设计、后端接口到前端联调、部署答辩的全程细节都过一遍，尤其会写很多常规教程里不会提的坑。

这个系统适合两类人：一是毕设选了类似题目、想快速搭出一个能通过答辩且代码干净的项目；二是虽然没选这个题，但想拿一套小团队协作工具练手、梳理SSM+Vue完整开发链路的人。全文我会按“先想清楚业务，再写代码”的思路来，不堆砌花哨功能，只把最核心的部分讲透。

1. 项目价值与选题逻辑

1.1 这个题目为什么经久不衰

“任务管理”四个字听起来朴素，但它几乎是所有管理信息系统的底盘。不管你是做政务OA、企业内部流程、项目协作平台，还是各类专项任务跟踪，核心都离不开“任务”这个数据实体的创建、分配、状态更新和结果归档。选这个题目，意味着你不需要去理解复杂的人工智能算法，也不需要死磕高并发架构，而是把精力集中在最标准、最容易被评审老师认可的业务闭环上。

技术栈上，SSM搭配Vue是很多院校软工、信管、计科专业的默认配置。Spring把对象管理交给容器，SpringMVC负责请求路由和参数绑定，MyBatis搞定数据库访问，前端用Vue做单页应用，Axios做接口通信。这套组合的生态资料极其丰富，遇到问题随便搜都有解决方案，对毕设周期来说是极大的时间保障。更重要的是，SSM是Java方向求职的重要基础，做完这个项目你对依赖注入、控制反转、ORM、前后端分离等概念会有真正体感，而不再停留在刷面试题的层面。

1.2 适合谁做，能学到什么

如果你手头有一两学期的Java基础课知识，但没写过完整的Web项目，这个选题上手最合适不过。它的工程量说大不大，说小不小：后端大概要写七八个实体类、十来个Mapper接口和对应XML、六七个Controller；前端则是登录页、布局框架、任务列表、任务表单、统计面板等几个核心页面。这种规模刚好能让你在几周内完成，但又足以逼你搞懂项目结构、调试技巧和部署流程。

我能明确告诉你的是，做完这一整套，你应该获得三项硬技能。第一，能独立把一张数据库表设计出来，并且想清楚字段之间的关联和状态如何流转。第二，能顺着一条请求链路从前端点击按钮开始，一路追到后端接口再到数据库SQL，定位并修复问题。第三，能理解权限控制的基本套路，知道为什么不能只在前端藏掉一个按钮就当作权限控制，后端必须再做一层校验。这些能力不华丽，却是毕业之后进企业最常用的基本功。

2. 系统需求分析与功能架构

2.1 角色模型与业务边界

做毕设最容易犯的毛病是一上来就写代码，写到哪算哪。合理的顺序是先定角色，再用角色反推功能边界。任务管理系统的标配用户角色有三种：管理员、部门负责人、普通执行人。管理员负责系统全局配置，比如维护部门信息、分配权限；部门负责人负责在部门内部创建任务、指派给具体人员、审核执行结果；普通执行人登录后看到自己名下的任务，填报进度、提交完成申请。

以军队任务管理场景为例（也适用于其他单位内部事务管理），对保密性、责任追溯有较高要求，所以“谁创建、谁派发、谁执行、谁验收”要在任务数据中全程留痕。因此系统中必须有人、时间和状态三个维度的日志记录，这既是业务需求，也是后面答辩时可以讲清楚的亮点。

如果只做简单的“增删改查”，很容易被老师发问后答不上来。你需要额外设计两个细节：一是任务的层级关系，即一个大任务可以拆分为若干子任务；二是任务的紧急程度与优先级，支持到期提醒。这两点会让系统从“玩具”变成“可用”，而且不增加太多开发量。

2.2 任务生命周期设计

任务管理系统的核心玩法就是状态机。我建议把任务状态拆成五个：待接收、进行中、待验收、已完成、已驳回。完整流程是这样：负责人创建任务，指定执行人和截止时间，此时任务状态是“待接收”；执行人登录系统后看到新任务，点击“接收”，任务变为“进行中”；执行过程中可以多次提交进度；完成后点击“提交验收”，任务变为“待验收”；负责人查看执行结果，如果合格就点“验收通过”，状态变更为“已完成”；如果不合格则填写驳回原因，状态回退到“进行中”。

这里有一个很容易被忽视的坑：状态回退时，之前填写的进度记录不能丢，而且最好把驳回原因也作为一条记录保存进数据库。不要把驳回原因只放在操作提示里，那样一旦刷新页面就没了。我的做法是建一张TaskLog表（任务日志表），每次状态变更、进度提交都会插入一条记录，前端详情页按下时间倒序渲染。这个设计在答辩时拿出来讲，“可追溯审计”三个字一说出口，老师基本不会再追问。

2.3 从流程图到功能清单

在正式编码之前，可以把上面的生命周期画成一张简单的角色功能矩阵，横向是三种角色，纵向是任务各阶段。然后整理出系统所需要的基本页面：

• 登录页（支持校验码、密码MD5加密存储）
• 首页/工作台：显示待办任务数、未读通知、最近任务动态
• 任务管理列表：支持搜索、筛选、排序、分页
• 创建/编辑任务弹窗或页面
• 任务详情页：显示任务信息、进度时间线、验收结果
• 部门管理（管理员用），用户管理（管理员用）
• 个人中心：修改密码、查看自己执行的任务

功能清单出来后，最好再对照数据库表结构草案走一遍：每个页面需要读取哪些表、写入哪些表，确认没有遗漏。这样做的前提是数据库设计先行，也就是下一篇要讲的内容。

3. 数据库设计与核心表结构

3.1 基础表设计与字段命名的取舍

数据库设计是整个项目的地基，最怕的是边开发边改表结构。我推荐至少要包含五张核心表：用户表（sys_user）、部门表（sys_dept）、角色表（sys_role）、任务表（task）、任务日志表（task_log）。

用户表的基本字段包括id、username、password、real_name、dept_id、role_id、phone、status。这里有两处细节值得注意。第一，password字段存的是摘要值，而不是明文，我会用MD5加一个固定盐再存，虽然不算绝对安全，但对毕设级别够用，也能体现安全意识。第二，role_id建议直接存在用户表里而不是建中间关联表，因为一个用户在当前系统中只需要一个角色，加中间表既增加复杂度又没有带来实际收益。如果有人质疑“为什么不规范化”，你就可以回答：“在设计取舍上，我优先考虑了查询效率和实现简单，当前业务约束下不存在多角色冲突。”

部门表字段相对简单：id、name、parent_id、leader_id。leader_id关联用户表的负责人，这样部门负责人登录后，可以根据dept_id快速查到本部门人员，再查出他们名下的任务。

3.2 任务表设计：字段和业务约束

任务表是整个系统的重头戏，字段要最克制、最够用。我的设计如下：

• id：主键自增
• task_name：任务名称，不能为空
• task_desc：任务描述，用TEXT类型
• priority：优先级，0普通，1紧急，2特急
• status：当前状态，用int类型，0待接收，1进行中，2待验收，3已完成，4已驳回
• create_user：创建人id
• execute_user：执行人id
• audit_user：验收人id（默认与create_user相同）
• start_time、end_time：开始时间和截止时间
• parent_id：父任务id，用于子任务关联
• create_time、update_time：通用审计字段

在业务约束层面，我强烈建议加两个数据库索引。第一个是execute_user字段的普通索引，因为列表页最常执行的查询就是“查某个人的任务”。第二个是status字段的索引，因为统计功能（比如待办数量）需要按状态筛选。没有索引遇到几百条数据感觉不出来，一旦数据量到几万级，查询卡顿就会非常明显，这个优化点写进论文能加分。

另外，parent_id是需要留意的字段。如果某个任务被拆成多个子任务，子任务的parent_id指向父任务id。查询父任务详情时，可以查出所有子任务列表。我这里没有把父子任务的进度做实时汇总，因为那样会涉及递归查询和更新同步，对毕设项目来说收益不大，做了一个简单的“手动刷新汇总”就足够了。

3.3 任务日志表与统计字段

任务日志表是体现系统成熟度的关键。每次操作都会记录一条日志，字段包括id、task_id、user_id、action（1接收，2提交进度，3提交验收，4验收通过，5驳回）、remark（备注或驳回原因）、create_time。写进度时，还可以在前端把“完成百分比”作为remark的一部分传入，同时我在任务表里加一个progress字段，用来保存当前进度百分比，列表页直接显示进度条。

如果你希望工作台首页有统计图（这是答辩展示的加分项），可以用一个统计视图或者简单SQL，按状态分组统计任务数量。例如“SELECT status, COUNT(*) FROM task GROUP BY status”，前端用Chart.js或ECharts画成饼图/柱状图。不需要额外建统计表，实时查询即可，毕竟数据量不会很大。

4. SSM后端开发实操

4.1 项目分层与SpringMVC控制器的设计

后端我习惯按“Controller—Service—Mapper”三层来分包：controller、service（含impl）、mapper（含xml）、entity、common（放统一返回结果、全局异常处理）。这种分层结构清晰且是主流面试问题的基准答案。

Controller层不要写任何业务逻辑，只做两件事：接收参数、调用Service并返回统一结果。我自封了一个Result类，属性是code、message、data，配合泛型使用。成功时code为200，失败时code为500。这样前端Axios拦截器就可以根据code统一判断请求是否成功，不用每个接口都去处理各种异常情况。另外，所有接口路径统一加个前缀/api，比如/api/task/insert。这个改动对后续部署配置Nginx转发时很省事。

写Controller时还有一个细节：参数校验不要只依赖前端。比如创建任务时，taskName为空、executeUser不存在，后端都要能拦截并返回明确提示。我这里用了注解校验，比如@NotBlank(message = "任务名称不能为空")，然后在方法参数上加@Valid。一个简单的参数校验就能避免很多无意义的空数据写入数据库。

4.2 MyBatis动态SQL与状态流转更新

Service层中最重要的方法，一个是创建任务，另一个是更新任务状态。我们来重点看状态更新的实现。假设执行人点击“接收”，前端传taskId和userId过来，后端要做什么？先检查任务是否存在，再检查状态是否符合（必须是待接收状态才能转到进行中），检查当前登录用户是否为执行人，最后执行UPDATE并插入日志表。

这个“先校验再更新”的顺序千万不要颠倒。我在MyBatis XML里写UPDATE语句时会加上条件限制，例如：

<update id="updateStatus"> UPDATE task SET status = #{newStatus} WHERE id = #{taskId} AND status = #{expectStatus} </update>

这样即使前端请求被恶意篡改，只要状态不对，受影响行数就是0，事务最终回滚，不会产生脏数据。这是并发环境下防止状态覆盖的简单有效做法，也可以作为论文中的一个“技术难点”来写。

MyBatis动态SQL用得最多的是列表查询的查询条件。根据前端传来的keyword、status、priority、executeUserId动态拼接WHERE条件，用 标签判断即可。有一点我要提醒：如果查询条件允许传时间范围，而你没有指定，前端传了空字符串过来，容易导致SQL报错。所以在Controller层要做参数预处理，把空字符串转成null，再传给Mapper。

4.3 登录校验、拦截器与跨域配置

登录逻辑我是这样设计的：登录成功后将用户对象和登录标记写入Session，同时返回前端用户基本信息；写一个拦截器继承HandlerInterceptor，重写preHandle方法，判断Session中是否有登录用户，没有则返回401和一个提示码。然后把拦截器注册配置到SpringMVC配置类中，排除掉登录接口和静态资源。

还有一个开发中几乎必踩的坑：跨域。前后端分离开发时，前端跑在Vite默认的5173端口，后端跑在Tomcat 8080端口，浏览器会拦截跨域请求。解决办法是后端配置一个CorsFilter，允许指定来源访问，设置允许携带凭证。注意如果你在拦截器中使用了Session，则跨域配置里allowCredentials必须为true，而且allowedOrigins不能使用“*”，需要指定前端的具体地址，否则浏览器会给你一个晦涩难懂的报错。

4.4 登录密码的加密与安全处理

密码存储这一块，我见过很多毕设代码演示里直接把明文存进数据库，答辩时万一被问到“你是怎么保证安全的”就会卡壳。我建议每个用户默认密码设置为123456，新建用户时不接收明文密码，而是存MD5加盐后的值。具体做法是：取固定字符串（可以定义为常量）加上原始密码，整体做MD5，再用MD5的输出做一次SHA-1。这样光看数据库字段没人能还原出原始密码。

登录时先按用户名查出用户，校验状态是否为1（启用），再把输入密码做同样处理比对摘要值。比对通过后写入Session。如果要更严谨可以加BCrypt，但考虑到毕设项目底子本来就以体现流程为主，MD5+SHA-1的叠加方案足够，而且解释起来不费劲。

5. Vue前端实现要点

5.1 前端工程与目录结构规划

前端部分我用Vite搭建基础工程（也可以用Vue CLI，差别不大），整体目录结构按功能划分更清爽：api目录放所有接口请求模块，每个模块按业务命名，比如task.js、user.js、dept.js；router目录放路由配置；store目录使用Pinia管理登录状态和用户信息；views目录放页面组件；components目录放公共的弹窗、表格、分页等复用组件。

组件复用的价值很容易被低估。比如任务列表页里“变更状态”的确认弹窗，和任务详情页里的“驳回原因填写”弹窗，其实结构非常相似。如果直接把代码复制两遍，后续要改弹窗标题或者按钮样式就得改两个地方。我抽出来的一个BaseConfirmModal组件，接收title、content、visible和确认回调，用户操作统一走这个入口。代码量多了一点点，但维护成本大幅下降。

路由配置上，我建议用懒加载方式引入页面组件（把动态import放进routes数组），这样首屏加载会快很多。做一个简单的NProgress顶部进度条，也能让切页面时感官更流畅。这些细节不会增加太多工作量，但对使用体验和答辩演示流畅度影响明显。

5.2 Axios请求封装与响应拦截器

接口请求我会封装成一个request.js工具文件。基础逻辑是：创建Axios实例，设置baseURL为/api，设置withCredentials为true（保证Session的Cookie能携带），并设置超时时间。在请求拦截器里，从Pinia中取出token或者直接从SessionStorage里取user，如果有就往请求头塞。在响应拦截器里，读取后端Result结构，如果code不是200，就通过Element Plus的Message组件弹出错误提示；如果是401，则清楚本地登录信息并跳回登录页。

这里有个很重要的设计：拦截器统一处理的好处是，页面业务代码只需要关心成功数据。比如任务列表的请求：

export function fetchTaskList(params) { return request.get('/task/list', { params }) }

页面里调用后拿到response.data就能直接用了，错误提示全由拦截器搞定。这样代码非常干净，也方便后续统一调整错误处理策略。

5.3 任务列表页与动态表单的实现

任务列表页是整个前端工作量最重的地方。上方是搜索筛选区，有任务名关键词、状态、优先级三个过滤项；中间是一个表格，展示任务名称、执行人、优先级、状态、截止日期、操作按钮。状态我用Tag标签显示不同颜色：待接收灰色、进行中蓝色、待验收橙色、已完成绿色、已驳回红色。这样演示时视觉反馈很明显。

操作按钮需要根据状态和当前用户角色显示：待接收状态执行人显示“接收”按钮，进行中显示“提交进度”“提交验收”，待验收状态创建人显示“验收通过”“驳回”。这里有两种做法，一是v-if根据角色和状态写条件，二是在后端接口里返回可操作的按钮列表。我当时用的是后端返回actionList字段的方式，好处是前端逻辑简单、权限控制后端化，但也意味着后端要多写一点枚举判断。对毕设来说，用v-if写法直观更易懂，答辩也容易讲明白。

创建任务表单的重点是动态绑定执行人选项。负责人登录后，前端先请求部门用户列表的接口，然后把数据渲染成下拉框。这里要注意：执行人必须是部门内的启用用户，而不是全部用户。所以后端接口要设计成deptId参数，联合用户表和部门表查询。

5.4 路由守卫与菜单联动

系统里不同角色的菜单显示不能一样。我的做法很简单：前端菜单项配置里带有roles字段，渲染侧边栏时通过Pinia里的用户角色做过滤。但是这里要强调，前端菜单隐藏仅仅是为了用户体验，真正的权限控制靠后端接口校验，不然懂技术的人直接调接口就能越权。

路由守卫写在router/index.js的beforeEach钩子里，逻辑是这样的：如果当前访问路径不是“/login”，且本地没有用户信息，就重定向到“/login”。如果已经登录了，但访问“/login”，就重定向到“/home”。守卫里还要做一个动态加载菜单的初始化动作，如果用户信息已经有了，但菜单列表是空的，就根据用户角色去组装菜单并返回true。理解这几行路由守卫逻辑，能让你在答辩时应对关于权限的追问。

前端还有一块容易忽略的是进度条展示。任务详情页会展示所有子任务的完成进度，我这里用了一个进度条组件，progress字段值为0到100，根据值显示不同颜色。低于30显示红色，30到80显示黄色，超过80显示绿色。纯视觉细节，答辩时演示出来会让人觉得你考虑得很完整。

6. 部署、避坑与答辩准备

6.1 环境准备与前后端构建部署

开发环境的准备，我相信你已经比我当初顺利多了：JDK 1.8、Maven 3.6+、Tomcat 8.5、MySQL 5.7，前端Node.js 14以上。IDE用IDEA即可，前端用VS Code写Vue组件。

构建部署时，我踩过一次很深的坑：后端打War包放到Tomcat里运行，前端build出来的dist目录放哪里？最稳妥的是把dist里的文件复制到Tomcat的webapps/ROOT下，然后让后端接口的baseURL都走根路径加上/api前缀。这样域名或端口下访问根路径就是前端页面，访问/api路径就是后端接口。不过要注意，如果直接放ROOT，需要先清掉Tomcat自带的文件，否则会覆盖。这个过程操作不难，但文档里写清楚能省不少事。

前端的环境变量也要配置好。开发环境的baseURL是http://localhost:8080/api，生产环境的baseURL是/api（同域名下的相对路径）。Vite里可以建.env.development和.env.production两个文件，通过import.meta.env.VITE_API_BASE读取。这个配置方式几乎是必考的。

6.2 常见问题速查表

我必须把一些低概率但高杀伤力的问题列出来，免得你在答辩演示时翻车。

6.3 答辩现场高概率被问到的问题

答辩时老师通常不关心你会不会写代码，而是关心你写的时候想没想清楚。我整理了十个高频问题，提前准备答案能让你更从容。

第一，“如果任务数据量很大，你怎么优化？”参考答案分三层：SQL层加索引，列表页分页查询，再提升就是引入Redis缓存热点统计数据和做读写分离，但不建议说得太深，以免被追问细节。

第二，“你这个系统是怎么保证任务不会被重复接收？”我的答案是数据库状态字段加乐观锁更新，UPDATE时用“WHERE status=待接收”来保证只有一次成功。

第三，“权限控制你是怎么做的？”答两点：后端拦截器校验登录状态，接口内根据当前用户id判断操作权限，前端菜单只是体验优化。

第四，“父子任务你为什么要这样设计？”重点是任务可以拆分，子任务继承父任务的部分字段，通过parent_id关联，形成树形结构。

第五，“日志表会不会导致数据量无限增长？”可以答：日志是审计需要，可以考虑定期归档到另一个表。

第六，“为什么选SSM而不选Spring Boot+Vue？”这种问题要得体地答：SSM能更直观理解SpringMVC和MyBatis的底层配置逻辑，对学习更友好；如果表达对Spring Boot的掌握，可以补充说“现在也能用Spring Boot迅速搭成同样结构的项目”。

第七，“你的密码加密是怎么做的？”把MD5加盐和SHA-1组合的方案讲清楚，再补充一句“真实生产环境建议直接使用BCrypt”。

第八，“项目里面你遇到最大的困难是什么？”这是一个展示你思考深度的机会，讲跨域问题和状态流转并发处理都是好素材，重点讲你怎么排查的，而不是只讲结果。

第九，“任务提醒功能怎么实现？”可以答：列表里根据截止时间和状态计算超期标识，入库时判断并变成红色标签；如果要说定时提醒，就需要引入定时任务和WebSocket推送，可以作为扩展点一句话带过。

第十，“这个项目能直接上线用吗？”答案是：演示功能完整，但生产级还需要加强安全配置、防止SQL注入、引入日志框架等。既承认不足，又说明你知道怎么改进，比硬吹要稳妥。

7. 论文撰写的几个实用写法

论文这块我不展开讲大框架，只说三个特别加分的写法。

第一，需求分析章节不要只写“系统需要任务管理功能”，而要写清楚角色的痛点。比如“当前用表格和口头沟通方式派活，进度不透明，验收无依据，因此需要系统实现任务的线上闭环管理”。这样拔高了项目的价值。

第二，技术可行性分析要结合项目实际。不要空话套话，可以具体写“SSM中各层职责不同，Controller分发请求、Service处理业务逻辑、Mapper访问数据，配合Vue组件化开发，使前后端并行开发成为可能”。一句话就体现出你真懂这套架构。

第三，系统测试章节不要只写“测试用例都通过”。认真写几个典型测试用例，比如“测试用例T01：执行人接收已验收的任务，预期返回状态不允许操作”，配合截图放进去，论文信服力会强很多。

另外，论文里的截图数量一定要足够多，高清、关键步骤都要截下来，尤其是登录、创建任务、验收驳回这条完整流程，以及统计图表的展示。答辩时老师最先翻的就是图表。

8. 后备扩展与真实体验

我个人的体会是，这类经典项目最大的价值不是“能跑”，而是让你完整走一遍从业务到技术再到交付的过程。当你把任务管理系统的前后端跑通后，你会突然看懂很多企业级项目的套路：无非是数据建模、接口设计、权限控制、状态流转那一套。换一个业务场景，只是表和字段不同，骨架几乎没有区别。

最后再分享一个小技巧：如果你想把项目做得比同题目的同学更亮眼，可以加一个“任务到期自动标红”的小功能。后端做定时任务，每天凌晨扫描一次任务表，把超过截止日期且状态不是已完成的任务标成超期。前端在列表里把超期字段渲染为红色标签。这个功能代码量不超过五十行，但答辩演示时很容易让人眼前一亮。

希望这篇复盘能帮到你。接下来该动手建表了。