这套前后端分离企业项目管理系统我从拿到源码到部署上云服务器前前后后折腾了一周。技术栈就是标题里写的那些——SpringBoot做后端服务、Vue做前端界面、MyBatis负责数据访问、MySQL存业务数据。单看每个技术都不新鲜但它把企业里项目怎么管、任务怎么派、进度怎么查这些场景串得特别完整比网上那些只有登录注册的demo项目强太多。不管你是正在学前后端分离实战链路还是公司内部急需一套轻量级项目管理工具这套代码都很有参考价值。下面我把整个系统的业务设计、表结构、前后端关键实现以及部署流程完整拆开讲全是实际操作中验证过的经验。1. 为什么前后端分离成了企业项目的默认姿势1.1 单体时代的痛点早年间做企业管理系统最典型的做法是JSPServlet或者SpringMVC直接返回视图。这种模式下前端页面和后端逻辑挤在同一个工程里每次改一个按钮样式都要重启整个服务前端同学和后端同学在同一个代码仓库里互相踩脚谁动谁难受。项目周期一长代码里混着HTML、JS、Java新人接手想死的心都有。这套项目管理系统之所以选择前后端分离核心目的不是炫技而是把接口和界面彻底分开。后端只负责提供JSON数据前端只管渲染页面两者通过HTTP接口通信。开发阶段可以并行后端写接口的同时前端用mock数据就能把页面做出来部署阶段也可以独立伸缩哪个压力大就多开几个实例互不拖累。1.2 技术栈选型背后的逻辑为什么偏偏是SpringBootVueMyBatisMySQL这套组合我个人的判断是它足够中庸也就足够稳妥。SpringBoot不用多说内嵌Tomcat、自动配置、起步依赖简化到极致一个main方法就能把服务拉起来。Vue的三件套vue-router、vuex/pinia、axios属于前端基础课会的人多招人好招出了问题网上一搜一大把解决方案。MyBatis则是Java后端最普及的持久层框架SQL自己掌控动态SQL灵活面试题都围绕它——团队里没人不会。MySQL就更不用说了开源、免费、稳定中小企业的绝对主流。这套组合的另一个隐形成本是生态成熟度。文档多、插件多、坑都被前人踩平了。你要真去选个冷门框架光解决环境问题就能耗掉三天得不偿失。1.3 这套系统到底能做什么从功能模块上看它覆盖了企业项目管理的基本闭环项目管理创建项目、维护项目信息、设置项目起止时间、项目状态流转任务管理拆解任务、指派负责人、跟踪任务进度、设置优先级和截止日期成员管理维护用户信息、分配项目成员、项目负责人权限控制数据看板项目列表统计、任务完成率、个人工作量视图系统管理登录认证、用户权限、操作日志这套体系不算大但五脏俱全。它特别适合作为学习样本因为在它身上你能看到一套真实业务系统从0到1的完整链路而不是单个技术点的孤立演示。2. 数据库先行——项目管理系统表结构设计的实战推演2.1 先画表还是先写代码我强烈建议先建模拿到这类项目源码后值得注意它的表结构设计是有明确业务逻辑的。别上来就打开IDE写代码先把SQL脚本导入MySQL用数据库客户端Navicat或DBeaver把表关系理清楚你会发现后面读代码时思路顺畅很多。项目管理系统的核心实体就四个维度人、项目、任务、评论。再加上权限相关的关联表和数据字典大概六到八张表就能支撑起整个业务。表少不丢人清晰才是关键很多大厂系统前期也是这么起步的。2.2 核心表结构设计我在实际使用中整理过这套系统的核心表大致如下表名用途关键字段说明sys_user用户表id、username、password、real_name、avatar、statusproject项目表id、name、description、start_date、end_date、status、owner_idtask任务表id、project_id、title、assignee_id、priority、status、deadlineproject_member项目成员关联表id、project_id、user_id、roletask_comment任务评论表id、task_id、user_id、content、create_time拿task表举例its关键设计点是project_id和assignee_id都建了普通索引。这不是随便建的因为列表页最常见的操作就是查某个项目的所有任务和查某个用户被分配的任务这两个字段是查询条件的常客。索引设计的原则很简单——如果where后面经常用到某个字段就给这个字段建索引如果表记录超过几万行索引的价值尤其明显。2.3 状态字段和时间字段的坑项目中所有状态字段项目状态、任务状态都用的是varchar或int存储枚举值这很正常。但我在自己项目里踩过一个坑状态值直接用中文存进去比如已完成代码里写死字符串后来需求变了要把已完成改成已归档连带改表和代码麻烦得要命。这套系统用status数字编码来做状态流转0未开始、1进行中、2已完成、3已取消枚举值在前后端各维护一份。看起来麻烦但后续迭代时加状态只需加数字不用动老数据。时间字段也需要注意。create_time、update_time这类字段强烈建议设置数据库默认值DEFAULT CURRENT_TIMESTAMPinsert的时候不用手动塞值省心还不容易漏。另外deadline这种业务时间字段前端传参时格式统一用yyyy-MM-dd HH:mm:ss前后端约定好一个格式能避开一大堆解析问题。2.4 初始化数据准备跑通项目之前先执行项目里自带的init.sql或admin.sql。里面除了建表语句通常还带了一条初始管理员账号admin/admin123这类。导入后先登录一遍看菜单和页面是否正常渲染再开始改业务排查问题时范围会小很多。我第一次用的时候跳过初始化直接改配置结果页面白屏了半小时后来才发现是缺了数据字典表里那几个基础记录——这种低级错误希望你们别重蹈覆辙。3. SpringBoot后端落地——接口规范、JWT认证与MyBatis动态SQL3.1 后端工程目录怎么组织最舒服这套系统的后端分层很标准controller接收请求、service写业务逻辑、mapper做数据访问、entity对应数据库表。我的建议是拿to这个项目做参考时先不用纠结包结构够不够高级先理解这种经典分层的调用链Controller - Service - Mapper。等你真正接手新项目再按自己的习惯调整也不迟。GitHub上很多教程习惯在service层扔一堆接口和impl两套文件来回跳。这个项目比较务实直接用类实现代码量少一半小团队维护起来反而更顺手。有时候设计模式用多了真的会把人绕晕。3.2 application.yml配置的三个关键点后端启动之前配好application.yml就行但有三个地方特别容易出错第一个是数据源连接串MySQL 8以上版本一定要带useSSLfalse和serverTimezoneAsia/Shanghai。不然启动时大概率报SSL连接错误或者时区异常。我之前第一次连MySQL 8就被The server time zone value Öйú±ê׼ʱ¼ä这个乱码报错坑过加上serverTimezone之后瞬间清爽。第二个是MyBatis配置。开启驼峰映射很关键因为数据库字段是下划线风格create_time而Java实体类是驼峰风格createTime不开启的话查出来的对象属性全是null而且这种问题不报错、难排查。配置起来就一行mybatis: configuration: map-underscore-to-camel-case: true mapper-locations: classpath:mapper/*.xml第三个是端口选择。默认8080经常被其他程序占我习惯改成8010之类的独立端口。改了端口之后记得前端代理也要跟着改不然联调时接口全部失败。3.3 统一返回体和全局异常接口规范从第一天抓起前后端分离项目最重要的约定之一就是接口返回格式必须统一。这套系统里定义了Result类所有接口统一返回{code: 200, message: success, data: ...}这种结构。前端axios拦截器只看code判断业务成功还是失败不用关心具体接口返回什么字段。这种约定一开始就要定住否则接口多了再统一改动成本翻倍。全局异常处理也很有用。RestControllerAdvice把异常统一拦截下来业务异常返回业务错误码未知异常返回500并打出完整堆栈。没有这层处理的话后端一报错就直接把默认错误页返回给前端前端拿到的根本不是JSON拦截器里处理逻辑全都白搭。3.4 JWT认证用拦截器就够了不用上Spring Security我见过很多新手一上来就引入Spring Security全家桶配置类写了一百多行还是懵的。这套系统用的是拦截器JWT的轻量方案对绝大多数内部管理系统来说完全够用。登录接口验证用户名密码后用jjwt生成一个token返回给前端。前端把它存在本地每次请求header里带上Authorization: Bearer token。后端写一个拦截器过滤需要认证的路径比如/api/**排除/api/login校验token合法性并把用户信息塞到request attribute里供后续接口使用。核心无非三件事生成token、校验token、解析用户身份。不用引入一堆安全框架的依赖也不用管什么SecurityConfig的过滤器链理解成本直线下降。等哪天真需要细粒度的角色权限控制再换Spring Security也不迟系统架构留好扩展点就行。3.5 MyBatis动态SQL是最值钱的地方这套系统里任务列表是多条件查询的典型场景按项目筛选、按状态筛选、按负责人筛选、按关键字模糊搜索。如果用Java循环拼接SQL代码丑还容易被SQL注入。MyBatis的where加if标签完美解决这个需求。select idselectTaskList resultTypecom.example.entity.Task SELECT * FROM task where if testprojectId ! null AND project_id #{projectId} /if if teststatus ! null AND status #{status} /if if testassigneeId ! null AND assignee_id #{assigneeId} /if if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY create_time DESC /select这段SQL的价值在于条件可以任意组合用户勾选几个筛选条件就拼接几个不用为每种组合写单独的SQL。Mapper接口里只需要写一个方法带一个包含所有可选字段的条件对象或Param参数前端传什么就查什么省了N个重载方法。分页查询在这个项目里是通过PageHelper实现的。加依赖后Mapper查询前设置PageHelper.startPage(pageNum, pageSize)再执行查询方法返回的结果自动带total和分页数据不需要手动写LIMIT语句。注意PageHelper有个坑startPage之后必须紧跟第一条查询语句中间不能插入其他查询不然分页会作用在错误的SQL上。我在一个统计接口里犯过这个错误查出来的总数永远不对排查了半天才发现中间多了一次count查询。3.6 批量插入和事务那些事项目里初始化任务数据时如果需要批量导入MyBatis的批量插入可以这么写insert idbatchInsert INSERT INTO task(project_id, title, assignee_id, status, priority, create_time) VALUES foreach collectionlist itemitem separator, (#{item.projectId}, #{item.title}, #{item.assigneeId}, #{item.status}, #{item.priority}, NOW()) /foreach /insert注意批量插入一次性不要超过1000条我试过一次性塞5000条MySQL直接报max_allowed_packet超限。拆成每500条一批插入实测稳定很多。事务方面在service方法上加Transactional只有运行时异常才回滚受检异常默认不回滚如果业务上需要回滚就要在注解里指定rollbackFor Exception.class。这是Spring事务管理的经典考点实际开发中也确实容易忽略不加rollbackFor的话很多异常场景下数据不会自动回滚线上容易出脏数据。4. Vue前端工程化——组件拆分、请求封装与动态路由4.1 前端目录结构的设计思路这套系统的前端基于Vue 3也可能是Vue 2根据版本定目录结构大同小异。我的习惯是这么划分api/按业务模块存放接口请求函数views/页面级组件一目录一个路由页面components/公共组件比如任务卡片、人员选择器、分页组件router/路由配置store/全局状态管理utils/工具函数和axios封装layout/整体布局组件包含侧边栏和顶栏对新手来说理清楚views和components的边界是最关键的。views放页面一个页面一个文件负责数据加载和页面编排components放可以被多个页面复用的块比如任务列表组件可能在项目详情页和个人工作台里都出现抽成组件就不用在两个页面写两遍逻辑了。4.2 axios封装和拦截器的妙用前端最核心的封装就是axios。不封装的话每个页面都要写一遍完整的请求逻辑代码里全是重复的loading处理和错误提示。这套系统的axios封装做了三件事第一请求拦截器统一注入token。所有请求自动带上Authorization头不用每个接口手写。service.interceptors.request.use( config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )第二响应拦截器统一处理业务码。拿到的响应如果code ! 200直接弹出错误提示页面代码只需要关心数据本身不用每个接口都做错误判断。service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) if (res.code 401) { // token失效跳转登录页 router.push(/login) } return Promise.reject(new Error(res.message)) } return res }, error { ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )第三统一封装get和post方法返回promise。4.3 路由守卫未登录直接拦截前端不能只靠后端接口拦截因为用户没登录也能看到页面框架和菜单虽然拿不到数据但体验极差。这套系统的vue-router配置了全局前置守卫每次跳路由之前检查本地有没有tokenrouter.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })如果只在后端做验证你进系统后先看到一堆空页面再跳回登录页视觉效果很不专业。前端先拦截后端再校验双重保障。动态路由是这个项目里的一个亮点。不同角色登录后看到的菜单不一样。实现思路是登录后从后端拉取当前用户的权限列表和菜单数据用addRoute方法动态注册路由。这套系统里用的是简单版——根据用户角色直接展示或隐藏菜单项。更复杂的版本会把路由表放在后端前端只注册基础路由权限路由靠后端返回再动态加载。两种思路都行看项目复杂程度。4.4 组件拆分的颗粒度我在实际开发里总结的组件原则很简单一个组件只干一件事。比如任务卡片组件只负责展示任务的基础信息和状态标签不管数据从哪来。项目列表页和数据看板页都引用了这个组件传入task对象就渲染出卡片内部逻辑互不干扰。组件通信方面这套系统大量用props传参和emit抛事件。父子组件的通信模式是够用的别动不动就引入状态管理库。只有像当前登录用户信息这种全局数据才放进store其他页面间的交互通信通过事件总线或路由参数传递就够了。4.5 开发联调代理和构建配置前后端分离开发阶段最头疼的是跨域。浏览器直接请求后端接口肯定跨域解决办法是前端开发服务器开代理。Vite配置vite.config.jsWebpack就是vue.config.js配置大同小异server: { proxy: { /api: { target: http://localhost:8010, changeOrigin: true } } }这个配置的意义是前端请求/api/project/list时开发服务器把请求转发到后端的http://localhost:8010/api/project/list代理转发发生在服务端不存在跨域问题。生产环境则不同。前端构建后是纯静态文件部署时用Nginx把/api开头的请求反向代理到后端服务前端页面本身由Nginx直接serve。这就是前后端分离部署的核心逻辑——开发和生产的跨域处理方式完全不同网上很多人说部署好了还是跨域基本都是Nginx反代配置没写好。环境变量也要区分。.env.development里写VITE_API_BASE_URL/api.env.production里写VITE_API_BASE_URL/prod-api之类构建时自动替换baseURL不需要改代码。5. MySQL环境与数据准备——字符集、连接参数和初始化脚本5.1 建库语句里藏着大学问这个项目的初始化脚本里建库语句用的是utf8mb4字符集。为什么不用utf8因为MySQL的utf8是utf8mb3的别名只能存基本多文种平面BMP的字符像emoji这种四字节字符存不进去。utf8mb4才是真正的完整UTF-8。企业系统迟早会遇到用户昵称带emoji的情况直接用utf8mb4就是从源头避坑。CREATE DATABASE IF NOT EXISTS pm_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;排序规则用utf8mb4_general_ci还是utf8mb4_unicode_ci都可以。对于中文内容来说两个排序规则都能正确排序general_ci性能略好unicode_ci在排序准确性上更优。中小项目差别微乎其微选一种坚持用就行。5.2 JDBC连接串的细节不能少MySQL 8的驱动连接串我推荐配置是这样spring: datasource: url: jdbc:mysql://localhost:3306/pm_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver拆开解释useUnicodetruecharacterEncodingutf8保证中文不乱码useSSLfalse跳过SSL握手本地开发没必要加密传输serverTimezoneAsia/Shanghai解决时区报错allowPublicKeyRetrievaltrue是MySQL 8的密码认证方式导致的不加的话jdbc连不上会报Public Key Retrieval is not allowed。还有一个建议给项目单独建一个数据库账号别直接用root。CREATE USER pm_user% IDENTIFIED BY 密码;然后GRANT ALL PRIVILEGES ON pm_system.* TO pm_user%;。这样线上出问题的时候回收权限最小化root密码泄露的风险也低一些。5.3 初始化数据里的门道导入初始化脚本时如果脚本里带DEFAULT CURRENT_TIMESTAMP导入后表里的时间字段会自动取当前时间。这个细节能保证你在测试时数据看起来是活的而不是N年前的老数据。我习惯导入后先执行几条验证性SQL确认表结构和数据都对SELECT COUNT(*) FROM sys_user; SELECT COUNT(*) FROM project; SELECT id, username FROM sys_user;如果admin账号查不到先别急登录八成是导入的库选错了或者脚本执行中断。这个问题最常见的错误是打开Navicat时没有先切换到目标数据库就直接运行脚本数据全部建到了默认库下。5.4 常见的MySQL连接报错排查我整理过几类高频坑这里给出排查方向SSL连接错误报错信息带SSL、Public Key检查连接串是否加了useSSLfalseallowPublicKeyRetrievaltrue时区乱码报错信息带serverTimezone或者Öйú±ê׼ʱ¼ä加serverTimezoneAsia/ShanghaiUnknown database数据库没建或者连接串里的库名和实际库名不一致Access denied for user用户名密码不对或该用户没有目标库的访问权限max_allowed_packet超限批量插入或导入大SQL时报错调整MySQL配置里的max_allowed_packet或者拆分批处理这些坑几乎是每个前后端分离项目部署都会遇到的提前知道能省不少时间。6. 部署到服务器——jar包、Nginx、Tomcat三种方式的完整流程6.1 后端打包启动的一套组合拳后端部署前先确认生产环境配置。把application.yml里的数据库地址换成生产库端口保持默认或者在启动参数里覆盖。打包命令很简单mvn clean package -DskipTests执行完在target目录下生成一个xxx.jar文件。上传到服务器后最朴素的方式就是java -jar pm-system.jar但直接终端运行有个问题一旦断开SSH连接进程就挂了。所以我建议用systemd守护进程。在/etc/systemd/system/pm-system.service中写入[Unit] DescriptionPM System Service Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/usr/local/pm-system ExecStart/usr/local/jdk/bin/java -Xms512m -Xmx1024m -jar pm-system.jar Restarton-failure RestartSec10 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable pm-system systemctl start pm-system systemctl status pm-system之后查日志用journalctl -u pm-system -f。这套操作下来后端服务就自动重启、开机自启动了比nohup要稳得多。我实际使用中nohup方式进程莫名消失过几次换systemd之后再没出现过。6.2 前端构建和Nginx配置前端构建命令npm install npm run build执行完的dist目录就是全部静态资源上传到服务器任意目录比如/usr/share/nginx/html/pm。Nginx配置是核心先把静态文件服务配好server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/pm; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8010/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里最容易被忽视的是location /里的try_files。它解决的是vue-router使用history模式时刷新页面404的问题。用户访问/project/1时服务器上不存在这个文件路径try_files会把请求回退到index.html由前端路由接管页面就能正确渲染。没有这一行刷新子路由页面就会404——这是前端部署里最经典的一个坑。location /api/的proxy_pass后面带不带/效果不同。带/表示把/api前缀去掉再转发也就是请求/api/project/list会转发到http://127.0.0.1:8010/project/list不带/则保持完整路径。具体用哪种取决于后端接口路径带不带/api前缀。如果后端Controller里RequestMapping(/api)就去掉/如果后端就是RequestMapping(/project)就得带/去掉前缀。这是个看起来不起眼、踩上去头破血流的配置项。6.3 Tomcat部署的适用场景这个项目的部署教程里也提了Tomcat它更适合那些必须用war包部署的传统场景。如果你公司统一要求应用必须丢进Tomcat的webapps目录里管理那打包方式改成warpackagingwar/packaging并让启动类继承SpringBootServletInitializer重写configure方法。剩下的流程就是把war丢进webapps启动Tomcat即可。但我的观念是Java项目能用jar就用jar。jar独立、内嵌Tomcat、启动就一个命令不存在同一个Tomcat里多个应用版本冲突的问题。war部署适合老运维团队习惯统一管理的情况新项目没必要逆潮流。6.4 云服务器环境快速配置如果是全新的云服务器我的建议顺序是安装JDK 8或11java -version验证安装MySQL 8设置root密码新建业务库和账号安装Nginx配置静态资源目录和反向代理上传后端jar包和前端dist目录关闭防火墙或放行端口云服务器尤其注意安全组按顺序启动MySQL、后端服务、Nginx第5步经常被忽略。云服务器的安全组规则只放行80的话后端的8010端口在外网是不可访问的但没关系因为我们通过Nginx反代外部请求只走80端口后端服务只要内网能访问就行。如果你希望后端端口直接暴露就得在安全组里放行8010不过不推荐容易被扫到攻击。7. 从开发到上线几个绕不开的实战大坑7.1 刷新页面404这个前面已经提到过因为vue-router默认是history模式URL很干净没有#号但服务器不知道/project/1该返回哪个文件。处理方案就是Nginx的try_files回退index.html。如果用的不是Nginx而是Tomcat也有类似问题不过Tomcat里没有try_files的简写配置一般要加Tuckey的UrlRewriteFilter相对麻烦。这也是我推荐Nginx部署前后端分离项目的原因——处理这种问题天然顺手。7.2 跨域问题要分开发和生产两套思维开发环境的跨域靠Vite/Webpack代理生产环境靠Nginx反代。如果生产环境还出现跨域八成是请求路径没走Nginx的代理规则或者后端CORS配置和生产环境Nginx代理的顺序冲突了。后端如果之前为了开发环境方便配了CorsFilter允许所有来源生产环境建议把Nginx的反代配好之后再决定是否收紧CORS策略。我曾见过一个系统生产环境用了CORS全放开被安全测试评为高危漏洞整改的时候得同时改后端配置和Nginx规则来回折腾很久。7.3 MyBatis的N1查询和缓存选择在任务列表中分页查出20条任务如果每条任务都要再查一次项目名称和负责人姓名数据库会多执行40条SQL。这叫N1问题。解决办法是用JOIN一次查出任务关联的项目名和负责人名或者用MyBatis的association和collection做嵌套结果映射。实际上一个列表页SQL写复杂点、只查一次比在Java层循环查询性能提升明显。MyBatis的一级缓存是默认开启的作用范围是同一个SqlSession。但Spring管理的Mapper每次执行都是独立的SqlSession一级缓存几乎不起作用。二级缓存默认关闭如果想要开启需要实体类实现Serializable并在Mapper XML里加cache/。不过我在实际项目中不敢随便开二级缓存因为一旦涉及关联表更新缓存刷新就有滞后风险容易出现脏数据。查询慢的根源尽量靠优化SQL和索引解决而不是靠缓存这个思路更稳妥。7.4 连接池配置别用默认值SpringBoot默认的HikariCP连接池很优秀但默认配置不一定适合你的业务量。我有一次压测时发现接口偶尔报connection is not available原因是Hikari的maximum-pool-size默认是10并发一超过10新请求就得排队等连接。后来调整配置后明显缓解spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000maximum-pool-size不是越大越好开100个连接数据库也未必扛得住。一般20到30够用具体看数据库服务器的性能指标。另外连接超时时间别设太短我设过10秒数据库偶尔flush一下慢查询前端就报连接超时了。30秒是经验值。7.5 文件上传遇到的坑很多项目管理demo不包含文件上传如果你要扩展MinIO是一个很好的选择。这个组合也是搜索里常出现的minio加入到springboot。流程是先装MinIO服务器然后SpringBoot集成MinIO Java SDK提供上传接口前端拿到上传URL后做文件展示。开发环境可以先用本地磁盘存储把功能跑通生产再切换到MinIO或者云OSS。自己用和小规模内网MinIO一把梭长期对外提供服务还是云OSS省心不需要运维对象存储服务器。7.6 日志和监控部署后千万别裸奔最后提一嘴线上环境不配日志会非常痛苦。SpringBoot默认只把日志打到控制台用systemd部署后日志被journald统一收集确实能journalctl看但日志一多就难查。我习惯用logback配置按天滚动appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file/usr/local/pm-system/logs/pm-system.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternpm-system.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n/pattern /encoder /appender配好之后查问题时直接tail -f /usr/local/pm-system/logs/pm-system.log或者用grep按时间过滤定位效率比在journal里翻高得多。我个人的体会是这类型的前后端分离项目管理系统技术上的难点不在于某个框架用得多深而在于把业务场景和工程实践完整串起来。整个过程里最容易耗时间的不是写代码而是环境配置、路径匹配、跨域处理这些细节。跑通一次之后这套体系基本就是通用技能以后再做类似的团队协作类系统都能直接复用这套思路。最后再分享一个小技巧。拿到任何前后端分离项目源码后建议先花半小时把数据库脚本和README彻底过一遍把表关系和接口文档理清楚再动手启动项目。这半小时的回报率极高。我也踩过那种图快直接启动结果缺依赖、缺配置、白屏、接口404连环炸的坑后来每次复盘都发现问题根源在前期没读懂文档。先看文档再动代码遇到问题能少走一半弯路。
前后端分离项目管理系统实战：SpringBoot+Vue+MyBatis+MySQL部署全攻略
这套前后端分离企业项目管理系统我从拿到源码到部署上云服务器前前后后折腾了一周。技术栈就是标题里写的那些——SpringBoot做后端服务、Vue做前端界面、MyBatis负责数据访问、MySQL存业务数据。单看每个技术都不新鲜但它把企业里项目怎么管、任务怎么派、进度怎么查这些场景串得特别完整比网上那些只有登录注册的demo项目强太多。不管你是正在学前后端分离实战链路还是公司内部急需一套轻量级项目管理工具这套代码都很有参考价值。下面我把整个系统的业务设计、表结构、前后端关键实现以及部署流程完整拆开讲全是实际操作中验证过的经验。1. 为什么前后端分离成了企业项目的默认姿势1.1 单体时代的痛点早年间做企业管理系统最典型的做法是JSPServlet或者SpringMVC直接返回视图。这种模式下前端页面和后端逻辑挤在同一个工程里每次改一个按钮样式都要重启整个服务前端同学和后端同学在同一个代码仓库里互相踩脚谁动谁难受。项目周期一长代码里混着HTML、JS、Java新人接手想死的心都有。这套项目管理系统之所以选择前后端分离核心目的不是炫技而是把接口和界面彻底分开。后端只负责提供JSON数据前端只管渲染页面两者通过HTTP接口通信。开发阶段可以并行后端写接口的同时前端用mock数据就能把页面做出来部署阶段也可以独立伸缩哪个压力大就多开几个实例互不拖累。1.2 技术栈选型背后的逻辑为什么偏偏是SpringBootVueMyBatisMySQL这套组合我个人的判断是它足够中庸也就足够稳妥。SpringBoot不用多说内嵌Tomcat、自动配置、起步依赖简化到极致一个main方法就能把服务拉起来。Vue的三件套vue-router、vuex/pinia、axios属于前端基础课会的人多招人好招出了问题网上一搜一大把解决方案。MyBatis则是Java后端最普及的持久层框架SQL自己掌控动态SQL灵活面试题都围绕它——团队里没人不会。MySQL就更不用说了开源、免费、稳定中小企业的绝对主流。这套组合的另一个隐形成本是生态成熟度。文档多、插件多、坑都被前人踩平了。你要真去选个冷门框架光解决环境问题就能耗掉三天得不偿失。1.3 这套系统到底能做什么从功能模块上看它覆盖了企业项目管理的基本闭环项目管理创建项目、维护项目信息、设置项目起止时间、项目状态流转任务管理拆解任务、指派负责人、跟踪任务进度、设置优先级和截止日期成员管理维护用户信息、分配项目成员、项目负责人权限控制数据看板项目列表统计、任务完成率、个人工作量视图系统管理登录认证、用户权限、操作日志这套体系不算大但五脏俱全。它特别适合作为学习样本因为在它身上你能看到一套真实业务系统从0到1的完整链路而不是单个技术点的孤立演示。2. 数据库先行——项目管理系统表结构设计的实战推演2.1 先画表还是先写代码我强烈建议先建模拿到这类项目源码后值得注意它的表结构设计是有明确业务逻辑的。别上来就打开IDE写代码先把SQL脚本导入MySQL用数据库客户端Navicat或DBeaver把表关系理清楚你会发现后面读代码时思路顺畅很多。项目管理系统的核心实体就四个维度人、项目、任务、评论。再加上权限相关的关联表和数据字典大概六到八张表就能支撑起整个业务。表少不丢人清晰才是关键很多大厂系统前期也是这么起步的。2.2 核心表结构设计我在实际使用中整理过这套系统的核心表大致如下表名用途关键字段说明sys_user用户表id、username、password、real_name、avatar、statusproject项目表id、name、description、start_date、end_date、status、owner_idtask任务表id、project_id、title、assignee_id、priority、status、deadlineproject_member项目成员关联表id、project_id、user_id、roletask_comment任务评论表id、task_id、user_id、content、create_time拿task表举例its关键设计点是project_id和assignee_id都建了普通索引。这不是随便建的因为列表页最常见的操作就是查某个项目的所有任务和查某个用户被分配的任务这两个字段是查询条件的常客。索引设计的原则很简单——如果where后面经常用到某个字段就给这个字段建索引如果表记录超过几万行索引的价值尤其明显。2.3 状态字段和时间字段的坑项目中所有状态字段项目状态、任务状态都用的是varchar或int存储枚举值这很正常。但我在自己项目里踩过一个坑状态值直接用中文存进去比如已完成代码里写死字符串后来需求变了要把已完成改成已归档连带改表和代码麻烦得要命。这套系统用status数字编码来做状态流转0未开始、1进行中、2已完成、3已取消枚举值在前后端各维护一份。看起来麻烦但后续迭代时加状态只需加数字不用动老数据。时间字段也需要注意。create_time、update_time这类字段强烈建议设置数据库默认值DEFAULT CURRENT_TIMESTAMPinsert的时候不用手动塞值省心还不容易漏。另外deadline这种业务时间字段前端传参时格式统一用yyyy-MM-dd HH:mm:ss前后端约定好一个格式能避开一大堆解析问题。2.4 初始化数据准备跑通项目之前先执行项目里自带的init.sql或admin.sql。里面除了建表语句通常还带了一条初始管理员账号admin/admin123这类。导入后先登录一遍看菜单和页面是否正常渲染再开始改业务排查问题时范围会小很多。我第一次用的时候跳过初始化直接改配置结果页面白屏了半小时后来才发现是缺了数据字典表里那几个基础记录——这种低级错误希望你们别重蹈覆辙。3. SpringBoot后端落地——接口规范、JWT认证与MyBatis动态SQL3.1 后端工程目录怎么组织最舒服这套系统的后端分层很标准controller接收请求、service写业务逻辑、mapper做数据访问、entity对应数据库表。我的建议是拿to这个项目做参考时先不用纠结包结构够不够高级先理解这种经典分层的调用链Controller - Service - Mapper。等你真正接手新项目再按自己的习惯调整也不迟。GitHub上很多教程习惯在service层扔一堆接口和impl两套文件来回跳。这个项目比较务实直接用类实现代码量少一半小团队维护起来反而更顺手。有时候设计模式用多了真的会把人绕晕。3.2 application.yml配置的三个关键点后端启动之前配好application.yml就行但有三个地方特别容易出错第一个是数据源连接串MySQL 8以上版本一定要带useSSLfalse和serverTimezoneAsia/Shanghai。不然启动时大概率报SSL连接错误或者时区异常。我之前第一次连MySQL 8就被The server time zone value Öйú±ê׼ʱ¼ä这个乱码报错坑过加上serverTimezone之后瞬间清爽。第二个是MyBatis配置。开启驼峰映射很关键因为数据库字段是下划线风格create_time而Java实体类是驼峰风格createTime不开启的话查出来的对象属性全是null而且这种问题不报错、难排查。配置起来就一行mybatis: configuration: map-underscore-to-camel-case: true mapper-locations: classpath:mapper/*.xml第三个是端口选择。默认8080经常被其他程序占我习惯改成8010之类的独立端口。改了端口之后记得前端代理也要跟着改不然联调时接口全部失败。3.3 统一返回体和全局异常接口规范从第一天抓起前后端分离项目最重要的约定之一就是接口返回格式必须统一。这套系统里定义了Result类所有接口统一返回{code: 200, message: success, data: ...}这种结构。前端axios拦截器只看code判断业务成功还是失败不用关心具体接口返回什么字段。这种约定一开始就要定住否则接口多了再统一改动成本翻倍。全局异常处理也很有用。RestControllerAdvice把异常统一拦截下来业务异常返回业务错误码未知异常返回500并打出完整堆栈。没有这层处理的话后端一报错就直接把默认错误页返回给前端前端拿到的根本不是JSON拦截器里处理逻辑全都白搭。3.4 JWT认证用拦截器就够了不用上Spring Security我见过很多新手一上来就引入Spring Security全家桶配置类写了一百多行还是懵的。这套系统用的是拦截器JWT的轻量方案对绝大多数内部管理系统来说完全够用。登录接口验证用户名密码后用jjwt生成一个token返回给前端。前端把它存在本地每次请求header里带上Authorization: Bearer token。后端写一个拦截器过滤需要认证的路径比如/api/**排除/api/login校验token合法性并把用户信息塞到request attribute里供后续接口使用。核心无非三件事生成token、校验token、解析用户身份。不用引入一堆安全框架的依赖也不用管什么SecurityConfig的过滤器链理解成本直线下降。等哪天真需要细粒度的角色权限控制再换Spring Security也不迟系统架构留好扩展点就行。3.5 MyBatis动态SQL是最值钱的地方这套系统里任务列表是多条件查询的典型场景按项目筛选、按状态筛选、按负责人筛选、按关键字模糊搜索。如果用Java循环拼接SQL代码丑还容易被SQL注入。MyBatis的where加if标签完美解决这个需求。select idselectTaskList resultTypecom.example.entity.Task SELECT * FROM task where if testprojectId ! null AND project_id #{projectId} /if if teststatus ! null AND status #{status} /if if testassigneeId ! null AND assignee_id #{assigneeId} /if if testkeyword ! null and keyword ! AND title LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY create_time DESC /select这段SQL的价值在于条件可以任意组合用户勾选几个筛选条件就拼接几个不用为每种组合写单独的SQL。Mapper接口里只需要写一个方法带一个包含所有可选字段的条件对象或Param参数前端传什么就查什么省了N个重载方法。分页查询在这个项目里是通过PageHelper实现的。加依赖后Mapper查询前设置PageHelper.startPage(pageNum, pageSize)再执行查询方法返回的结果自动带total和分页数据不需要手动写LIMIT语句。注意PageHelper有个坑startPage之后必须紧跟第一条查询语句中间不能插入其他查询不然分页会作用在错误的SQL上。我在一个统计接口里犯过这个错误查出来的总数永远不对排查了半天才发现中间多了一次count查询。3.6 批量插入和事务那些事项目里初始化任务数据时如果需要批量导入MyBatis的批量插入可以这么写insert idbatchInsert INSERT INTO task(project_id, title, assignee_id, status, priority, create_time) VALUES foreach collectionlist itemitem separator, (#{item.projectId}, #{item.title}, #{item.assigneeId}, #{item.status}, #{item.priority}, NOW()) /foreach /insert注意批量插入一次性不要超过1000条我试过一次性塞5000条MySQL直接报max_allowed_packet超限。拆成每500条一批插入实测稳定很多。事务方面在service方法上加Transactional只有运行时异常才回滚受检异常默认不回滚如果业务上需要回滚就要在注解里指定rollbackFor Exception.class。这是Spring事务管理的经典考点实际开发中也确实容易忽略不加rollbackFor的话很多异常场景下数据不会自动回滚线上容易出脏数据。4. Vue前端工程化——组件拆分、请求封装与动态路由4.1 前端目录结构的设计思路这套系统的前端基于Vue 3也可能是Vue 2根据版本定目录结构大同小异。我的习惯是这么划分api/按业务模块存放接口请求函数views/页面级组件一目录一个路由页面components/公共组件比如任务卡片、人员选择器、分页组件router/路由配置store/全局状态管理utils/工具函数和axios封装layout/整体布局组件包含侧边栏和顶栏对新手来说理清楚views和components的边界是最关键的。views放页面一个页面一个文件负责数据加载和页面编排components放可以被多个页面复用的块比如任务列表组件可能在项目详情页和个人工作台里都出现抽成组件就不用在两个页面写两遍逻辑了。4.2 axios封装和拦截器的妙用前端最核心的封装就是axios。不封装的话每个页面都要写一遍完整的请求逻辑代码里全是重复的loading处理和错误提示。这套系统的axios封装做了三件事第一请求拦截器统一注入token。所有请求自动带上Authorization头不用每个接口手写。service.interceptors.request.use( config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )第二响应拦截器统一处理业务码。拿到的响应如果code ! 200直接弹出错误提示页面代码只需要关心数据本身不用每个接口都做错误判断。service.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) if (res.code 401) { // token失效跳转登录页 router.push(/login) } return Promise.reject(new Error(res.message)) } return res }, error { ElMessage.error(error.message || 网络异常) return Promise.reject(error) } )第三统一封装get和post方法返回promise。4.3 路由守卫未登录直接拦截前端不能只靠后端接口拦截因为用户没登录也能看到页面框架和菜单虽然拿不到数据但体验极差。这套系统的vue-router配置了全局前置守卫每次跳路由之前检查本地有没有tokenrouter.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else if (!token) { next(/login) } else { next() } })如果只在后端做验证你进系统后先看到一堆空页面再跳回登录页视觉效果很不专业。前端先拦截后端再校验双重保障。动态路由是这个项目里的一个亮点。不同角色登录后看到的菜单不一样。实现思路是登录后从后端拉取当前用户的权限列表和菜单数据用addRoute方法动态注册路由。这套系统里用的是简单版——根据用户角色直接展示或隐藏菜单项。更复杂的版本会把路由表放在后端前端只注册基础路由权限路由靠后端返回再动态加载。两种思路都行看项目复杂程度。4.4 组件拆分的颗粒度我在实际开发里总结的组件原则很简单一个组件只干一件事。比如任务卡片组件只负责展示任务的基础信息和状态标签不管数据从哪来。项目列表页和数据看板页都引用了这个组件传入task对象就渲染出卡片内部逻辑互不干扰。组件通信方面这套系统大量用props传参和emit抛事件。父子组件的通信模式是够用的别动不动就引入状态管理库。只有像当前登录用户信息这种全局数据才放进store其他页面间的交互通信通过事件总线或路由参数传递就够了。4.5 开发联调代理和构建配置前后端分离开发阶段最头疼的是跨域。浏览器直接请求后端接口肯定跨域解决办法是前端开发服务器开代理。Vite配置vite.config.jsWebpack就是vue.config.js配置大同小异server: { proxy: { /api: { target: http://localhost:8010, changeOrigin: true } } }这个配置的意义是前端请求/api/project/list时开发服务器把请求转发到后端的http://localhost:8010/api/project/list代理转发发生在服务端不存在跨域问题。生产环境则不同。前端构建后是纯静态文件部署时用Nginx把/api开头的请求反向代理到后端服务前端页面本身由Nginx直接serve。这就是前后端分离部署的核心逻辑——开发和生产的跨域处理方式完全不同网上很多人说部署好了还是跨域基本都是Nginx反代配置没写好。环境变量也要区分。.env.development里写VITE_API_BASE_URL/api.env.production里写VITE_API_BASE_URL/prod-api之类构建时自动替换baseURL不需要改代码。5. MySQL环境与数据准备——字符集、连接参数和初始化脚本5.1 建库语句里藏着大学问这个项目的初始化脚本里建库语句用的是utf8mb4字符集。为什么不用utf8因为MySQL的utf8是utf8mb3的别名只能存基本多文种平面BMP的字符像emoji这种四字节字符存不进去。utf8mb4才是真正的完整UTF-8。企业系统迟早会遇到用户昵称带emoji的情况直接用utf8mb4就是从源头避坑。CREATE DATABASE IF NOT EXISTS pm_system DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;排序规则用utf8mb4_general_ci还是utf8mb4_unicode_ci都可以。对于中文内容来说两个排序规则都能正确排序general_ci性能略好unicode_ci在排序准确性上更优。中小项目差别微乎其微选一种坚持用就行。5.2 JDBC连接串的细节不能少MySQL 8的驱动连接串我推荐配置是这样spring: datasource: url: jdbc:mysql://localhost:3306/pm_system?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver拆开解释useUnicodetruecharacterEncodingutf8保证中文不乱码useSSLfalse跳过SSL握手本地开发没必要加密传输serverTimezoneAsia/Shanghai解决时区报错allowPublicKeyRetrievaltrue是MySQL 8的密码认证方式导致的不加的话jdbc连不上会报Public Key Retrieval is not allowed。还有一个建议给项目单独建一个数据库账号别直接用root。CREATE USER pm_user% IDENTIFIED BY 密码;然后GRANT ALL PRIVILEGES ON pm_system.* TO pm_user%;。这样线上出问题的时候回收权限最小化root密码泄露的风险也低一些。5.3 初始化数据里的门道导入初始化脚本时如果脚本里带DEFAULT CURRENT_TIMESTAMP导入后表里的时间字段会自动取当前时间。这个细节能保证你在测试时数据看起来是活的而不是N年前的老数据。我习惯导入后先执行几条验证性SQL确认表结构和数据都对SELECT COUNT(*) FROM sys_user; SELECT COUNT(*) FROM project; SELECT id, username FROM sys_user;如果admin账号查不到先别急登录八成是导入的库选错了或者脚本执行中断。这个问题最常见的错误是打开Navicat时没有先切换到目标数据库就直接运行脚本数据全部建到了默认库下。5.4 常见的MySQL连接报错排查我整理过几类高频坑这里给出排查方向SSL连接错误报错信息带SSL、Public Key检查连接串是否加了useSSLfalseallowPublicKeyRetrievaltrue时区乱码报错信息带serverTimezone或者Öйú±ê׼ʱ¼ä加serverTimezoneAsia/ShanghaiUnknown database数据库没建或者连接串里的库名和实际库名不一致Access denied for user用户名密码不对或该用户没有目标库的访问权限max_allowed_packet超限批量插入或导入大SQL时报错调整MySQL配置里的max_allowed_packet或者拆分批处理这些坑几乎是每个前后端分离项目部署都会遇到的提前知道能省不少时间。6. 部署到服务器——jar包、Nginx、Tomcat三种方式的完整流程6.1 后端打包启动的一套组合拳后端部署前先确认生产环境配置。把application.yml里的数据库地址换成生产库端口保持默认或者在启动参数里覆盖。打包命令很简单mvn clean package -DskipTests执行完在target目录下生成一个xxx.jar文件。上传到服务器后最朴素的方式就是java -jar pm-system.jar但直接终端运行有个问题一旦断开SSH连接进程就挂了。所以我建议用systemd守护进程。在/etc/systemd/system/pm-system.service中写入[Unit] DescriptionPM System Service Afternetwork.target [Service] Typesimple Userroot WorkingDirectory/usr/local/pm-system ExecStart/usr/local/jdk/bin/java -Xms512m -Xmx1024m -jar pm-system.jar Restarton-failure RestartSec10 [Install] WantedBymulti-user.target然后执行systemctl daemon-reload systemctl enable pm-system systemctl start pm-system systemctl status pm-system之后查日志用journalctl -u pm-system -f。这套操作下来后端服务就自动重启、开机自启动了比nohup要稳得多。我实际使用中nohup方式进程莫名消失过几次换systemd之后再没出现过。6.2 前端构建和Nginx配置前端构建命令npm install npm run build执行完的dist目录就是全部静态资源上传到服务器任意目录比如/usr/share/nginx/html/pm。Nginx配置是核心先把静态文件服务配好server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/pm; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8010/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这里最容易被忽视的是location /里的try_files。它解决的是vue-router使用history模式时刷新页面404的问题。用户访问/project/1时服务器上不存在这个文件路径try_files会把请求回退到index.html由前端路由接管页面就能正确渲染。没有这一行刷新子路由页面就会404——这是前端部署里最经典的一个坑。location /api/的proxy_pass后面带不带/效果不同。带/表示把/api前缀去掉再转发也就是请求/api/project/list会转发到http://127.0.0.1:8010/project/list不带/则保持完整路径。具体用哪种取决于后端接口路径带不带/api前缀。如果后端Controller里RequestMapping(/api)就去掉/如果后端就是RequestMapping(/project)就得带/去掉前缀。这是个看起来不起眼、踩上去头破血流的配置项。6.3 Tomcat部署的适用场景这个项目的部署教程里也提了Tomcat它更适合那些必须用war包部署的传统场景。如果你公司统一要求应用必须丢进Tomcat的webapps目录里管理那打包方式改成warpackagingwar/packaging并让启动类继承SpringBootServletInitializer重写configure方法。剩下的流程就是把war丢进webapps启动Tomcat即可。但我的观念是Java项目能用jar就用jar。jar独立、内嵌Tomcat、启动就一个命令不存在同一个Tomcat里多个应用版本冲突的问题。war部署适合老运维团队习惯统一管理的情况新项目没必要逆潮流。6.4 云服务器环境快速配置如果是全新的云服务器我的建议顺序是安装JDK 8或11java -version验证安装MySQL 8设置root密码新建业务库和账号安装Nginx配置静态资源目录和反向代理上传后端jar包和前端dist目录关闭防火墙或放行端口云服务器尤其注意安全组按顺序启动MySQL、后端服务、Nginx第5步经常被忽略。云服务器的安全组规则只放行80的话后端的8010端口在外网是不可访问的但没关系因为我们通过Nginx反代外部请求只走80端口后端服务只要内网能访问就行。如果你希望后端端口直接暴露就得在安全组里放行8010不过不推荐容易被扫到攻击。7. 从开发到上线几个绕不开的实战大坑7.1 刷新页面404这个前面已经提到过因为vue-router默认是history模式URL很干净没有#号但服务器不知道/project/1该返回哪个文件。处理方案就是Nginx的try_files回退index.html。如果用的不是Nginx而是Tomcat也有类似问题不过Tomcat里没有try_files的简写配置一般要加Tuckey的UrlRewriteFilter相对麻烦。这也是我推荐Nginx部署前后端分离项目的原因——处理这种问题天然顺手。7.2 跨域问题要分开发和生产两套思维开发环境的跨域靠Vite/Webpack代理生产环境靠Nginx反代。如果生产环境还出现跨域八成是请求路径没走Nginx的代理规则或者后端CORS配置和生产环境Nginx代理的顺序冲突了。后端如果之前为了开发环境方便配了CorsFilter允许所有来源生产环境建议把Nginx的反代配好之后再决定是否收紧CORS策略。我曾见过一个系统生产环境用了CORS全放开被安全测试评为高危漏洞整改的时候得同时改后端配置和Nginx规则来回折腾很久。7.3 MyBatis的N1查询和缓存选择在任务列表中分页查出20条任务如果每条任务都要再查一次项目名称和负责人姓名数据库会多执行40条SQL。这叫N1问题。解决办法是用JOIN一次查出任务关联的项目名和负责人名或者用MyBatis的association和collection做嵌套结果映射。实际上一个列表页SQL写复杂点、只查一次比在Java层循环查询性能提升明显。MyBatis的一级缓存是默认开启的作用范围是同一个SqlSession。但Spring管理的Mapper每次执行都是独立的SqlSession一级缓存几乎不起作用。二级缓存默认关闭如果想要开启需要实体类实现Serializable并在Mapper XML里加cache/。不过我在实际项目中不敢随便开二级缓存因为一旦涉及关联表更新缓存刷新就有滞后风险容易出现脏数据。查询慢的根源尽量靠优化SQL和索引解决而不是靠缓存这个思路更稳妥。7.4 连接池配置别用默认值SpringBoot默认的HikariCP连接池很优秀但默认配置不一定适合你的业务量。我有一次压测时发现接口偶尔报connection is not available原因是Hikari的maximum-pool-size默认是10并发一超过10新请求就得排队等连接。后来调整配置后明显缓解spring: datasource: hikari: maximum-pool-size: 30 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000maximum-pool-size不是越大越好开100个连接数据库也未必扛得住。一般20到30够用具体看数据库服务器的性能指标。另外连接超时时间别设太短我设过10秒数据库偶尔flush一下慢查询前端就报连接超时了。30秒是经验值。7.5 文件上传遇到的坑很多项目管理demo不包含文件上传如果你要扩展MinIO是一个很好的选择。这个组合也是搜索里常出现的minio加入到springboot。流程是先装MinIO服务器然后SpringBoot集成MinIO Java SDK提供上传接口前端拿到上传URL后做文件展示。开发环境可以先用本地磁盘存储把功能跑通生产再切换到MinIO或者云OSS。自己用和小规模内网MinIO一把梭长期对外提供服务还是云OSS省心不需要运维对象存储服务器。7.6 日志和监控部署后千万别裸奔最后提一嘴线上环境不配日志会非常痛苦。SpringBoot默认只把日志打到控制台用systemd部署后日志被journald统一收集确实能journalctl看但日志一多就难查。我习惯用logback配置按天滚动appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file/usr/local/pm-system/logs/pm-system.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternpm-system.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory30/maxHistory /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n/pattern /encoder /appender配好之后查问题时直接tail -f /usr/local/pm-system/logs/pm-system.log或者用grep按时间过滤定位效率比在journal里翻高得多。我个人的体会是这类型的前后端分离项目管理系统技术上的难点不在于某个框架用得多深而在于把业务场景和工程实践完整串起来。整个过程里最容易耗时间的不是写代码而是环境配置、路径匹配、跨域处理这些细节。跑通一次之后这套体系基本就是通用技能以后再做类似的团队协作类系统都能直接复用这套思路。最后再分享一个小技巧。拿到任何前后端分离项目源码后建议先花半小时把数据库脚本和README彻底过一遍把表关系和接口文档理清楚再动手启动项目。这半小时的回报率极高。我也踩过那种图快直接启动结果缺依赖、缺配置、白屏、接口404连环炸的坑后来每次复盘都发现问题根源在前期没读懂文档。先看文档再动代码遇到问题能少走一半弯路。
