在Java技术栈里做web项目SpringBootVue3MyBatis这套组合这几年几乎成了“标准答案”。我最近正好把一套智慧社区系统从零到一完整落地前后端分离权限、业主、报修、缴费、公告、门禁这些模块都跑通了。这篇就把我从架构设计到数据库建表、从后端接口到前端页面、从部署上线到排坑的完整过程分享出来项目源码风格比较适合毕设、课设或者脚手架二次开发想拿Java面试题里那些所谓“高并发”“分布式”忽悠人的同学不如先把这套单体项目吃透来得实在。1. 系统整体设计与思路拆解1.1 为什么选前后端分离架构智慧社区系统不是那种内部管理系统它要面向业主、物业管理员、系统管理员三类角色甚至有业主端小程序、物业端后台管理、运营大屏等多端需求。如果沿用传统模板引擎比如Thymeleaf把页面渲染放在Server端最大的问题就是“多端适配”非常痛苦——小程序端、H5、PC后台三个端要是共用一个服务端渲染方案代码耦合度会高到让你怀疑人生。前后端分离的核心思路是后端只负责输出JSON数据前端通过HTTP请求动态渲染。这样做的好处有三点前端完全独立部署Nginx托管静态资源可以针对不同端做差异化的UI交互比如物业管理后台用Vue3Element Plus大屏可视化用ECharts互不干扰。后端接口可以复用一套API同时服务PC、小程序、未来可能的移动App改造一下鉴权方式就行。团队协作上前端和后端只需要约定好接口文档swagger/knife4j并行开发联调效率高。1.2 技术栈选型背后的思考SpringBoot选2.7.x版本而不是最新的3.x这是我自己踩过一次坑之后做出的选择。注意SpringBoot 3.x基于Jakarta EE 9很多老版本的第三方库不兼容。智慧社区项目往往要集成大量基础组件例如操作日志切面、旧版MyBatis插件、自定义序列化器如果你的依赖没有完全适配SpringBoot 3.x启动时会出现各种ClassNotFound或者Bean创建失败。从稳定性和生态兼容性考虑生产环境我用的是SpringBoot 2.7.12。Vue3这边组合式APIComposition API比选项式APIOptions API好在哪我用一句话给你概括选项式API把“同一业务逻辑”拆散到data、methods、watch里看着规整实际项目一复杂你要在三个地方来回跳才能看懂一个完整功能组合式API让你把一套功能的响应式数据、计算属性、监听器、方法放在一起内聚性明显更强。MyBatis没用MyBatis-Plus而是原生MyBatis XML映射文件这是刻意为之。后面第三节我会详细解释原因简而言之这是毕设和二次开发场景的“求稳做法”MySQL用8.0.33版本。1.3 智慧社区业务模块划分这套系统的业务边界特别清晰我第一版规划了七个核心模块模块名称核心功能对应角色业主管理业主信息登记、房屋绑定、家庭成员维护物业管理报修管理在线报修、工单流转、维修评价业主 物业缴费管理物业费账单生成、缴纳记录、欠费提醒业主 物业公告管理社区通知发布、置顶、过期下线物业管理访客管理访客预约、放行记录、黑名单业主 物业门禁记录进出记录查询、异常报警物业管理只读系统管理用户、角色、菜单、权限、操作日志系统管理员模块之间不是孤立的。举个例子业主下单报修后系统自动生成一条工单物业方处理完成后业主端能看到处理状态并评价——这套流程涉及业主、物业两个角色的数据交互因此用户权限控制和数据隔离在设计时要前置考虑等开发到半路再回头补权限就麻烦了。2. 核心细节解析与实操要点2.1 用户权限设计这是后端的灵魂智慧社区系统的权限模型用的是最经典的RBAC基于角色的访问控制用户都关联到角色角色再绑定菜单和按钮权限。数据层面我用了三张关联表sys_user、sys_role、sys_menu以及两张关联表sys_user_role、sys_role_menu。这套五张表模型对于管理类项目其实是“够用好几年”的不用一上来就上Spring Security的复杂配置。实际项目中我是这样设计权限的一个业主登录后默认分配“业主”角色他看到的是访客预约入口、我的报修、我的账单、社区公告和物业人员看到的完全是两套界面。物业管理员能进入工单处理、房屋信息管理、费用账单生成等后台管理页面。系统管理员只负责系统配置和审计日志不需要操作任何业务数据。权限的粒度需要细化到按钮级别。例如“报修删除”这个按钮只有特定角色能看到。后端的做法是在接口上使用自定义注解RequirePermission(repair:delete)由切面拦截校验当前登录用户是否具备该权限码这种方式比单纯靠前端v-if控制更安全。2.2 数据库设计MySQL表结构与场景逻辑建表之前我建议先画一张E-R图把核心实体的关系理清楚。智慧社区系统里比较关键的表有业主房产关联表、报修工单表、账单表、访客预约表。下面我直接给出几张核心表的建表语句你可以直接复用。业主表的核心字段简化版CREATE TABLE resident ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, user_id bigint(20) DEFAULT NULL COMMENT 关联登录用户ID, name varchar(50) NOT NULL COMMENT 业主姓名, phone varchar(20) DEFAULT NULL COMMENT 联系电话, id_card varchar(18) DEFAULT NULL COMMENT 身份证号, gender tinyint(1) DEFAULT 0 COMMENT 性别 0保密 1男 2女, building_no varchar(20) DEFAULT NULL COMMENT 楼栋号, unit_no varchar(20) DEFAULT NULL COMMENT 单元号, room_no varchar(20) DEFAULT NULL COMMENT 房号, audit_status tinyint(1) DEFAULT 0 COMMENT 审核状态 0待审核 1通过 2驳回, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT业主信息表;这里有三个细节值得注意性别字段注释里写0保密因为实际项目中有人不愿意填从用户体验和合规角度考虑不能强制。审核状态字段audit_status是为了应对“业主提交绑定申请→物业在后台审核通过”这个真实流程这个环节在多数毕设源码里会被直接省略掉但实际项目必须有。每个表都加create_time和update_time后续做操作日志、数据分析和排查问题时特别有用。报修工单表的字段设计核心思想就是“状态机流转”CREATE TABLE repair_order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(32) DEFAULT NULL COMMENT 工单编号, resident_id bigint(20) DEFAULT NULL COMMENT 报修业主ID, repair_type varchar(50) DEFAULT NULL COMMENT 报修类型水电/门窗/家电等, description text COMMENT 报修描述, images varchar(500) DEFAULT NULL COMMENT 报修图片逗号分隔, status tinyint(1) DEFAULT 0 COMMENT 状态 0待派单 1处理中 2已完成 3已取消, assignee_id bigint(20) DEFAULT NULL COMMENT 维修工ID, handle_remark varchar(500) DEFAULT NULL COMMENT 处理备注, complete_time datetime DEFAULT NULL COMMENT 完成时间, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报修工单表;在一次开发中我遇到一个比较典型的场景——业主提交的报修单物业方响应后维修工直接上门处理但维修工自己并不会登录后台所以状态由物业方直接修改。后来我加了assignee_id字段将维修工作为独立的用户类型挂到系统里流程才闭环。事后再看设计工单类表时一定要预留处理人的字段而不是只存业主ID这是很多新手容易忽略的点。2.3 数据库事务与防误操作设计缴费模块比较特殊涉及金额一个订单的生成、对账、缴纳状态更新必须在同一个事务里完成。对于业主在平台上一键支付这笔操作实际项目流程是这样的生成订单记录并且在订单表写入初始状态“待支付”。调用微信支付/支付宝支付的统一下单API拿到支付二维码。业主扫码支付后支付平台回调我们的后端接口此时通过回调返回的订单号将状态更新为“已支付”。同步在流水表里插入一条交易流水记录保证后续对账有据可查。这类涉及金额变动的方法我的习惯是在Service层方法上加Transactional(rollbackFor Exception.class)。但这里有个很多人容易犯的错直接在Controller层加事务注解。如果Controller调用多个Service方法事务边界就被扩大了里面任何一个非核心操作比如发送通知短信失败会导致整个事务回滚钱收了但业务单被撤销。正确的做法是事务只加在“真正的核心业务方法”上外围的短信、消息通知放到事务提交后再执行。3. 实操过程与核心环节实现3.1 环境准备与版本选型拿JDK来说我用的JDK 8对应Java 8配合Maven 3.8构建工具。节点版本用的Node 16.14因为Vue3 Vite4对Node版本有要求太老的Node跑不起来Vite太新的Node有时会有依赖兼容问题。数据库这边MySQL 8.0要注意时区参数设置。我的连接串长这样spring.datasource.urljdbc:mysql://localhost:3306/smart_community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueuseSSLfalse必须加上否则MySQL 8默认开启SSL会导致本机连接直接报错allowPublicKeyRetrievaltrue是解决基于caching_sha2_password认证方式的连接报错。3.2 SpringBoot后端工程搭建后端项目我按标准分层结构组织controller、service、mapper、entity、dto另外加一个common包放统一返回结果、全局异常处理、JWT工具类。Maven依赖中最核心的几个是dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version2.3.1/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.33/version /dependencyJWT做登录鉴权这个是当前前后端分离项目最主流的方案。服务端登录成功后签发token前端把token存到localStorage或者用pinia全局状态管理配合持久化每次请求在axios拦截器里加请求头Authorization: Bearer token后端通过拦截器校验token并把用户信息塞进ThreadLocal上下文。逻辑上是这套但也有一些容易被忽视的问题JWT本质上就是个自包含的令牌用户修改密码或注销登录后旧token其实还是有效的直到过期所以我额外在用户表加了一个token_version字段修改密码时递增版本在JWT的payload里带上这个版本校验时做个对比就不一致了就拒绝访问相当于提供了一层“可吊销token”的能力。3.3 MyBatis XML写法的取舍与打印SQL配置前面说了我坚持用原生MyBatis XML这是我个人认为的“控制感”和“透明性”最佳方案。MyBatis-Plus确实能省很多CRUD代码但有一个致命问题对于复杂的分页统计、多表联查、动态条件拼接这类操作MP的Wrapper写法虽然也能写但很多人写着写着就写出了全表扫描级别的SQL还意识不到最后性能出问题就只会问“为什么这么慢”。原生XML里你可以直接控制每一行SQL的写法动态SQL用where、if、foreach标签拼接还方便拿去数据库工具里执行验证。这里分享一个我在调试阶段非常依赖的习惯开SQL日志打印。mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true cache-enabled: truelog-impl配置成StdOutImpl会在控制台打印完整的Preparing、Parameters、Total这个输出对于定位参数绑定错误和SQL语法问题极其高效很多新手不知道这个开关排查问题时只会瞎猜。map-underscore-to-camel-case则会把数据库的下划线字段自动映射到驼峰属性省去一大堆手动映射的resultMap。但注意如果字段里有大小写混合命名例如buildingNo靠AS别名或者resultMap解决别偷懒。3.4 Vue3前端工程搭建与核心页面实现前端我用Vite4创建项目核心依赖是vue3、vue-router4、pinia、axios、element-plus、sass。这几个是现代Vue3项目的“六件套”如果你2026年再开新项目组合大概率还是这些只是版本可能升一升。特别说下状态管理。我在项目里用pinia做用户状态管理export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(token) || , userInfo: {}, permissions: [] }), actions: { setToken(token) { this.token token localStorage.setItem(token, token) }, setUserInfo(info) { this.userInfo info }, logout() { this.token this.userInfo {} this.permissions [] localStorage.removeItem(token) } } })相比Vuexpinia的API设计明显更符合直觉类型提示也更好。Vuex里的mutation、action、state那一堆概念在pinia里被简化成了“直接改state、直接定义action”心智负担小很多。用导航守卫来控制页面访问逻辑router.beforeEach((to, from, next) { const userStore useUserStore() if (to.path /login) { next() } else { if (!userStore.token) { next(/login) } else { next() } } })路由守卫做了“未登录就拉到登录页”的拦截接口层面的AuthInterceptor则保证即使有人伪造路由也无法直接调用后端接口拿数据形成双保险。页面开发方面我以“业主缴费”的列表页为例这算是一个典型的数据展示操作场景。前端处理步骤是进入页面时调用账单分页接口→表格渲染数据→根据账单状态决定每行显示哪些操作按钮→弹窗输入查询条件→提交表单后重新加载列表。Element Plus的表单校验、弹窗、Message提示这套组件体系很成熟开发效率高。3.5 前后端联调与本地代理配置前端开发服务器跑在5173端口后端接口跑在8080端口直接交互相当于跨域。本地开发环境有两个解决方案后端写个CrossOrigin注解或者全局CORS配置这在开发阶段省事但上线后前后端分域部署时还得再调整。前端用Vite的proxy代理配置把请求代理到后端地址让浏览器觉得所有请求都是同源的这个是更常见的做法也更贴近生产部署形态。我在vite.config.js里的配置如下server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这招在开发阶段几乎是必需技能。如果不配置代理就只能去后端改CORSLoophole很多、联调时也容易被绕晕。已配置好后再一问前端接口全都能正确响应相对就顺畅了。3.6 接口层统一返回与全局异常处理和前端配合的时候“接口返回格式统一”这条规则可以让整个团队都很舒服。我定义了一个统一返回对象R也有人叫Result结构是{ code: 200, message: success, data: {} }业务异常、参数校验异常、系统异常全部通过全局异常处理器RestControllerAdvice拦截转换成规定的返回格式。这样前端axios响应拦截器里只需要判断一次code如果不等于200就给用户弹出错误消息不用每个接口单独处理错误分支。这个统一返回对象是要结合HTTP状态码的。HTTP状态码负责描述“这次HTTP请求是否成功传输”业务code负责“这次业务操作是否成功”两者别混淆否则前端拦截器逻辑会特别混乱。我的约定是HTTP请求成功就返回200业务失败返回code500或者code4012这一类的业务码。4. 常见问题与排查技巧实录4.1 SpringBoot项目启动异常Datasource配置报错现象启动类直接报Failed to configure a DataSource。原因没有配置数据源参数SpringBoot自动装配时找不到DataSource对象。处理方式在application.yml补齐配置但如果当时只是单测某个Service、暂时不想连数据库可以在启动类或者测试类上加一个排除项SpringBootApplication(exclude {DataSourceAutoConfiguration.class})日常排查中最常见的不是这个而是把url写成了jdbc:mysql://localhost:3306/而漏掉了库名或者MySQL服务根本没启动。启动不了的顺序排查法先看MySQL有没有起再在命令行连一下数据库最后才是检查配置文件的拼写。4.2 MyBatis绑定异常Invalid bound statement现象调用Mapper方法时提示Invalid bound statement (not found)。原因接口和XML映射文件没有正确绑定。常见的有三种Mapper接口和XML文件的namespace写错了XML文件没有放在resources目录下正确的包路径中application.yml里没有配置mapper-locations。一个很隐蔽的原因是Maven构建时把XML文件排除了。pom.xml里对resources做了过滤默认只打包src/main/resources下的文件如果你的XML放在非规范路径就会漏掉。我的解决方案是在pom.xml里显式指定resources resource directorysrc/main/java/directory includes include**/*.xml/include /includes /resource /resources如果确定XML文件都在多半是namespace写错了对照接口的全限定类名检查一遍就行。4.3 MySQL 8.0 SSL连接报错现象启动或运行时报The server time zone value is unrecognized或者SSL connection error。原因MySQL 8.0默认时区是UTC和本地时间不一致SSL握手认证问题。处理方式在连接串上追加serverTimezoneAsia/ShanghaiuseSSLfalse。注意生产环境中MySQL服务端如果开了强制SSL就不能简单设置useSSLfalse。这种情况要生成证书或改用RSA公钥参考官方文档处理。开发环境下直接关闭SSL是合规的常规操作。4.4 Vue3打包后部署到SpringBoot的坑有时候前端打包完了想直接把dist目录丢到SpringBoot的static目录里一起部署。这个方案不是不行但有几个坑要避路由模式必须改成hash模式createWebHashHistory否则刷新非首页地址会404。前端资源路径要用相对路径base: ./否则部署到子目录时css/js文件全部加载不出来。后端接口和前端页面如果在同一个端口记得配置SpringBoot把未匹配的前端路由转发到index.html。对于生产环境我其实不太推荐这种单包部署方式更建议前端独立用Nginx部署后端用SpringBoot容器各自维护、各自扩容。把静态资源交给Nginx处理天然有缓存策略Gzip压缩也更好配置。4.5 前端跨域和登录状态丢失前端开发时proxy代理配置好之后一般联调就没问题了但登录状态丢失是个高频问题。排查思路查看localStorage里的token还在不在刷新页面后被清掉说明pinia持久化做了但读取逻辑不对。查看axios请求头是否携带了token如果配置了拦截器检查拦截器取token的时机。用store里的token但store可能在初始化时没有从localStorage恢复数据所以取到的是空字符串。后端拦截器校验失败统一返回401前端axios响应拦截器捕获到401就直接跳转登录页。这个逻辑要确保是在“非登录接口”才执行不然登录接口自己报错也会被送到登录页形成死循环。踩过一次之后前端初始化store时从localStorage恢复token的代码我都是最先写好根本不等后端联调。这是前后端协作里特别容易被忽视的细节。4.6 操作日志与缓存导致的数据不一致有段时间我把业主列表查询加了MyBatis二级缓存结果后台更新了业主信息后列表还是老数据。排查下来是二级缓存没做刷新。MyBatis的二级缓存默认是Mapper级别的如果你用了自定义的缓存实现比如Redis或者Caffeine必须确保增删改操作会主动清理相关缓存。不然以我当时的经验最直接的办法就是先移除二级缓存只保留一级缓存这样数据一致性更有保障。等需求明确要求“高并发只读”再考虑引入真正的分布式缓存。5. 项目代码的安全防护与部署上线经验5.1 防SQL注入和XSS攻击MyBatis的#{}预编译写法能天然防SQL注入但总有新手喜欢用${}去拼接表名或排序字段。${}是字符串替换存在注入风险除非那个位置必须是动态表名、动态排序字段这类数据库不支持预编译的情况。我的原则是能用#{}绝对不用${}确需用${}的地方做白名单校验例如排序字段只有create_time和update_time两个白值前端表单提交的字符串接口处做XSS过滤后端再用工具类对富文本内容或普通字符串中的script等危险标签进行转义。做管理后台的同学们一定要有“接口裸奔五秒钟就会被扫描器盯上”的意识安全不是上线后的事而是从写第一行代码就刻在骨子里的习惯。5.2 部署到Linux服务器CentOS/Debian部署这套项目大概分五步后端打包mvn clean package -DskipTests得到smart-community.jar。前端打包npm run build得到dist/目录。环境配置Linux服务器装JDK8、MySQL8、Nginx。启动后端用nohup java -jar smart-community.jar server.log 21 方式启动记得先配置好application-prod.yml里生产库的连接。配置Nginxserver { listen 80; server_name your_domain.com; location / { root /opt/smart-community/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这样前端页面加载、静态资源访问、API请求转发全部一次到位前后端分离的系统才算跑通了。5.3 项目源码的Git管理习惯最后聊聊工程的版本管理。这套项目有后端和前端两个子项目我建议用Git仓库分开维护或者用monorepo把两个子项目放在同一仓库的不同目录下。具体看团队规模如果是单人开发怎么舒服怎么来但有一点必须坚持不要把node_modules、target这类的编译产物提交进仓库.gitignore从一开始就配好。数据库脚本要单独放一个sql/目录每次表结构变更都要追加新脚本而不是去改旧脚本这是多人协作和后续回滚的保命习惯。写在最后的经验沉淀这套智慧社区系统从设计到上线前端、后端、数据库三层都踩了不少典型的坑。我最大的体会是对一个项目来说技术栈其实不是最大的难点真正的难点在于把业务逻辑理清楚、把边界划明白。像业主绑定房屋的审核流程、报修工单的状态流转、账单生成之后的防重复缴费这些细节才是决定系统能不能真正用起来的关键。技术选型上SpringBootVue3MyBatisMySQL这套组合在当前环境下依然是一个稳妥且生命力极强的方案它不花哨但足够扎实能快速出活也能稳定运行。读者要是拿这套源码去二次开发建议先跑通整个流程再往里面加自己想要的模块会比从零开始盲目堆功能顺畅得多。