手头正好有一套从需求梳理到落地的企业项目管理系统源码技术栈是 Java SpringBoot Vue3 MyBatis MySQL前端分离得挺干净拿来改吧改吧就能复用。企业项目管理系统这个题目听着大实际拆开无非就是“项目立项、任务拆解、进度跟踪、成员协作、工时统计”这几件事的数字化。这套系统解决的核心问题是让项目状态不再靠打听而是靠数据说话让任务分配不再靠口头而是靠流程闭环。如果你正准备做毕设、给公司内部搭一套项目管理后台或者想找一份能看懂、能改、能上线的前后端分离源码作为学习样板这篇内容能直接给你一条相对完整的路。我写这篇文章不打算只贴一段演示代码而是想把从库表设计到安全认证、从前端路由到接口联调过程中那些容易翻车的环节都摊开讲。这套东西拿来学习也好、二次开发也好核心价值在于它是典型的“业务系统标准形态”——有用户权限、有CRUD、有状态流转、有统计报表覆盖了Java后端开发面试里高频出现的场景。读懂了这套项目SpringBoot的自动装配、MyBatis的Mapper机制、Vue3的组合式API、Pinia的状态管理基本都能串起来。1. 项目定位与技术选型思路1.1 企业项目管理系统到底管什么很多刚接触项目的人一上来就问“系统有哪些功能”但在我看先想清楚“系统要解决谁的什么痛点”更重要。企业项目管理系统的使用者通常有三类人项目经理要分任务、盯进度、汇总风险普通成员要查看自己的待办、提交进度、反馈阻塞管理层要看到人力和项目进展的全局视图。由此推导出的功能边界就相对清晰项目档案、项目成员、任务分解、任务状态流转、工时填报、项目看板、消息提醒。这套源码在这块做得比较克制没有硬塞一堆华而不实的图表插件而是围绕“任务流转”这个主线把项目的生命周期管起来。一个项目从“立项”开始经过“进行中”、“暂缓”、“完成”几个阶段每个阶段背后都有对应的任务状态数据支撑。项目维度有基础字段任务维度有优先级、指派、截止时间、实际工时成员维度有角色区分。整个系统跑起来之后项目干系人看到的不是Excel里乱糟糟的表格而是统一入口的数据面板。1.2 为什么是SpringBootVue3MyBatisMySQL这套组合技术选型这件事很多新人喜欢追新一上来就引入微服务、引入各种中间件结果项目还没跑起来先被概念淹没。这套系统选SpringBoot首先是生态成熟市面上的Java面试题、企业后端岗位要求几乎都围绕SpringBoot展开用它做后端底座无论是找人维护还是自我学习资料都足够多。Vue3做前端相比Vue2最大的变化是组合式API和更好的TypeScript支持后台管理系统的场景里Vue3配合Element Plus这类组件库做表格、表单、弹窗、权限控制的速度非常快。MyBatis做持久层理由更直接企业项目里的SQL往往需要精细控制特别是多表联查和动态条件筛选MyBatis的XML映射给了开发者足够的主动权。MySQL则是成本和技术门槛的双重考虑中小型企业的数据量级下它完全够用部署、备份、运维的文档也是一抓一大把。这套组合没有用Redis做缓存、没有上RabbitMQ做消息队列并不是说那些技术不重要而是项目的复杂度还没有到需要它们支撑的阶段。真正的业务系统开发永远是根据复杂度选型而不是根据技术潮流选型。加上Redis和MQ的工作量会让一个本该聚焦业务逻辑的项目变得难以收尾。2. 数据库设计与 MyBatis 映射2.1 核心表结构怎么划分数据库设计决定了业务逻辑的上限这绝对不是一句空话。这套系统的表结构围绕“组织-用户-项目-任务”四条主线展开角色权限相关表放到独立的模块里避免业务表和权限表混在一起。sys_user存用户基本信息sys_role和sys_menu管角色与菜单权限user_role做关联这三张表支撑了前端的动态菜单和接口鉴权。业务表这边project表记录项目名称、编号、开始结束时间、项目状态、负责人。project_member表记录项目成员和成员在项目内的角色这张表承担的是“项目资源”的概念成员加入项目之后才能被指派任务。task表是核心中的核心承接项目ID、任务名称、指派人ID、创建人ID、优先级、状态、计划开始时间、计划结束时间、实际工时。工时记录单独拆成task_work_log表每条记录对应任务ID和填写人ID这样后端的统计报表才有数据基础。我见过很多项目把附件、评论、日志全部塞进task表这是典型的反模式。一旦任务表字段过多索引失效、查询变慢、代码里各种if判断问题都会集中爆发。这套源码把日志、评论、工时分别拆表是符合企业系统常规做法的。2.2 关键联表查询与分页实现项目管理系统里最典型的查询是“任务列表页”它需要根据当前用户的角色和项目筛选条件查出任务列表同时关联用户名和项目名。用MyBatis写这类查询重点在于动态SQL的组装。如果直接把所有条件拼在XML里条件多的时候SQL会非常臃肿。合理的做法是在Mapper接口里定义一个复合查询对象包含任务实体、分页参数、筛选条件集合然后用where标签自动过滤空条件。分页这里用的PageHelper接入成本很低。在pom.xml引入pagehelper-spring-boot-starter然后配置一个拦截器插件业务代码里只需要在查询前调用PageHelper.startPage(pageNum, pageSize)后续的第一次Mapper查询会自动带上LIMIT语句。需要注意一个大坑PageHelper只能作用于紧跟它之后的第一条查询语句如果查询前做了其他Mapper操作分页就会失效。这是我调试时踩过的很实际的坑。MyBatis的XML映射文件里resultMap用来解决数据库字段名和Java实体属性名不一致的问题。当前很多团队喜欢把数据库字段直接写成下划线风格如project_name而Java属性用的是驼峰风格如projectName。最省事的办法是打开SpringBoot配置项map-underscore-to-camel-case: true让它自动转换。但遇到多表联查时重复字段名会绕过自动映射比如查询任务关联了项目名和用户名两个结果集里都有name字段这时候就必须用resultMap和别名手动指定。2.3 MyBatis缓存机制MyBatis的缓存分成一级缓存和二级缓存。一级缓存默认开启作用范围是同一个SqlSession在SpringBoot集成环境下SqlSession跟着事务走事务结束缓存就清空所以它对业务的影响通常感觉不明显。二级缓存默认关闭配置开启后每个Mapper命名空间内的查询结果会被缓存适合那些“读多写少且对实时性要求低”的数据。但注意一旦开启二级缓存这个命名空间下的增删改操作会触发缓存刷新如果多表联查时缓存了包含关联数据的对象其他表更新就可能带来数据不一致。我在实际项目里除非是字典表这类极稳定的数据否则不建议轻易开启二级缓存。面试题里经常问MyBatis的一级缓存会不会出现脏读答案是如果两个不同事务的SqlSession操作同一数据一级缓存隔离在各会话内部不会互相污染。但如果用了二级缓存又没有做好刷新策略脏读的概率就会明显上升。这套系统源码也是按这个思路处理基础数据表启用二级缓存核心业务表不启用。3. SpringBoot 后端落地实践3.1 工程结构怎么搭才不乱包结构这事很多小伙伴上来就按controller、service、mapper这样的技术分层去建包结果项目一旦变大找某个业务功能的代码要跨好几个包非常难受。这套源码采用的是“按业务域分包内部再按技术角色分层”的方式。比如project包下面有ProjectController、ProjectService、ProjectServiceImpl、ProjectMapper、ProjectMapper.xml、entity包下的Project.java、dto包下的ProjectQueryDTO。这样做的好处是业务内聚一个业务域的修改不会牵扯到其他业务域的代码结构。SpringBoot工程的基础配置核心在application.yml。数据源、MyBatis配置、日志级别都在这一份文件里看得到。端口、数据库名、密码这些可以放到application-dev.yml和application-prod.yml里做环境隔离。真正要注意的是密码和敏感配置不能硬编码构建打包时用环境变量的方式把数据库地址和账号密码注入进来避免把生产库密码提交到Git仓库里。3.2 基于 JWT 的登录认证与角色权限企业项目管理系统的后台权限设计是刚需。这套源码用的方案是JWT SpringBoot拦截器的方式登录成功后生成一个Token前端放入请求头携带后端拦截器校验有效性。JWT相比Session方案的好处在于服务端无需存储登录状态天然适配前后端分离和后续多实例部署的场景。Token生成时我会把用户ID、用户名、角色编码这些非敏感信息放进Claims里但绝不把密码放进去。拦截器主要验证Token的签名和过期时间解析出来的用户ID放进ThreadLocal或Request attribute里供后续业务方法直接获取当前用户。这里有个实际经验每次请求都查一次数据库拿完整用户信息会很耗性能所以Token里的用户基础信息要够用真正的用户权限可以在登录后一次性加载到前端由前端控制菜单和按钮显隐。权限的精细控制放在接口层面是更安全的做法。后端不仅要在拦截器里校验是否登录还要在Controller方法上通过自定义注解校验角色权限。比如项目经理才能操作“创建项目”普通成员只能查看。拦截顺序是登录校验 - 权限校验 - 业务处理。这套逻辑跟Spring Security很像但用注解加拦截器实现逻辑透明适合中小规模项目也方便面试时讲清楚你的完整思考链路。3.3 核心业务接口的设计套路任务状态流转这个接口是系统中最容易出问题的点。很多人会把状态流转写成一坨if-else看起来能跑但每加一个状态就要改一次代码。合理的做法是定义状态枚举每个枚举里定义允许的下游状态集合状态流转方法统一做校验。比如任务状态包括“待处理 - 进行中 - 已完成/已驳回”一个驳回操作会回到待处理一个完成操作会记录完成时间。这套设计模式保证了状态机的可维护性也是很多后端岗位面试的加分点。工时填报的逻辑也需要细致处理。任务工时如果允许反复修改会造成统计报表的数据不可信。实际做法是记录每一次工时填报的操作人、操作时间、变更前后工时形成一条操作日志而不是直接覆盖原记录。这样项目经理在查看人力报表时能追溯是哪个人在哪个时间点改了工时避免扯皮。这套源码里对应的就是task_work_log表的设计逻辑。新增、修改、删除这类基本接口核心是校验逻辑放在哪的问题。我个人的实践是参数基础校验用注解放在Controller比如NotBlank、NotNull业务语义校验必须放在Service层比如“任务不属于当前项目”、“项目状态不允许删除”。因为Controller层注解偏简单而格式正确不代表业务合法两层校验各司其职。4. Vue3 前端实现要点4.1 项目初始化和目录结构前端这块源码基于Vite构建的Vue3工程相比WebpackVite的开发服务器启动速度有质的提升改代码热更新基本是毫秒级。工程里用了Element Plus做UI组件库配合Vue Router做路由Pinia做全局状态。目录结构上src/api下按业务域拆分的接口请求文件src/views下是页面组件src/router下是路由配置src/store下是Pinia模块src/utils下是工具函数和请求封装。Vue3学习过程中最让人头疼的是组合式API和选项式API的区别。这套源码用的是组合式APIsetup语法糖写法更接近函数式组织逻辑。一个页面组件里按“响应式数据 - 计算属性 - 生命周期请求 - 方法”的顺序组织代码。如果某个页面的逻辑特别重甚至可以抽出成独立的composables函数比如useTaskList()这在后台系统开发里能显著提高代码复用率。创建Vue3项目的命令很简单npm create vitelatest project-name -- --template vue然后按需安装vue-router、pinia、axios、element-plus。但真正做到可用级别还需要额外处理几件事给Element Plus按需引入组件样式、配置路径别名指向src目录、统一封装全局的请求错误提示。这些都做好工程才能真正跑起来不报错。4.2 Axios 请求封装与跨域处理前后端分离的项目跨域是绕不开的问题。开发环境下前端跑在5173端口后端跑在8080端口浏览器的同源策略会拦截请求。常规解法是在Vite的server.proxy配置里把/api前缀的请求转发给后端地址这样前端发出的请求变成相对路径浏览器层面没有跨域问题后端也只需要允许本地代理访问即可。生产环境部署则通常用Nginx做反向代理把前端静态资源和后端接口统一挂在同一个域名下。Axios封装的核心不在请求本身而在拦截器。请求拦截器里统一加上Token头响应拦截器里统一处理HTTP状态码和业务码。比如登录过期返回401时拦截器统一跳转登录页并清除本地存储的用户信息避免每个页面都写一遍重复判断。业务码和HTTP状态码要区分开HTTP状态码代表传输层的成功或失败业务码代表业务层面的成功或失败比如“密码错误”“无操作权限”这两个码混淆会导致前端判断逻辑非常混乱。上传文件的场景也是一样普通的POST请求头是application/json文件上传必须使用multipart/form-dataAxios里直接用FormData对象传输不要手动设置Content-Type让浏览器自动带boundary边界符。如果手动指定了错误的内容类型后端接收文件时会解析失败。4.3 动态路由、路由守卫与 Pinia 状态管理后台管理系统的菜单应该是跟着用户权限走的。第一种方案是后端返回菜单列表前端动态注册路由第二种方案是前端预先定义好全部路由再根据用户权限过滤。两种方案各有优劣。这套源码采用的是第二种因为前端把页面组件全部写好了动态注册路由反而复杂过滤方案更容易实现。根据用户角色返回的权限标识去控制菜单显隐复杂度低且不容易出错。路由守卫使用Vue Router的beforeEach每次跳转前判断用户是否已经登录、页面是否需要权限。没有登录的强制跳转到登录页已登录但访问无权限页面时重定向到403或者提示页。这里有一个很容易踩的坑动态添加或过滤路由后如果router实例已经生成了某个路由再去修改它不会生效。所以路由表先定义一个基础白名单所有带权限的路由统一在登录后生成。Pinia管理全局状态的重点是保持响应式。用户信息、项目当前筛选条件、全局的消息未读数这些跨页面共享的数据放进Pinia其他状态尽量保持页面内局部。store模块里注意避免直接改后端返回的数据后端返回的对象应该拷贝一份再修改否则在严格模式下会报状态变更错误。在实际开发中保持“数据流单向”的思路会少遇到很多调试时理不清头绪的问题。4.4 表单校验与日期处理的细节Vue3后台系统的表单校验很多人忽略了对日期格式的校验。项目管理系统里的任务截止日期如果用户填了非法日期或早于今天的日期业务上是明显不合理的。Element Plus的表单校验规则里可以自定义validator比如“结束时间必须晚于开始时间”“截止时间不能早于当前时间”。面试题里也经常问到Vue3的表单rules校验这个系统里给了比较完整的示例。日期选择器默认返回的是Date对象或字符串这取决于value-format的设置。提交给后端前建议统一格式化为yyyy-MM-dd HH:mm:ss的字符串。这里有个细节如果前端传的是带时区的ISO字符串后端LocalDateTime解析时如果不加JsonFormat注解常见的表现是日期字段变成“2025-07-10T16:00:00.00000:00”这种格式前端展示时会出现8小时时差。这个问题在很多项目联调阶段都会出现最好的做法是全局配置Jackson的时间格式化而不是每个字段手动加注解。5. 前后端联调与部署细节5.1 本地联调的完整流程把前后端源码拿到手本地跑通整体流程的顺序很重要。第一步先准备MySQL数据库执行项目提供的init.sql脚本初始化库表结构和基础数据。第二步根据本机MySQL的地址、端口、账号密码修改后端application-dev.yml里的数据源配置。第三步启动后端SpringBoot应用确认控制台没有报错能正常监听8080端口。第四步在前端工程根目录执行npm install安装依赖再执行npm run dev启动开发服务器访问Vite输出的本地地址。联调的重点是用一个完整业务场景打通链路。我的习惯是先登录系统看Token能不能正常生成和写入请求头然后新建一个项目再给项目添加成员再创建任务给任务指派成员和填写工时最后在列表页看数据是否正常显示。整个过程能走通说明数据库、后端接口、前端路由、状态管理基本都正常。如果这些核心流程不通排查的方向就应该是数据库脚本或者接口请求路径。后端接口自测可以用Swagger或者Postman但为了联调效率我更推荐在后端启动后先用浏览器插件或Postman验证接口返回。如果后端接口返回正常再定位前端问题如果后端本身返回就不对优先看SQL语句和日志。日志级别调成DEBUGMyBatis会把执行的SQL和参数都打印出来这是排查数据库问题最直接的手段。排查完之后再调回INFO减少生产日志量。5.2 部署场景下的常见配置问题代码本地跑通之后部署是另一回事。前端npm run build生成静态文件Nginx配置root指向dist目录location /api/反向代理到后端地址。后端打包成jar包用java -jar或systemd托管运行。这里最隐蔽的问题是前端静态资源路径。如果前端配置了base: /部署在域名根路径是没问题的但如果部署在二级目录/admin下就必须改成base: /admin/否则JS和CSS资源会404。MySQL在生产环境的连接字符串要加上useSSLfalse和serverTimezoneAsia/Shanghai参数。不加时区参数可能出现日期错乱没有关闭SSL可能出现连接警告或失败尤其在云数据库或某些MySQL版本下。我遇到过数据库连接反复超时的问题后台看是默认连接池参数配置过小经调整maximum-pool-size和connection-timeout参数后才稳定。这些配置在本地开发时可能感知不强但部署到服务器上环境差异会把这些隐藏问题全部暴露出来。6. 常见问题排查与避坑建议6.1 启动阶段的典型报错MySQL连接失败这类问题占新手排查量的一半。首先确认MySQL服务是否启动Linux下用systemctl status mysqld查看Windows下看服务列表。其次确认密码是否写对默认的root账户如果设置了密码但配置里没填就会报Access denied。最后确认端口3306被占用或改了端口配置也要跟着改。MyBatis XML文件找不到SpringBoot项目如果Mapper的XML文件放在src/main/java目录下打包时不会自动拷贝到classes目录。解决方案是在pom.xml的build里把src/main/resources和src/main/java下的xml文件都纳入打包资源范围。很多人本地IDE能跑但一打包部署就报Invalid bound statement几乎都是因为这个。如果XML文件放在src/main/resources/mapper下然后在application.yml里配置mybatis.mapper-locations: classpath:mapper/*.xml80%的问题都能避免。接口返回404或405404通常是路径写错前端请求的/api/project/list后端Controller映射的却是/project/list前缀不一致。405则是请求方法不匹配前端用POST请求了后端只允许GET的接口。排查时先看后端控制台有没有请求日志再看返回的HTTP状态码这种问题五分钟内能定位。6.2 运行阶段的缓存与性能问题MyBatis的二级缓存如果开启到业务表上有一个典型的坑更新了A表但B表关联查询时用了缓存导致数据显示旧内容。实际表现是页面数据改了刷新还是不变化。解决办法是合理划分缓存空间或者统一在写操作时清理相关Mapper的缓存。这类问题排查起来慢最好在设计阶段就避免。分页性能这块任务列表数据量上来之后PageHelper的COUNT查询会额外消耗一定资源。如果业务允许可以关闭一些超大列表的总数统计直接“下一页”的方式替代页数跳转。另外MySQL的LIMIT在深分页时存在性能衰减比如第10万条数据LIMIT 100000, 20的扫描行数会非常大。查到后面页的数据变慢是预期行为可以配合WHERE id 某个值做游标分页来改善。数据库索引设计也直接影响运行阶段体验。task表的查询条件大概率围绕project_id、assignee_id、status展开应该建复合索引。但索引不是越多越好写频繁的表加太多索引会导致插入和更新变慢。这套系统源码里只给查询频率高且区分度高的列建了索引这个度是值得体会的。6.3 体验提升的一些经验实际项目中消息通知这个功能常常被当成锦上添花但我见过很多系统的使用率下滑恰恰是因为成员不知道任务被指派给了自己。如果你的项目管理系统要做消息提醒优先做站内信和待办角标不要一上来就对接短信、邮件或者企业微信推送。站内消息只需要一张消息表加一个定时轮询接口改动成本低但对用户体感提升非常明显。另外就是日志系统虽然Java的日志框架能直接输出到控制台和文件但生产环境真正排查问题时file日志的级别、按天分割、日志清理策略都要提前设计。如果不做清理tomcat日志和项目日志能把磁盘塞满这个坑在运维阶段非常常见。7. 源码阅读与二次开发建议7.1 拿到源码先看什么拿到一套陌生源码最忌讳从Controller开始逐行读。我的建议是先看数据库的初始化脚本从表结构反推业务模型。理解了表之间的关系再去读实体类对应的Mapper接口看SQL怎么写。下一步看Controller层的路由和参数接收方式最后再看Service层。因为Service层往往是最厚的最后读它反而能借助前面对SQL和路由的了解理解得更快。源码里的通用模块优先读比如统一返回结果类ResultT、全局异常处理器、PageResult分页结构、BaseController。这些是整套代码的骨架和约定。如果团队有自己的规范化约定后面开发新功能时不按这个约定来代码风格就会分裂。7.2 想往上加功能的时候怎么改假设需求是增加“项目周报”功能。数据层面可以复用现有表结构再加一张project_report表关联项目ID、上报周期、内容、创建人。后端增加ReportController和对应的Mapper前端在项目详情页加一个报告Tab标签复用现有表单和列表组件。这类功能的开发难度并不在于新增一张表和一个页面而在于权限边界是否想清楚谁有权限查看报告、谁有权限提交报告、项目结束后报告是否锁定。没想清楚这几点功能上线就会持续产生需求迭代。如果你想在这个系统里加“甘特图”或者“看板”强烈建议先查一下有没有现成的Vue3组件库不要重复造轮子。自己画甘特图的成本远比预想的高从拖拽交互到时间缩放每一块都是工作量。后台系统的开发效率很大程度取决于组件选型非核心组件能站别人的肩膀就不要自己从零写。7.3 学习这套源码的高效路径对于正在准备Java后端面试的人这套源码的价值尤其高。用它可以梳理清晰的回答链路SpringBoot如何启动、MyBatis如何映射、PageHelper如何分页、拦截器如何做登录校验、全局异常如何统一处理。这些几乎是后端岗位面试题里最常出现的一批问题。更进阶一点可以研究JWT的续期方案、用户权限的动态刷新、局部刷新Token等扩展点。Vue3方面它覆盖了组合式API、Pinia、Vue Router、Axios拦截器、动态菜单过滤这些后台管理系统高频场景对Vue3学习者和准备Vue3面试的人都是不错的案例库。比如面试里问“前端如何根据后端返回的角色权限渲染菜单”这个源码里的实现思路就可以直接用来回答。多说一句学习源码和做自己的项目完全是两件事。源码是用来“解剖”的一个函数一个函数地拆理解设计意图做项目是用来“打磨”的尽量用自己理解且可控的方案而不是抄一堆看不懂的魔法代码。确保代码的每一行都是自己掌握的后期交付才不会有隐患。8. 实操心得与避坑清单8.1 开发前后端分离系统的总体心态前后端分离项目开发时间久了最大的感受是接口约定必须先行。如果前后端各自按自己的想法定义字段名和返回结构联调阶段一定会互相等待、反复沟通非常浪费时间。我的习惯是先定义一份简单的接口文档哪怕是Markdown格式的表格包含接口路径、请求参数、返回结果示例、权限要求前后端照着它开发再配合Swagger做在线调试联调体验会好非常多。接口数据结构尽量保持扁平减少不必要的嵌套。前端拿到一个嵌套三层的数据结构展示和表单回填都会很痛苦。返回给前端的DTO字段名不要使用数据库下划线风格统一转成驼峰命名。框架层面的全局时间格式化、全局异常处理、统一返回格式这些约定哪怕辛苦一点也要在一开始定下来。后期的每个新功能都是复用这套约定省下来的时间会非常可观。8.2 盘点一下我遇到过的坑第一次做这类系统时我踩过最耗时的坑是权限模块。最初的实现只是在前端判断角色显示菜单后端接口完全没做校验结果团队成员直接绕过前端调接口把不属于自己的项目任务改掉了。后来花了很长时间给每个Controller方法补权限注解和拦截校验。所以后端接口的权限验证绝对不能省前端隐藏菜单只是用户体验层面的事情安全防线必须建立在后端。另外一个坑是删除功能的物理删除。项目管理系统的任务记录、工时记录都属于审计敏感数据物理删除之后无法追溯。正确做法是给表加一个deleted字段查询时统一过滤删除变成软删除。用户看到的是“删除成功”但数据还在库里这为后续的审计恢复留了后路。企业管理系统和普通个人应用不同数据完整性永远是第一优先级的。数据库字段类型也曾让我吃过教训。存储工时时用double累计统计后可能出现浮点误差存储金额或精确数值时用decimal统一指定精度。同理状态字段用枚举值还是字符串在代码里要保持一致别人改代码时看到1和2不知道什么意思可维护性就会变差。合理的做法是状态类字段在后端用枚举常量持久化时才转成数据库对应的数值。8.3 最后给几个扩展方向如果这套系统之后要往真实生产级演进第一步应该是引入Redis。用Redis存用户的Token能够实现主动下线弥补JWT无法主动失效的缺陷缓存热点字典数据减少数据库查询压力。引入Redis的复杂度不高但带来的架构收益非常明显。第二步是引入定时任务比如每天定时扫描即将到期的任务生成站内提醒消息。SpringBoot自带的Scheduled注解就能实现不需要额外引入XXL-Job除非你后续有分布式任务调度的需求。定时任务在业务系统里的价值往往被低估一个简单的到期提醒就能显著提升管理效果。第三步才是考虑微服务化。微服务引入的是服务发现、配置中心、链路追踪、分布式事务等一系列复杂问题如果业务体量没有达到几千个并发或者多个独立团队协作单体应用配合良好模块划分仍然是最佳选择。把单体项目的模块边界画清晰后续拆分成微服务也会顺畅。个人经验是这类项目管理系统最值钱的资产不是代码本身而是流程梳理和数据建模。前端页面、后端接口都是可以快速替换的但表结构一旦定了后续所有功能都会跟着长出来。想清楚业务规则代码只是把这些规则翻译成系统语言的过程而已。
