基于Spring Boot+Vue的小微企业项目管理系统开发实战

1. 先弄清楚小微企业到底需要管什么1.1 一个真实场景三个人同时追着问项目到哪了我在帮一家做定制软件开发的小公司做内部工具时老板跟我说了一句特别扎心的话我每天一半的精力都在问进度不是在管项目。这就是小微企业的真实状态。公司可能就二三十个人同时开着四五个项目每个项目两三个人负责。客户在微信里问进度怎么样了老板转头去问项目经理项目经理再去问开发开发说快好了还有个功能没测。一圈问下来半小时过去了最后得到的答案还是一个模糊的快了。这其实就是我选择做这个小微企业项目管理系统的最直接动机——不是要做一个对标 Jira、禅道的大型平台而是要解决项目信息散落在微信群、Excel、口头汇报里这个最要命的问题。Java 技术栈在这个场景里非常合适生态成熟、招人容易、资料多尤其对于计算机毕业设计来说市面上能找到的参考案例和开源组件都非常充足。1.2 这套系统要解决的四个核心问题在真正动手之前我先把这个系统的定位想清楚了。它不是简单地把项目管理流程搬到线上而是要针对小微企业的特点重点解决下面四个问题第一个问题是项目信息透明化。所有项目、任务、进度、成员、文档都集中在一个系统里不再依赖微信聊天记录翻找。老板打开系统就能看到每个项目的整体进度项目经理能清楚每个成员手上有多少任务。第二个问题是任务闭环管理。从项目立项、任务拆解、分配、执行、提交、验收每个环节都有明确的状态和负责人避免这事我好像交给谁了但又好像没交的情况。第三个问题是沟通留痕。项目相关的讨论、附件、变更记录都沉淀在系统里。哪天客户说我没说过要改成这样你翻出系统里的沟通记录问题就清楚了。第四个问题是进度可量化。不靠感觉汇报快了差不多了而是通过任务的完成情况自动计算项目进度用数据说话。这套系统的核心用户角色就三类管理员、项目经理也可以叫项目负责人、普通成员。管理员管人员和系统配置项目经理建项目、拆任务、看进度普通成员领任务、提交付、写工时。没有复杂的组织架构、没有跨部门审批流把这三类角色管好了系统的基本骨架就立住了。2. 技术栈定稿面向毕业设计的最优组合2.1 后端Spring Boot MyBatis-Plus 的组合逻辑技术选型这件事我见过太多人一上来就纠结。实际上对于毕业设计级别的项目管理系统后端用Spring Boot MyBatis-Plus MySQL就是最稳的组合没有之一。Spring Boot 选 2.7.x 版本就好别一上来就追 Spring Boot 3。原因很实际3.x 基于 Jakarta EE很多网上现成的代码和教程都是 2.x 的遇到问题你搜到的答案大概率不适用。Java 版本用 8 或者 11这也是目前绝大多数公司生产环境的标配答辩的时候也经得起问。ORM 框架我选了 MyBatis-Plus 而不是原生 MyBatis 或者 JPA理由很直接MyBatis-Plus 的BaseMapper提供了单表 CRUD 的现成方法写项目管理系统这种以单表操作为主的业务能省掉大量重复的 XML 映射文件。同时它还带了分页插件、代码生成器、字段自动填充这些实用功能开发效率提升非常明显。我用了它的代码生成器连表结构设计好之后entity、mapper、service、controller 四层代码一键生成然后再去改造具体的业务逻辑。这里要说一句生成器只是辅助业务逻辑必须自己写清楚不然答辩的时候老师问你怎么实现某个功能你答不上来那就很难看了。2.2 前端Vue3 Element Plus 还是服务端渲染前端方案上我建议优先选Vue 3 Element Plus Axios的前后端分离模式。原因有两个第一项目管理系统本身就是典型的表格 表单 弹窗密集型应用Element Plus 的表格、表单、树形控件、日期选择器都是现成的开发效率极高第二前后端分离是目前行业主流方案毕业设计用这个架构答辩时可以讲的东西更多比如跨域处理、接口鉴权、路由守卫这些都能展开说。如果你的前端基础比较薄弱不想碰 Vue 工程化和 npm 那一套也可以退一步用 Thymeleaf 服务端渲染加 AdminLTE 或 Bootstrap 模板。但坦率地说工作量不一定小而且效果打分通常会差一些。我自己的经验是Vue3 Element Plus 的学习成本并没有想象中高照着官方文档和几个开源后台模板改三四天就能上手。前端用 Vite 构建配置代理解决开发环境的跨域问题。生产环境打包后扔到 Nginx 里前端静态资源由 Nginx 托管/api开头的请求反向代理到后端的 8080 端口。这个部署方案简单可靠也是我在实际项目里反复验证过的。2.3 数据库、缓存与部署选型数据库就用 MySQL 8.0。需要注意MySQL 8 的默认字符集是utf8mb4在建库的时候显式指定一下避免以后存 emoji 表情或者特殊符号时出现乱码。缓存这块如果项目里要用 Redis务必要想清楚用它来做什么。我见过不少毕业设计为了用 Redis 而用 Redis最后只是在登录的时候存了个 token这其实没有体现 Redis 的价值。在这个项目里合理的用法是把系统配置信息部门成员列表项目进度统计结果这类读多写少的数据缓存起来并在数据变更时主动清除缓存。这样设计答辩时才能说清楚 Redis 解决了什么问题。部署环境方面本地开发就是一台笔记本生产环境我建议用一台 2核4G 的云服务器装好 JDK、MySQL、Nginx、Redis 就够了。整个系统跑下来内存占用大概 1.5G 左右这个配置完全够用。3. 模块设计与功能边界3.1 项目管理与立项审批项目模块是整个系统的数据源头。我在设计的时候把项目分成以下几个核心字段项目名称、项目编号、客户名称、负责人、开始时间、预计结束时间、项目状态、优先级、项目描述。项目状态我设计了四个未开始、进行中、已暂停、已完成。没有搞复杂的审批流因为小微企业里项目立项通常就是老板拍板的事搞一层管理员审批就已经算流程固化了。项目经理提交立项申请管理员审核通过后项目才进入进行中状态这个流程既体现了管理的规范性又不会因为流程太重让人不想用。项目列表页要有筛选和搜索功能按状态、负责人、时间范围筛选按名称或编号模糊搜索。这里我用的是 MyBatis-Plus 的LambdaQueryWrapper动态拼接条件前端传什么条件就拼什么条件注意所有查询条件都用参数绑定防止 SQL 注入。3.2 任务拆解与状态流转设计任务模块是这套系统的核心中的核心也是工作量最大的部分。一个项目下面挂多个任务任务可以设置父任务形成两级层级——一级是模块/阶段二级是具体任务。为什么只要两级因为小微企业项目本身就不大拆成三四级任务树反而增加管理成本两级足够用了。任务字段包括任务名称、所属项目、父任务、执行人、创建人、优先级、开始时间、截止时间、任务状态、完成进度、任务描述、附件。任务状态流转我用了五个状态待领取→进行中→待验收→已完成另外还有一个已驳回的状态。流转规则是这样的项目经理创建任务后任务处于待领取状态也可以直接指定执行人指定后自动变为进行中执行人开始工作任务状态变为进行中执行人提交交付物任务状态变为待验收项目经理验收通过任务变为已完成如果验收不通过项目经理驳回任务回到进行中同时系统生成一条驳回记录这个状态机看着简单但我在数据库设计时把状态流转的判断写在了 Service 层而不是数据库层。也就是说状态变更的核心逻辑用 Java 代码控制非法流转直接抛异常拒绝操作。这样做的优点是逻辑清晰、易于调试缺点是需要保证并发情况下状态不会乱。对于毕业设计这个体量Service 层校验就足够了。3.3 协作沟通与消息通知项目管理系统如果只有任务管理没有沟通功能那就和 Excel 表格没什么区别了。我在系统里做了一个轻量的项目动态模块所有关键操作都会产生一条动态记录比如张三创建了任务【登录页面开发】李四将任务【支付接口联调】提交验收王五上传了文件【需求说明书V2.pdf】。这些动态会按时间倒序展示在项目首页相当于项目的时间线。实现的思路很简单定义一个ProjectLog表每个关键业务动作在 Service 层记一条日志前端轮询或者页面加载时查询即可。不需要引入消息队列或者 WebSocket 那套复杂的东西毕业设计阶段展示效果和代码量之间要平衡。消息通知我做了站内信的形式。当任务被分配、被驳回、被验收通过时系统会往相关用户的Message表里插入一条记录用户登录后在右上角看到未读消息的红点提醒。这个功能实现起来很简单但用户体验提升非常明显是个性价比很高的功能点。3.4 统计报表与进度可视化统计模块是我认为最能拉开系统档次的部分。我做了两个维度的展示第一个是项目进度。项目进度怎么算我采用的是任务完成比例加权平均的方式先算出每个任务的权重默认权重为 1如果有多个任务项目进度 已完成任务权重之和 ÷ 全部任务权重之和。比如一个项目有 5 个任务3 个已完成项目进度就是 60%。如果有些任务更重要可以给任务设置权重值 2参与计算。第二个是成员任务负载。统计每个成员当前正在进行中的任务数量和即将到期的任务数量展示在成员管理页面。老板一看就知道谁手头活太多谁的排期太闲既能避免任务分配不均也可以作为答辩时的一个亮点——这种基于数据的资源调配思路比单纯列任务清单有深度得多。进度展示用 ECharts 的饼图、柱状图和折线图。项目进度用环图展示完成百分比任务状态分布用饼图每周完成任务数用折线图。ECharts 的配置项不难网上模板很多关键是数据结构要设计好后端接口返回的数据直接满足图表所需格式前端就不需要做太多转换。4. 数据库表设计毕业设计答辩时最容易被追问的地方4.1 核心表结构一览数据库设计是答辩时老师问得最细的部分表关系、字段类型、索引设计都会被追问。我的核心表设计如下表名用途关键字段sys_user用户表id, username, password, real_name, role_id, dept_id, status, avatarsys_role角色表id, role_name, role_key, descriptionsys_user_role用户角色关联表user_id, role_idpm_project项目表id, project_no, name, customer, owner_id, status, priority, start_date, end_date, description, deletedpm_task任务表id, project_id, parent_id, name, executor_id, creator_id, priority, status, weight, start_date, end_date, descriptionpm_task_log任务操作日志表id, task_id, operator_id, action, content, create_timepm_project_log项目动态表id, project_id, operator_id, action, content, create_timepm_comment任务评论表id, task_id, user_id, content, attachment_url, create_timepm_attachment附件表id, biz_type, biz_id, file_name, file_url, uploader_id, create_timesys_message站内消息表id, receiver_id, message_type, title, content, is_read, create_time这里我坚持了两个原则所有业务表都有逻辑删除字段deleted用户删除项目或任务时走的是逻辑删除而不是物理删除避免误删后无法恢复所有表都有create_time和update_time用 MyBatis-Plus 的自动填充功能维护。4.2 状态字段用 int 还是 varchar这是个看起来很小、其实很影响开发的决策。我的建议是状态字段用 varchar 存语义化的值比如IN_PROGRESS、COMPLETED而不是 0、1、2 这种数字。原因有两个第一可读性强查数据库的时候一眼就能看懂这条数据处于什么状态不用每次去翻代码里的枚举定义第二Java 枚举和字符串之间的映射非常自然用EnumValue注解就能实现 MyBatis-Plus 的自动转换代码层面依然是类型安全的。数据库层面给状态字段加上DEFAULT值并且用CHECK约束限定取值范围。MySQL 8 是支持CHECK约束的之前版本只是解析后忽略8.0.16 之后真正生效了。4.3 权限设计的取舍权限模型我选择了经典的RBAC基于角色的访问控制但做了一个简化用户 → 角色 → 权限菜单没有做到按钮级权限控制那么细。具体来说我建了sys_menu表维护左侧菜单树sys_role_menu表维护角色和菜单的关联关系。登录用户根据角色拿到自己可见的菜单列表后端接口用拦截器校验角色比如只有项目经理角色才能调用创建任务的接口普通成员只能查看和更新自己的任务。这里要特别提醒一个坑前端菜单隐藏只是体验问题真正的权限控制必须做在后端接口层面。如果只在前端根据角色隐藏按钮懂点技术的人直接拼一个接口地址就能绕过限制这在答辩时如果被老师提问到你的系统权限安全吗你是站不住脚的。所以接口层的角色校验必须要写哪怕只是一个简单的注解加拦截器。5. 关键代码实现几个不能糊弄的功能点5.1 基于RBAC的权限拦截我实现了一个RequirePermission自定义注解加在 Controller 方法上配合 Spring MVC 拦截器实现接口级权限控制。核心逻辑是这样的Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }然后写一个拦截器在preHandle中获取当前登录用户的角色和权限集合判断是否包含注解指定的权限标识public class PermissionInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod)) { return true; } HandlerMethod handlerMethod (HandlerMethod) handler; RequirePermission annotation handlerMethod.getMethodAnnotation(RequirePermission.class); if (annotation null) { return true; } // 从 ThreadLocal 或 Session 中获取当前用户权限集合 SetString permissions getCurrentUserPermissions(); if (permissions.contains(annotation.value())) { return true; } response.setStatus(HttpStatus.FORBIDDEN.value()); return false; } }权限标识的命名我用了project:create、task:assign、user:delete这种资源:操作的格式清晰且易于扩展。用户登录时把权限集合一次性查出来放进 Redis 缓存避免每个请求都去查数据库。5.2 任务状态机与操作日志任务状态的每次变化我都要求必须附带一条操作日志。实现方式是在 Service 层写一个统一的状态变更方法Transactional public boolean changeTaskStatus(Long taskId, String fromStatus, String toStatus, Long operatorId, String remark) { Task task taskMapper.selectById(taskId); if (task null) { throw new BizException(任务不存在); } // 校验当前状态是否等于 fromStatus防止并发导致状态错乱 if (!fromStatus.equals(task.getStatus())) { throw new BizException(任务状态已变化请刷新后重试); } // 状态流转合法性校验 if (!TaskStatusTransition.canTransition(fromStatus, toStatus)) { throw new BizException(不允许从[ fromStatus ]流转到[ toStatus ]); } task.setStatus(toStatus); taskMapper.updateById(task); // 记录操作日志 TaskLog log new TaskLog(); log.setTaskId(taskId); log.setOperatorId(operatorId); log.setAction(toStatus); log.setContent(remark); taskLogMapper.insert(log); return true; }我把状态流转规则封装在一个TaskStatusTransition类里用一个二维布尔数组或者Mapfrom, Setto来表达允许的流转路径。比如// 待领取 - 进行中/已完成进行中 - 待验收/已驳回等等这个设计的好处是把所有规则集中在一个地方修改流转规则不会影响到业务代码。答辩的时候说到我将状态流转规则集中管理防止非法流转老师会认为你考虑到了边界情况。5.3 进度自动计算的实现思路项目进度计算我是用定时任务加实时计算结合的方式。任务状态变更为已完成时立即触发一次所属项目的进度重算另外每天凌晨 2 点跑一个定时任务把没更新的项目也重算一遍防止遗漏。public BigDecimal calculateProjectProgress(Long projectId) { ListTask tasks taskMapper.selectList( new LambdaQueryWrapperTask() .eq(Task::getProjectId, projectId) .isNull(Task::getParentId) // 只统计顶层任务避免子任务重复计算 ); if (tasks.isEmpty()) { return BigDecimal.ZERO; } BigDecimal totalWeight tasks.stream() .map(Task::getWeight) .reduce(BigDecimal.ZERO, BigDecimal::add); BigDecimal completedWeight tasks.stream() .filter(t - COMPLETED.equals(t.getStatus())) .map(Task::getWeight) .reduce(BigDecimal.ZERO, BigDecimal::add); return completedWeight.divide(totalWeight, 2, RoundingMode.HALF_UP) .multiply(BigDecimal.valueOf(100)); }这里有个细节值得注意只统计顶层任务不计入子任务。如果父任务和子任务同时参与统计进度会被双重计算。比如一个父任务用户模块开发下面挂了登录页注册页两个子任务父任务完成后子任务也完成了如果不加过滤用户模块就贡献了两倍权重进度直接失真。6. 开发中踩过的坑清单6.1 MyBatis-Plus 自动填充失效我在sys_user表设计时create_time和update_time使用了 MyBatis-Plus 的自动填充功能配置了MetaObjectHandler实现类。结果发现通过insert方法插入数据时没问题但用updateById更新时update_time就是不更新。排查了半天原因是在实体类的update_time字段上我用了TableField(fill FieldFill.INSERT_UPDATE)这个配置本身没错问题出在代码生成器生成的实体里把 datetime 类型映射成了LocalDateTime而我在测试时传了一个null进去MyBatis-Plus 判定字段为 null 就不执行自动填充。解决方案是给字段加updateStrategy FieldStrategy.NOT_NULL的声明或者更简单的方法——在MetaObjectHandler的updateFill方法里获取不到旧值就直接setFieldValByName(updateTime, LocalDateTime.now(), metaObject)强制覆盖。这个坑很隐蔽但排查过程本身就是很好的面试素材。答辩时可以讲一讲MetaObjectHandler 的触发条件与字段策略的关系这是加分项。6.2 事务与嵌套调用我在任务状态变更方法上加了Transactional方法内部又调用了同一个类的另一个Transactional方法——插入消息通知。结果发现事务并没有像预期的那样合并消息通知插入成功了即使外层状态更新失败也提交了。原因很经典Spring 的声明式事务基于 AOP 代理同类内部方法调用不走代理所以内层方法的Transactional注解根本没生效。解决办法有两个一是把消息通知逻辑单独拆到一个MessageService类里通过注入该 Service 来跨类调用事务就会正确传播二是自己在内层方法里用TransactionTemplate手动控制事务。我选了第一个方案代码结构也更清晰——一个 Service 只负责自己的事务边界跨模块联动通过调用对方的 Service 实现。6.3 前端跨域与接口统一返回前后端分离开发时跨域问题是必踩的坑。我先在后端写了一个全局CorsFilter配置了允许的域名、方法和请求头同时前端 Vite 的server.proxy也配了代理。结果两边都配置之后反而出现了请求头重复、CORS 冲突的问题。最后我做了个决定**开发环境只靠 Vite 代理解决跨域后端不开放 CORS生产环境通过 Nginx 反向代理前后端同域不存在跨域问题。**这样前端代码里不需要处理跨域后端也不用写 CORS 配置逻辑最干净。另外我强烈建议接口统一返回结构public class ResultT { private Integer code; // 200 成功其他为失败 private String message; private T data; }所有接口统一返回Result前端 Axios 响应拦截器里统一判断code等于 200 才走成功逻辑否则统一弹错误提示。这样避免每个页面各写一套错误处理代码量少一半而且答辩时比较有体系感。7. 答辩与演示准备的实战建议7.1 演示数据与演示脚本系统开发完成后别急着截图写论文先把演示数据准备好。我的做法是造了 3 个完整项目、每个项目下面挂 8~12 个任务、任务全部做完或部分完成再配 5 个不同角色的用户账号。演示用的项目名称不要再用测试项目 1换成某电商平台小程序开发进销存管理系统升级这种真实感强的名称演示效果完全不一样。演示脚本一定要提前走两遍第一遍从登录开始按首页 → 项目列表 → 项目详情 → 任务管理 → 进度统计的主线走一遍第二遍挑一个能体现系统亮点的小场景比如新建一个任务并分配给成员然后切换账号模拟成员收到的待办提醒完成提交验收的完整闭环。这个闭环演示下来比罗列功能菜单有说服力得多。7.2 答辩高频问题如何应对根据我带过的学生的反馈毕业设计答辩基本绕不开这几个问题你这个系统相比 XX 系统有什么创新点不要硬吹技术多牛诚实一点说系统规模上无法和商业产品比较但针对小微企业场景做了三个优化轻量级任务状态机、基于权重的进度自动计算、操作日志驱动的协作时间线。这三点是你可以展开讲清楚的就是加分项。你遇到的最大困难是什么怎么解决的把踩坑经历讲出来重点描述排查思路而不是结果。比如事务并发问题你要说我通过给状态增加前校验解决了并发冲突通过拆分类解决了事务失效。为什么用这个技术方案从项目规模和技术匹配度来回答系统是典型的中小型 Web 应用Spring Boot MyBatis-Plus MySQL 组合经过大量生产验证学习资料丰富且足够支撑当前业务量。千万别从因为这个框架最流行的角度去答。7.3 后期扩展方向如果有人问你这套系统还能怎么发展或者说你答辩完之后想继续完善我建议往三个方向考虑一是引入 WebSocket 实时推送让任务分配和项目动态不再依赖轮询刷新消息体验从登录后看到红点升级为桌面浏览器直接弹提醒。二是增加数据导出功能把项目报表、成员工时导出为 Excel这在实际办公中是非常高频的需求。三是把系统部署到公网配合域名和 HTTPS 证书让团队成员真正用起来得到真实的用户反馈。哪怕只是一个小团队、小范围使用产出的改进意见也比空想出来的需求有价值得多。说实话做一个能跑通、能演示、能讲清楚的项目管理系统并不难难的是每个模块都真正想清楚为什么这样做。这套系统我从数据库设计到前后端代码前后用了一个多月踩了不少坑也积累了很多实际经验。如果你也在做类似的毕业设计按照上面的思路一步步来应该能少走很多弯路。过程中如果遇到具体问题欢迎随时交流。