1. 项目概述与技术定位第一次看到“前后端分离综合小区管理系统”很多人的反应是“又一个CRUD管理系统”。但实际动手做起来你就会发现这类项目是典型的“麻雀虽小、五脏俱全”它表面上是围绕小区业务做信息管理背后却把SpringBoot后端、Vue前端、MyBatis持久层、MySQL存储、权限控制、接口联调、部署上线这些Web开发全链路都串起来了。不管你是拿它当毕业设计、课程实训还是想快速积累一个能写进简历的完整项目这套东西都相当能打。我最终做出来的版本包含两个单独的工程一个是community-server后端工程另一个是community-ui前端工程。前端Vue负责页面渲染和用户交互后端SpringBoot负责业务逻辑与数据持久化两边通过RESTful API通信数据格式统一用JSON。这样拆分之后的好处十分直接前端不再关心SQL怎么写后端也不用操心按钮怎么摆各自独立开发、独立测试、独立部署这也是目前企业里主流的前后端分离开发模式。整个系统的核心业务覆盖了小区管理的常见场景房产信息管理、业主信息维护、楼栋单元管理、车位管理、费用账单管理、报修工单处理、访客登记、公告发布、投诉建议等。简单来说一个小区日常运营需要的管理功能这个系统基本都做到了。项目最值得参考的不仅是一堆增删改查页面而是它背后完整的工程化思路统一的Result响应封装、JWT令牌认证、拦截器校验、全局异常处理、日志记录、MyBatis动态SQL、前端路由守卫、Axios请求拦截、Vuex状态管理等。这些是平时零散学技术时很难串起来的“实战拼图”。这篇文章我就把这个项目从设计、编码、联调到部署的完整过程以及当中踩过的一些坑一五一十地拆给你看。顺便说一句这类系统适合谁来参考我建议主要是三类人刚学完Java基础和SpringBoot、想做一个完整项目练手的学生想转行Java开发、需要一个作品集项目的求职者以及在小公司或外包团队工作需要快速交付一个管理后台的初级开发。如果你已经能熟练写各种管理系统那这篇文章的部署和架构部分也有值得参考的地方。2. 技术选型与架构设计思路2.1 为什么选SpringBoot Vue这套组合这套组合放到今天几乎已经是Web管理系统的“默认配置”但每个技术选型背后都有它的理由下面拆开说。后端用SpringBoot图的是它快速启动、约定大于配置的特性。传统SSH或者SSM项目光写配置文件就要折腾半天而SpringBoot把Tomcat内嵌、自动装配都处理好了只要引入spring-boot-starter-web依赖一个注解就能启动Web服务。更关键的是SpringBoot生态太成熟了集成MyBatis只需要加一个依赖和几行配置集成JWT也不需要引入复杂的框架自己写个工具类就行。这对于中小型管理系统来说相当合适不需要微服务那套重型治理但需要稳定的开发效率和足够清晰的工程结构。前端选Vue说实话Vue的上手曲线比React更平滑一点模板语法对新手友好而且Vue全家桶Vue Router、Vuex、Axios提供了完整的单页应用解决方案。配合Element UI组件库后端把接口数据返回格式定义好前端直接绑定数据就能渲染表格和表单开发效率极高。Vue的双向数据绑定让表单交互的开发速度快得惊人尤其是小区管理这种需要大量表单录入和查询筛选的场景效率优势非常明显。MyBatis作为持久层框架核心优势在于SQL由开发者掌控。一些复杂的多表关联查询比如查一个业主名下所有的房产、车位和未缴账单用MyBatis写动态SQL配合ResultMap映射非常直观。相比JPAMyBatis的SQL可调优空间更大相比纯JDBC它又省掉了大量结果集解析的样板代码。对于小区管理系统这种以复杂查询为主的业务系统MyBatis基本是不二之选。2.2 前后端分离架构的工作方式前后端分离的核心其实就一句话前端展示和数据获取分离前端后端只通过HTTP接口打交道。具体到这套系统请求流程大致是这样的用户在浏览器中输入地址加载的是Vue构建出的静态资源HTML、CSS、JavaScript。页面渲染出来之后用户点击按钮、提交表单Vue通过Axios实例发送HTTP请求到后端的API接口。后端SpringBoot收到请求后先经过拦截器做登录校验然后分发到对应的ControllerService层处理业务逻辑Mapper层操作MySQL数据库最后把结果封装成统一的JSON格式返回给前端。Vue拿到JSON数据后更新响应式变量页面自动重新渲染。这中间有几个关键技术点跨域、鉴权、状态管理。跨域是因为前端开发服务器和后端接口服务器默认端口不同比如前端跑在localhost:8080后端跑在localhost:9090浏览器出于安全策略会拦截跨域HTTP请求。解决思路是后端配置CORS过滤器允许指定来源的跨域请求。部署上线时一般用Nginx把前后端放在同域下既解决跨域又提升访问性能。鉴权用的是JWT 拦截器。用户在登录页面提交用户名密码后端校验通过后生成一个JWT令牌前端把令牌存到本地我用的是localStorage也可以用Cookie每次请求时在请求头加上Authorization字段。后端拦截器会验证令牌的有效性如果令牌无效或者过期就直接返回401前端收到401后跳转到登录页。这个机制解决了HTTP无状态的问题“状态”被保存在令牌里后端不用维护Session信息。状态管理用Vuex来存放当前登录用户信息、路由权限、全局通知等共享数据。比如登录成功后把用户信息存入Vuex页面头部显示当前操作员姓名同时也方便后续权限判断。2.3 数据库设计的关键考虑数据库设计对于一个管理系统来说重要性甚至超过后端代码。小区管理系统核心的难点不在表多而在于业务对象之间存在各种关联关系。我设计的时候把数据表分了几类下面列出几张核心表的结构和设计考虑。第一类是基础档案表包括小区表、楼栋表、单元表、房屋表、业主表、车位表。楼栋、单元、房屋是典型的层级关系房屋表通过building_id、unit_id关联父级信息。业主表其实可以拆成业主身份表和房屋绑定关系表因为一个业主可能拥有多套房产一套房产也可能有多个共有人。如果简单地在房屋表里加一个owner_id字段就会丢失“一个业主多套房”的场景。所以我加了一张house_owner_rel关系表用house_id和owner_id多对多关联。第二类是业务数据表包括费用账单表、缴费记录表、报修工单表、投诉建议表。费用账单表的关键字段是house_id、fee_type物业费、水费、电费、停车费等、amount、due_date、status。我建议把账单状态用数字表示0未缴、1已缴、2逾期这样在SQL里做统计聚合很方便。报修工单表则需要冗余一个report_owner_id报修人因为报修人不一定是业主本人可能是住户或租客。第三类是系统支撑表包括用户表、角色表、菜单权限表、操作日志表。用户表和业主表可以是解耦的业主可能有登录账号但系统管理员不一定是业主。所以我单独建了一张sys_user表用owner_id字段和业主表做可选关联。角色和菜单权限表是经典的RBAC模型用户与角色关联角色与菜单关联登录后根据角色动态生成可访问菜单列表。这里有一个经验想特别强调时间字段的类型选择。Java端的LocalDateTime和MySQL的datetime配合最顺手尽量避免用timestamp类型因为它在2038年会有溢出问题而且受时区影响容易踩坑。我习惯统一所有表的创建和更新时间字段用datetime并在Java实体类上用LocalDateTime类型接收。3. 核心功能模块与开发要点3.1 功能清单与业务全景图小区管理系统的功能模块我做的时候是按照“基础数据 → 日常业务 → 运营管理 → 系统设置”四层来划分的。这种分层思路也建议你直接照抄因为后面开发、测试、写文档都能按这个维度拆解。第一层基础数据管理小区信息维护、楼栋管理、单元管理、房屋管理、业主管理、车位管理。这层解决的是“小区有什么”的问题是最底层的数据支撑。第二层日常业务费用管理账单生成、缴费登记、欠费查询、报修管理业主报修、派工处理、进度反馈、访客管理访客登记、放行记录、投诉建议投诉录入、处理反馈。这层是小区里每天都会真实发生的业务事件。第三层运营管理公告发布、停车管理、报表统计收费率、报修完成率、入住率、数据看板首页仪表盘展示核心指标。这层主要给物业运营人员使用方便掌握整体运营状况。第四层系统设置用户管理账号启停用、密码重置、角色管理不同角色分配不同菜单权限、菜单管理、操作日志查询谁在什么时间做了什么操作。这层是任何一个管理系统的底座没有它系统就谈不上安全。每层模块的开发技术难度其实并不高关键在业务场景的理解和边界情况的处理。以费用管理为例“生成账单”就不是简单的插入几条数据这么简单物业费账单一般是月度或者季度自动生成水费电费账单是按抄表数来算的。我做的是每月1号定时任务扫描所有房屋自动生成上月的物业费账单逾期未缴自动标记为逾期。这套逻辑用Spring的Scheduled注解就能实现需要注意的只是定时任务里的并发控制和失败重试逻辑。3.2 权限管理的前后端实现权限管理是管理系统中绕不开的重点。用户登录后能看哪些菜单、能操作哪些按钮都得通过权限体系来控制。我采用的是经典的RBAC基于角色的访问控制模型。数据库层面涉及五张表用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户属于一个或多个角色比如某位员工同时是“收费员”和“报修处理员”角色绑定一堆菜单权限。后端提供两个接口登录成功后返回用户信息和JWT令牌获取当前用户信息的同时返回该用户拥有的菜单列表和按钮权限标识。后端拦截器负责验证JWT有效性验证通过后再从当前用户的权限集合中判断是否有权限访问某个接口。简单接口用注解RequirePermission(system:user:add)标记AOP切面对注解进行拦截判断没有权限就返回403。权限判断的关键是保证逻辑在“服务端”完成前端做的只是隐藏入口真正的安全边界在后端接口层。前端拿到菜单列表后通过Vue Router的addRoutes方法动态注册路由。这样用户没权限的页面根本无法访问即使手工修改URL也会被前端路由守卫拦截。按钮权限用自定义指令v-permissionsystem:user:add控制没有权限的按钮直接移除DOM。这里给你一个实操建议前端权限码必须和后端注解里的权限码完全一致否则会出现“菜单看得见但是接口全部403”的尴尬局面我一开始就吃过这个亏。3.3 核心接口设计与状态码约定接口设计是否规范直接影响前后端联调效率。我建议从项目一开始就定死几套约定后面对接会特别顺。统一返回格式是基础。后端所有接口返回的数据结构都固定为这样{ code: 200, message: 操作成功, data: {} }code用数字状态码200成功、400参数错误、401未登录、403无权限、500服务器异常。前端Axios拦截器统一处理code为200直接取datacode为401跳登录页并提示重新登录code为500弹出错误提示。这样可以避免大量重复的错误处理代码。分页查询接口的参数约定也很有讲究。前端传pageNum和pageSize后端返回{ total: 100, rows: [] }这里有个很多新手容易犯的错误前端老想着用返回的rows.length判断页面上有没有数据或者把total当成rows用。分页查询的返回必须同时包含总数和当前页数据列表前端表格组件才能正确显示总页数。我用的是MyBatis的分页插件PageHelperPageHelper.startPage(pageNum, pageSize)之后紧跟着的查询语句会自动分页返回的PageInfo对象里直接有总记录数非常方便。再一个关键是时间格式的统一。如果不做处理后端返回的LocalDateTime序列化出来是一串数组前端根本没法直接用。我用了Jackson的配置统一成yyyy-MM-dd HH:mm:ss字符串格式配置如下spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT8这几个约定一旦确定后面所有接口的开发就变成了流水线作业Controller收到参数 → 调Service处理 → 返回统一Result。效率高且不易出错。目录结构我按常见的分层方式组织controller、service、mapper、entity、dto、vo、config、utils、exception、aspect等包。分包的粒度不要太细太细了找类都费劲保持“职责清晰但不过度拆分”就好。4. 前后端联调与核心功能实现展示4.1 后端核心代码赏析与实现逻辑后端有几个地方我认为是整个项目的大脑和血管直接决定系统的健壮性和可维护性。挑几个最核心的部分说说代码不贴完整版只拆关键思路。第一个是统一登录认证流程。用户提交用户名密码后Service层调用UserMapper查出用户校验密码。这里的密码存储我用的BCrypt加密不是明文。之所以不用MD5是因为BCrypt每次生成的盐不同同一密码存入数据库的密文也不同并且自带强度因子抗暴力破解能力比MD5强得多。登录成功之后用JWT工具类生成令牌令牌里只放用户ID和用户名这类必要信息不要往里面塞太多业务数据因为JWT是base64编码并没有加密谁知道都能解码看到内容。第二个是全局异常处理。用RestControllerAdvice注解写一个全局异常处理器针对不同异常类型返回不同的响应。业务异常比如“该房屋已售出不能重复绑定”返回code400和提示信息参数校验异常返回code400和具体哪个字段出错兜底异常返回code500和“系统异常请稍后重试”。这个机制最大的价值在于后端永远不会把Java堆栈信息直接暴露给用户避免信息泄露同时前端收到的错误提示足够友好。第三个是动态SQL。MyBatis的where、if标签在复杂查询里特别好用。比如房屋分页查询用户可以按小区、楼栋、单元、房屋状态等条件组合搜索用动态SQL拼条件一段Mapper XML就能搞定大量组合查询场景后端Service层不用写一堆if分支去拼接条件对象。第四个是操作日志。我封装了一个Log注解配合AOP切面在方法执行前记录请求参数、执行后记录响应结果异步写入日志表。切面里需要从SecurityContext或者线程变量中获取当前操作人信息否则记录日志没有意义。异步写入用的是Spring的Async防止日志写入拖慢业务接口的响应时间。第五个是定时任务。生成物业费账单、检查车位到期提醒这类功能用Scheduled(cron 0 0 1 1 * ?)每月的1号凌晨执行。定时任务方法里要注意加try-catch否则一个房屋生成失败可能导致整个批处理中断。更稳妥的做法是一条条处理每条房屋失败的记录到一张失败日志表里方便排查。4.2 前端关键页面与接口对接实录前端部分我重点讲登录页、首页数据看板、费用管理页面这三个典型场景的实现路径掌握了这三个其他页面的套路的你都能自己推导。登录页是前端和后端第一次联调的入口最容易出现的问题就是跨域和Token存储。登录成功后把返回的token放入localStorage然后Axios每次请求前读取token放到请求头里。这里要小心axios拦截器的编码顺序请求拦截器必须在实例创建时就配置好否则某些请求会漏加请求头。我是这样组织的// request.js const service axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error { return Promise.reject(error) })响应拦截器里我处理了401跳转逻辑如果响应状态码是401清除本地用户信息跳转登录页并提示“登录状态已过期请重新登录”。这里一定要避免死循环跳转登录页时要判断是否已经在登录页不然会出现反复重定向。首页数据看板是整个项目里最有“面子”效果的部分也最体现前后端配合。我用的是ECharts在Vue的生命周期mounted中调用接口把返回的数据传给图表组件。核心指标包括小区总户数、入住户数、本月收费金额、未处理报修工单数、近一周访客流量趋势、各楼栋缴费率对比。这些数据后端用一个专门的统计Service聚合查询避免前端多次往返请求。一个聚合接口返回一个包含多个指标的对象比前端拉一堆列表自己算要高效得多。费用管理页面是业务最复杂的一个页面。核心操作有三个生成账单、缴费登记、欠费查询。生成账单时前端要选择费用类型和计费周期提交给后端后后端先检查该周期是否已经生成过账单避免重复生成。缴费登记时前台要显示房屋信息、业主姓名、应收金额、滞纳金等确认后提交缴费后端在一个事务里完成“插入缴费记录更新账单状态”两步操作防止数据不一致。这里有一个事务切面容易踩坑的点只在public方法上生效且同类内部调用不生效。所以“生成账单”和“缴费登记”这两个核心方法我放在了不同的Service类里或者通过代理对象调用自身方法保证事务注解能正常工作。如果你发现一个方法自己调用自己时事务失效了就是这个原因。4.3 数据库初始化与实际数据模拟数据库脚本是整个项目的起点。我的建议是除了建表语句之外一定要准备一套演示数据。原因很简单没有数据的管理系统前端的表格、图表、统计全部是空的你根本看不出功能是正常的。尤其在演示和测试时一套真实的模拟数据能帮你快速发现SQL逻辑是否正确。我的初始化脚本里包含一个完整小区的模拟数据几栋楼、每栋楼几个单元、每个单元几户业主、每户绑定1到2名业主、每户生成过去半年的物业费账单数据、部分账单已缴部分未缴。注意模拟数据之间的时间关联和逻辑关联要合理比如生成一份2025年3月的物业费账单那缴费日期应该是3月之后不能搞穿越。初始化SQL脚本的风格我这几年逐渐养成一个习惯建表语句和演示数据分开存放。schema.sql只放表结构data.sql放初始化和演示数据。在生产环境上线时只执行前者在开发测试环境才执行后者。这样能避免生产库中混入不必要的测试数据。另外有一点强烈建议所有表都加上created_at和updated_at字段这在排查问题时非常有用比如定位一条脏数据是什么时候写进去的。哪怕业务代码用不到这两个字段保留它们几乎是零成本价值却很大。5. 本地开发环境搭建与配置要点5.1 基础环境版本清单开发这套系统我用的环境版本如下建议直接照着搭省得各种奇奇怪怪的兼容性问题组件版本说明JDK1.8 或 11我用的是1.8稳定且生态兼容最好Maven3.6.3用于后端依赖管理和打包Node.js14.x 或 16.xVue CLI 4/5对低版本Node更友好MySQL5.7 或 8.0数据库5.7和8.0的驱动配置有差异IDEIntelliJ IDEA / VS Code前后端可以分开用不同IDEGit2.x用于版本控制这里有个容易踩坑的版本细节MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver连接URL上还要带serverTimezoneAsia/Shanghai参数否则时间处理会出问题。如果你的数据库是5.7驱动类名用com.mysql.jdbc.Driver就行。如果默认使用8.0版本SpringBoot的pom.xml里对应依赖的mysql-connector-java版本也要是8.x的否则数据库连接会报错。5.2 后端配置文件和关键参数解读后端工程的核心配置文件是application.yml里面的配置项虽然多但真正需要你理解透彻的是下面这几个模块。数据源配置是整个后端的命脉spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/community_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456useUnicodetruecharacterEncodingutf8是为了保证中文数据正常读写。中文乱码问题绝大多数情况不是代码问题而是连接URL上没加这段参数或者MySQL数据库本身的字符集不是utf8。建库时我建议明确指定字符集CREATE DATABASE community_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;。注意用utf8mb4而不是utf8因为要把Emoji表情和生僻字存进去utf8在MySQL里是阉割版字符集某些汉字的存储会有问题。MyBatis配置方面我开启了驼峰自动映射和日志输出方便调试时查看SQLmybatis: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl mapper-locations: classpath:mapper/*.xmlmap-underscore-to-camel-case: true的作用是把数据库里的下划线字段名比如house_id自动映射到Java实体类的驼峰属性名houseId这一点一定要开否则实体类的每个字段都要手写ResultMap映射写到你怀疑人生。JWT配置放在自定义前缀下方便统一管理和修改jwt: secret: your-secret-key-must-be-long-enough expire: 604800secret是JWT签名密钥生产环境必须足够长而且要放在环境变量或配置中心里不能直接硬编码推到Git仓库。expire是过期时间单位秒604800正好是7天。这个过期时间要合理设计太短用户体验差、动不动重新登录太长安全性差Token泄露后长时间有效。管理系统的登录态一周过期是比较合理的折中。5.3 前端环境配置和代理方案前端工程的启动配置也有几个关键点。第一是Node版本别太新Vue CLI 5配Node 18以上有时会出现兼容性警告但不是必然失败。遇到Node版本问题建议用版本管理工具切换Node版本比卸载重装省事得多。其次是开发环境的跨域代理配置。在vue.config.js中配置devServer代理把前端请求转发到后端开发服务器module.exports { devServer: { port: 8080, proxy: { /api: { target: http://localhost:9090, changeOrigin: true } } } }这样前端发请求的时候写/api/user/login开发服务器把它自动代理到http://localhost:9090/api/user/login顺便把跨域问题也解决了前端不用在后端CORS上反复调试。需要注意的是代理changeOrigin: true会把请求头中的Host字段改成目标地址否则部分后端框架的请求校验会失败。前端环境变量配置在.env.development和.env.production文件中。开发环境的baseURL为/api走代理生产环境的baseURL为完整域名或者不带前缀由Nginx统一转发。这个细节如果没区分好就会出现一个经典问题本地跑得好好的一上线全挂报404或者接口找不到。6. 打包部署全过程实录6.1 后端打包的两种产物生成方式后端打包成可执行Jar是最常见的部署方式。先用Maven的package命令打包重点检查pom.xml里是否包含了SpringBoot打包插件plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version2.7.18/version /plugin用mvn clean package -DskipTests执行打包会生成一个可以直接运行的Jar包。-DskipTests跳过单元测试如果测试类里依赖数据库连接跳过能省很多时间。打包完成后在target目录下能看到类似community-server-1.0.0.jar的文件这就是最终产物。还有一种部署方式是打成WAR包放到外部Tomcat里但这种做法在当前场景下已经不太推荐了。SpringBoot内嵌Tomcat相当稳定打成Jar包用java -jar直接启动管理简单、环境依赖少。除非你公司的运维规范要求必须用外部Tomcat否则我都建议用Jar启动。打好的包要验证一遍我的习惯是在本地先执行一次java -jar启动然后用curl访问一个不需要鉴权的接口测试连通性。不要等部署到服务器上再发现包是坏的排查成本完全不一样。6.2 前端构建与Nginx配置详解前端构建核心就一条命令npm run build。构建完成后在dist目录下生成一堆静态文件——index.html、static/js、static/css等。这些文件直接扔给Nginx托管就行。Nginx配置是实现“前后端同域访问”的关键。一个管理系统的常规Nginx配置如下server { listen 80; server_name your-domain.com; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api { proxy_pass http://127.0.0.1:9090; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files $uri $uri/ /index.html;这一行是Vue Router的history模式必须的配置。因为Vue是单页应用路由是前端的比如访问/owner/listNginx服务器上并没有这个物理路径找不到文件会直接404。配了try_files后Nginx会在找不到资源时返回index.html让前端路由自己接管页面渲染。location /api的proxy_pass把API请求转发到后端Java进程。这里有个细节注意proxy_pass http://127.0.0.1:9090;后面没有斜杠表示把原始请求的URI完整转发过去如果加了一个/则会把/api前缀去掉再转发。具体用哪种要看后端接口的URL是否带/api前缀前后端要一致否则接口404。前端如果配置了带/api的baseURL那么后端的Controller映射也应该以/api开头这样前后端在路径上天然对齐部署时Nginx只需简单转发即可。6.3 服务器环境搭建实操记录这一部分我尽量把实际执行过的命令和步骤完整列出来。以一台全新Linux服务器CentOS系或者Ubuntu都类似为例。第一步更新系统软件包并安装MySQL。装完后初始化数据库执行之前准备好的schema.sql。这里有个要点初始化完数据库后要专门创建一个业务账号而不是直接用root账号让后端连接。例如创建community_user账号只授予community_db库的全部权限降低风险。第二步安装JDK和Maven。这一步不用多讲用包管理器装或者手动解压都行。关键是配置好环境变量。装上之后记得用java -version和mvn -version验证一下。第三步上传Jar包到服务器指定目录比如/opt/community-server/用nohup后台启动nohup java -jar community-server-1.0.0.jar --spring.profiles.activeprod app.log 21 --spring.profiles.activeprod表示激活生产环境配置。同时我强烈建议写一个简单的启停脚本比如start.sh和stop.sh用jps或者ps -ef | grep community找到进程PID然后杀掉。脚本化管理部署是运维的基本功后面你会频繁用到。第四步安装Nginx把前端dist目录文件上传到/usr/share/nginx/html替换掉默认的Nginx欢迎页。配置好第6.2节里的Nginx代理配置后执行nginx -t检查配置语法通过以后nginx -s reload重载配置。到这一步整个系统已经可以通过浏览器访问了。打开http://服务器IP你应该看到登录页面。用管理员账号登录然后一个一个过功能确认所有接口都正常返回。6.4 部署过程中的安全加固简易指北既然都部署到服务器上了安全方面的基础加固不能完全不做尤其系统里存着小区业主的姓名、电话、身份证号等敏感信息。分享几个成本很低但收益明显的点。数据库账号必须限制来源主机不要用%通配所有IP。把community_user账号的主机限制为localhost或后端服务器的内网IP。这样即使数据库端口暴露到公网也只有指定来源能连暴力破解的成本会高很多。生产环境的Nginx要开启Gzip压缩和静态资源缓存。静态资源带hash的文件可以设置较长缓存时间比如location /static/ { expires 7d; }index.html则设置no-cache保证发版后用户能及时刷到新版本。开启Gzip后前端资源体积能减少60%以上加载速度提升明显。6.5 常见问题排查与避坑经验汇总项目从开发到部署完成我踩了不少坑下面把典型问题按“现象—原因—解决办法”的方式列成速查表建议直接收藏。现象可能原因解决办法前端页面打不开控制台报404Vue Router history模式未配try_filesNginx配置中添加try_files $uri $uri/ /index.html;登录提示“系统错误”后端日志显示“Access denied for user”数据库账号密码或权限配置错误检查application.yml数据源配置用Navicat测试连接前端报跨域错误开发环境代理没配或者生产环境未做同域转发开发环境配置devServer.proxy生产环境统一通过Nginx转发接口返回401登录后瞬间失效JWT密钥不一致或令牌过期时间过短检查前后端是否使用同一个jwt.secret调整过期时间中文显示乱码数据库连接URL缺字符集参数或数据库本身字符集不对URL加characterEncodingutf8建库指定utf8mb4上传接口报“超出文件大小限制”Nginx默认client_max_body_size为1MBNginx配置设置client_max_body_size 10m;事务方法内自调用不生效Spring事务代理机制限制不要在同类内部直接调用通过注入自身代理或拆分Service前端页面刷新后白屏publicPath和Nginx静态资源路径不匹配Vue构建配置publicPath: /部署路径保持一致除了表格里的这些问题再分享几个深度一点的排查经验。定位问题时第一步永远是看日志不要瞎猜。后端日志文件里能看到完整的堆栈信息前端打开浏览器开发者工具看Network面板中请求的状态码和响应体。前后端分离项目问题基本都能靠“后端看日志前端看Network”这一组合定位到。遇到接口报500先去看后端控制台输出的是什么异常十有八九是SQL写错了、字段类型对不上、或者空指针日志里都有明确信息。有一个和“静态资源404”容易混淆的场景值得单独说Nginx配置写对了但首页能打开接口能通只有页面里引用的JS和CSS资源404。这种情况要么是dist目录下静态资源没有上传完整比如漏了static目录要么是baseURL配错导致页面请求发到了一个不存在的路径。检查的时候不要盯着index.html看要先看浏览器控制台里具体的资源路径和实际服务器文件的对应关系。7. 项目的二次扩展思路与个人经验总结系统如果按现有功能开发完其实已经是一个能用的版本了。但如果你是想更进一步我有几个明确的扩展方向建议按优先级排列。第一个扩展方向是缴费渠道的对接。目前系统只有线下收费登记可以对接微信支付或支付宝实现业主在线缴费。技术栈上需要添加微信支付SDK、支付回调处理、账单状态回写逻辑。这样系统会“活”起来变成真正有价值的生产力工具而不仅是演示系统。第二个扩展方向是消息通知。业主报修进度、缴费提醒、公告发布这些都可以通过短信或站内消息推送。后端可以引入消息队列比如RabbitMQ把业务事件发到队列消费者异步发送通知避免业务接口被通知逻辑拖慢。第三个方向是数据可视化升级。当前首页看板已经能看核心指标真正有深度的是物业经营分析报表比如按季度统计收费率趋势、按楼栋分析报修频次、预测下月水电费支出。这些可以用定时任务生成报表数据表前端用ECharts做更复杂的趋势图和热力图。回顾这个项目从零到落地的整个过程我最大的感受是这类“管理系统”看起来到处都是但亲手把架构、权限、接口、部署全链路走一遍才是真正把零散知识点变成工程能力的关键一步。项目里的每一次“这里怎么写更合理”“为什么这么配不会出错”背后都是真实业务的权衡和工程经验的沉淀。最后分享一个我自己比较受用的小习惯养成把每一类问题的排查要点写在项目根目录的README.md里的习惯尤其是那些不太好搜到答案的坑。等下次发版遇到同样的问题翻一下自己的笔记几分钟就能定位省下的时间远比写笔记的时间多。希望这篇文章能帮你在自己的项目里少走几步弯路也欢迎在实践中遇到具体问题的时候带着场景来聊我们一起把经验补全。