ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

法律援助咨询系统Java项目实战:Spring Boot+Vue前后端分离部署指南

法律援助咨询系统Java项目实战:Spring Boot+Vue前后端分离部署指南 简介在Java Web开发中前后端分离架构已成为企业级业务系统的主流形态而Spring Boot与Vue的组合更是其中应用最广泛的技术栈之一。一个典型的业务系统往往涵盖用户管理、工单流转、数据统计、登录鉴权等核心模块理解其分层架构与数据流转逻辑是开发者从学生走向工程实践的关键一步。本文从一套完整的法律援助与咨询系统出发梳理Spring Boot后端分层设计、Vue前端页面组织、MySQL数据库表关联与索引优化、JWT登录鉴权机制等基础概念并结合实际部署中常见的环境配置、跨域处理、SQL脚本导入等问题给出可复用的排错思路。无论你是准备校招面试、接手遗留系统还是构建毕业设计掌握这套从环境搭建到二次开发的完整路径都能有效提升对Java实战项目的驾驭能力并为后续扩展消息通知、文件上传等高级功能打下坚实基础。1. 项目全貌法律援助与咨询系统到底是个什么项目拿到这个项目压缩包的时候我第一反应是这其实是一个很典型的“管理系统 业务服务”双核心结构的Java Web项目。名字叫“法律援助与咨询系统”听起来偏政务或公益但实际上拆开看它解决的是非常具体的业务问题——让有法律咨询需求的用户能够在线上提交问题让律师或法律援助人员能够在线受理、回复、跟踪案件进度同时后台还能对咨询记录、律师信息、法律知识相关内容做统一管理。这种项目在真实的IT职场里出现频率极高因为它涵盖了一个成熟业务系统该有的几大模块用户端在线咨询、后台工单处理、信息分类管理、登录鉴权、数据统计等。从学习和就业的角度看刷透这样一个项目比刷十个“图书管理系统”Demo有价值得多。从压缩包的结构来看这个项目是完整的前后端分离结构后端基于Java技术栈配合MySQL数据库前端是独立部署的界面工程另外还附带了一份说明文档用来指导环境搭建和运行部署。这种“完整前后端 文档 数据库脚本”的打包方式已经是目前市面上Java实战项目最常见的交付形态也非常接近企业里一个全栈开发工程师接手“半成品系统”时的工作场景。我觉得在正式动手跑这个项目之前必须先做一件事把压缩包里的文件结构浏览一遍。我见过太多人拿到项目就急着启动服务结果卡在各种资源缺失、配置不对的问题上。正确做法是先看目录、再看SQL脚本、然后才是配置文件最后考虑启动的事。从信息完整度来说这套项目已经算比较良心的了有数据库初始化脚本有后端工程有前端工程还有说明文档。4个要素凑齐意味着你完全可以照着文档从零跑起来。这套系统适合谁去研究我总结下来是三类人第一类是正在准备Java实习或校招的在校生手里需要一个“有业务深度”的项目来丰富简历第二类是刚进公司、被分配做业务系统维护或二次开发的新人需要快速理解一个成熟项目的结构和套路第三类是律师团队或基层法律服务机构的IT人员想通过现成系统快速实现线上咨询流转。当然如果你是打算基于Spring Boot Vue做毕业设计的同学这套系统更是一个可以直接参考甚至扩展的现成底座。2. 前后端工程结构与技术选型思路深度拆解2.1 后端分层架构为什么Java项目都爱这么组织代码打开后端工程后你大概率会看到一套非常标准的Spring Boot项目结构。controller包、service包、mapper或dao包、entity或model包、config包五层结构清清楚楚。很多初学者第一次看到这种分包会觉得“类怎么这么多”但我要说一句这种分层不是无聊的教条而是工程项目能够长期维护的根基。举个例子用户提交一条法律咨询请求请求先到达controller层这一层只负责接收参数和做简单的参数校验不写任何业务逻辑。然后它把数据传递给service层service层负责真正的业务处理判断用户是不是登录状态、咨询内容是否合规、是否需要指派给特定律师等等。数据持久化工作则由mapper层完成它通过MyBatis或MyBatis-Plus封装的SQL语句和数据库交互。这种分层的最大好处是“职责单一”。哪天你发现咨询列表查询速度慢你只需要去查询语句对应的mapper文件里优化SQL而不用在controller里翻找业务代码。反过来如果业务规则变了比如新增一个“咨询内容需要先经过敏感词过滤再入库”的需求你只需要改service层接口对外保持不变。对于法律援助和咨询这种需要频繁调整业务流程的系统而言这种可维护性太重要了。我查看过很多类似项目的代码这套系统的后端选型大概率是Spring Boot MyBatis-Plus MySQL Spring Security或JWT实现登录鉴权。Spring Boot负责提供自动化配置让项目不用再去手动配置一堆XMLMyBatis-Plus把单表CRUD的SQL都内置了开发者只需要写复杂的多表查询语句JWT则解决了前后端分离场景下的登录状态传递问题这个后面我细说。2.2 前端页面组织Vue Element UI是这类项目的标配前端工程这块标题里没有明确写Vue但结合当前Java前后端分离项目的主流生态这台系统的前端方案基本可以锁定为Vue框架搭配Element UI组件库。原因很简单Vue在国内开发者群体的普及率极高Element UI又提供了现成的表格、表单、弹窗、菜单组件拿来搭管理后台效率非常高。前端工程内部的典型结构是这样的views目录存放页面组件比如咨询管理页面、律师信息页、系统用户页router目录维护前端路由告诉浏览器哪个URL对应哪个页面api目录封装了所有向后端发送请求的方法比如request.js里统一配置了请求的baseURL和拦截器store目录如果有的话是Vuex或Pinia用来存登录状态、用户信息这类全局数据。这里我想强调一下“api目录统一封装请求”这个做法。在真实开发中几乎不会在每个页面里直接写axios请求而是先在api目录下的某个js文件里定义方法然后页面组件调用这个方法。比如咨询管理页面里有“获取咨询列表”这个操作前端代码会调用api/consultation.js里定义的getConsultationList()方法方法内部再用axios向后端发送GET请求。这么做的优势是如果后端接口地址变了你只需要改api目录里的一个文件而不是在几十个页面里逐个找、逐个改。还有一个关键点是跨域处理。前端工程默认运行在8080端口后端Spring Boot运行在8081或9090端口两个端口不同就会产生跨域问题。解决方案不外乎两种在后端写一个CorsConfig配置类允许指定来源的跨域请求或者通过前端开发服务器配置代理转发。实践中我更推荐后端配置CORS因为这样前后端联调时不需要额外依赖前端服务器的代理配置而且上线后如果前后端仍然分离部署CORS配置是必须的。2.3 说明文档的价值不是摆设是救命稻草很多同学拿到压缩包里的“说明文档”只当作一个装饰品但我做项目有一个习惯永远是先看文档后看代码。一份合格的说明文档会写清楚这几件事开发环境版本要求、数据库初始化步骤、后端启动方式、前端启动方式、默认登录账号。这套系统的说明文档如果内容足够完整你按照文档走一遍就不会出现“配置了半天项目还是启动不了”的尴尬局面。而现实情况是很多项目包里的文档是缺斤短两的只有简简单单的“把sql导入mysql、运行后端、运行前端”三句话。如果你手里的文档也是这种精简版我建议你主动给它做一次补充把所有踩过的坑、配过的参数都加进去做出一份属于自己的“部署排雷手册”。这个过程对理解项目整体运作的帮助胜过你重写一遍代码。3. 环境准备与项目部署从零跑通整套系统3.1 环境清单哪些工具版本是关键部署这套Java前后端分离项目之前先把环境对齐否则会出现各种莫名其妙的问题。我列一下这套项目的标准环境组合组件推荐版本说明JDK1.8或11大多数教学项目基于JDK 8编写11也能兼容Maven3.6后端依赖管理工具建议用Maven 3.6.3及以上MySQL5.7或8.0两个版本都可以但要注意驱动和连接串差异Node.js14.x或16.x前端工程运行环境版本太新可能兼容性问题npm/yarn随Node自带用于安装前端依赖包IDEA2021后端开发IDE社区版也能用VSCode或WebStorm任意前端开发工具按个人习惯选择JDK版本这里我要多说一句如果你的系统环境是JDK 17甚至21遇到旧项目直接跑不起来不用慌张。要么在IDEA里把项目的SDK切到8或11要么在pom.xml里调整一些依赖版本。实操中我发现把Spring Boot 2.3.x升级到Spring Boot 2.7.x通常就能兼容新JDK但这是改代码的方案学习阶段尽量别折腾直接用JDK 8最省心。MySQL版本选择上如果你之前装的是MySQL 8.0而SQL脚本里用到了类似“utf8mb4_0900_ai_ci”这样的排序规则导入时会提示字符集不支持。解决办法是下载脚本后用文本编辑器把排序规则全局替换成“utf8mb4_general_ci”。这个问题我遇到过不下三次几乎可以写进“Java项目部署十大坑”里了。3.2 数据库初始化正确导入SQL脚本的方式数据库脚本通常放在后端工程根目录或sql目录下文件名叫xxx.sql或init.sql。导入流程不复杂但有几个细节需要特别注意。先在MySQL里创建一个空数据库我用命令行举例CREATE DATABASE legal_aid DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后执行导入命令mysql -u root -p legal_aid init.sql进入MySQL客户端用show tables查看表是否创建成功。如果表都在再用select * from user表之类的语句确认初始数据是否写入。这里有几个容易踩的雷。第一个数据库编码。如果创建数据库时没有指定utf8mb4而SQL脚本里又有中文数据导进去就是一堆问号前端页面显示乱码。所以创建数据库时字符集一定要显式指定。第二个SQL脚本内部的数据库名。有些脚本里会包含“use dbsql”之类的语句如果你本地数据库名和脚本里写的不一样导完后数据进到了另一个库里后端连的是你新建的库自然查不到表。解决方法是记事本打开SQL脚本搜索“USE”语句把库名改成你自己的库名。第三个MySQL版本兼容性。用Navicat或DataGrip这类图形化工具导入大SQL文件时如果中途报错通常是指定行有语法不兼容问题。建议用命令行方式导入因为命令行工具对SQL文件的容错性更好而且能看到具体哪一行出错。3.3 后端启动最容易失败的三个环节后端启动前要改的核心配置在application.yml文件里。重点关注三个配置项端口号、数据库连接串、Redis配置如果有的话。这套系统大概率没有引入Redis那我重点说MySQL配置。server: port: 8081 spring: datasource: url: jdbc:mysql://localhost:3306/legal_aid?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver注意这里的驱动类名用的8.0版本的驱动类com.mysql.cj.jdbc.Driver。如果你的项目里引入的MySQL连接驱动是5.x版本驱动类要改成com.mysql.jdbc.Driver。而且JDBC URL里的serverTimezone参数是必须的不加它连MySQL 8.0时会报时区错误。改好这些在IDEA里打开后端工程等待Maven把依赖下载完然后运行启动类的main方法。正常启动后IDEA控制台会打印Spring Boot的标志和Tomcat started on port(s): 8081。这个日志一出现说明后端已经跑起来了。如果你在启动时报“无法连接到数据库”先不要怀疑代码先检查MySQL服务是否启动、用户名密码是否正确、库名是否和配置里一致、数据库是否能被外部访问。排查顺序从成本和概率上来讲最快的是在命令行用mysql -u root -p手动连一次秒级验证。3.4 前端启动npm install是第一个坑前端工程启动的标准三步流程是npm install npm run devnpm install这一步是下载项目的所有前端依赖速度取决于网络环境。如果你的网络条件不太理想可以考虑用淘宝镜像源来安装npm config set registry https://registry.npmmirror.com npm install依赖装完后运行npm run devVue项目会默认在localhost:8080端口启动也可能配置成别的端口以package.json里的scripts为准。前端启动后我建议做的第一件事不是登录而是打开浏览器开发者工具来看Network请求。如果有一个请求报404或500说明前端已经正确调到了后端接口只是接口内部有问题如果请求根本没发出说明前端配置的接口地址有问题。打开api目录下的request.js或http.js检查axios的baseURL设置是否指向了后端的地址。比如后端端口是8081那么baseURL应该写成http://localhost:8081。前后端联合调试时还有一个经典问题前端请求成功但拿不到数据控制台报CORS error。这个错误信息翻译过来就是跨域被拦截了。虽然在前端配置代理可以解决开发阶段的跨域但我更建议在了解跨域原理的前提下直接用后端CORS配置来解决毕竟上线部署后前后端往往还是分开跑的一次配置长期有效。4. 数据库表设计与业务流程的对应关系4.1 核心表结构从登录到咨询全流程的数据支撑打开数据库脚本看表结构你会发现这套系统的表设计基本覆盖了一个完整业务闭环。我根据自己的项目经验推测这套系统至少包含以下这些表用户管理方面大概率有用户表、律师表还可能有关联角色和权限的表。用户表核心字段是用户名、密码、昵称、联系电话、角色标识。密码存储一定是加密后的字符串常见的是BCrypt加密前端传原文后端加密后落库。你要是发现脚本里密码字段是一串以$2a$开头的字符串不用怀疑就是BCrypt。咨询业务方面核心的是咨询记录表、回复记录表、案件分类表。咨询记录表会记录咨询者ID、咨询标题、咨询内容、所属分类、状态字段待分配、已回复、已关闭、发布时间等关键信息。回复记录表则关联咨询记录ID和律师ID保存回复内容、回复时间。这种“一主一从”的表设计在业务系统里是最常见不过的它意味着一次咨询可以有多条回复相当于帖子与评论的关系。法律资源方面可能还会有法律知识表、法律法规分类表用来支撑系统的内容展示功能。这类表通常包含标题、内容摘要、正文、发布时间、浏览量等字段。把这些表合在一起看整个系统的数据流转逻辑就非常清楚了前端用户注册登录后发起咨询系统把咨询记录写入咨询表后台运营人员或律师查询待处理咨询在回复表中新增一条回复用户再刷新页面时前端接口查询咨询记录的同时关联查询回复记录展示出完整的咨询对话链条。4.2 表关联关系为什么查询要join这么多表在设计上咨询记录表需要关联用户表查出咨询者的姓名或昵称还要关联分类表查出咨询类型。回复记录表需要关联咨询记录表查出对应的问题也要关联律师表查出回复人身份。这种多表关联在查询时就会用到JOIN语句或MyBatis的多表查询配置。举个例子查询“当前用户的所有咨询记录及最新回复”这个需求SQL大致是这个形态SELECT c.id AS consultation_id, c.title, c.content, c.status, u.nickname AS user_name, r.reply_content, r.create_time AS reply_time FROM consultation c LEFT JOIN user u ON c.user_id u.id LEFT JOIN reply r ON c.id r.consultation_id WHERE c.user_id #{userId} ORDER BY c.create_time DESC这里有两点值得注意。第一用LEFT JOIN而不是INNER JOIN是因为用户发起的咨询可能还没人回复INNER JOIN会把这一类记录过滤掉显然不符合业务需求。第二如果一条咨询有多条回复这个查询会产生多条记录你会发现同一条咨询被重复列出。实际开发中这种情况有两种处理思路一是业务上限定一条法律咨询只有一条“官方回复”状态机比较简单二是把回复列表做成子查询或者在后端代码里组装成父子结构。我倾向于在了解业务规则后再决定用哪种方案不要为了追求“技术先进”而过度设计。4.3 数据库优化与常见运维问题很多同学本地启动项目后就觉得数据库操作已经“够用”了但如果这个系统真的要投产使用比如服务一个城区上千名咨询用户表里积累了几千条咨询记录后全表扫描会明显变慢。针对这种情况至少要在两个字段上加索引user_id和status。索引的原理不复杂相当于给字段建了一个有序的目录查询时通过目录快速定位而不是翻遍整本“书”。一般用Navicat直接在表设计界面添加索引即可或者用SQL语句ALTER TABLE consultation ADD INDEX idx_user_id (user_id); ALTER TABLE consultation ADD INDEX idx_status (status);联表查询还有一个常见问题是忘记加索引导致join性能雪崩。如果你发现某条查询耗时超过一秒先把SQL拿到数据库客户端里执行一次EXPLAIN看它的possible_key和key列。key列为空就说明没走索引结合查询条件把对应字段的索引补上。这一步排查习惯在进入企业工作后会让你少挨很多骂。5. 核心功能模块代码实操与业务实现细节5.1 登录鉴权JWT方案在前后端分离项目里的落地这套系统的登录机制我推测用的是JWT配合拦截器的方式。JWT的全称是JSON Web Token本质上是一串经过签名的字符串服务端在用户登录成功后把这串token返回给前端前端在后续每次请求的请求头里带上token后端拦截器验证token是否合法。登录流程拆开看是这样的第一步前端把用户名和密码通过POST请求发送到后端/login接口。 第二步后端从数据库查出用户用BCrypt的matches方法比对密码原文和加密串。 第三步比对成功则生成JWT其中包括用户的ID、用户名、角色信息用密钥签名后返回给前端。 第四步前端把token存在localStorage或sessionStorage中。 第五步每次请求时前端在request拦截器中设置请求头Authorization为token值。 第六步后端的Spring拦截器拦截业务接口请求解析token解析成功则放行失败则返回401状态码。这里有一个实操中的关键点token的密钥和过期时间要放在配置文件里不要写死在代码中。比如jwt: secret: your-secret-key-here expire: 86400 # 过期时间单位秒一天后过期expire设置为86400也就是24小时。做演示项目时可以设长一点比如7天方便开发调试但如果上线生产环境这个时间最好缩短一些同时配合前端的“记住登录状态”功能来做续签。我在实际调试时遇到过一种典型情况JDK版本不一致导致JWT依赖生成的token在启动时校验失败。这种问题排查起来很隐蔽因为没有启动报错只有调用接口时提示“token无效”。处理办法是先检查pom.xml里的jwt依赖版本我推荐用io.jsonwebtoken的jjwt 0.9.1版本配JDK 8如果JDK是11建议升级到jjwt 0.11.5并调整依赖坐标。5.2 咨询流转从用户发起咨询到律师回复的完整链路咨询功能是这个业务的主动脉我们把这条链路完整过一遍。用户在前端表单里填写咨询标题、咨询内容、选择分类点击提交。前端这里需要做非空校验和字数限制Element UI的Form组件自带rules校验规则设置好required属性和min/max长度即可。如果用户没有登录前端要提前拦截并跳转到登录页减少后端无效请求。后端接收到请求后controller层用RequestBody接收一个咨询表单对象用Valid注解触发参数校验。校验通过后就调service层service层把当前登录用户ID从JWT中解析出来设置到咨询对象上再把状态初始化为“待处理”写入数据库。律师端的处理流程则是律师登录后进入待办咨询列表页前端调后端接口查询状态为“待处理”的咨询记录。律师点击某条咨询进入详情页查看用户提交的完整描述在回复输入框填写答复内容提交后后端生成一条回复记录同时把咨询状态更新为“已处理”。你会发现这里有一个潜在的并发问题如果两位律师同时点开同一条“待处理”咨询并且同时提交回复会不会产生两条官方回复业务上如果设定“一条咨询只能有一条官方回复”就必须在代码层面加控制。简单方案是在更新状态的SQL里增加一个条件判断UPDATE consultation SET status 已处理, reply_time NOW() WHERE id #{id} AND status 待处理这条SQL类似乐观锁只有当咨询状态还是“待处理”时才能把状态改成“已处理”。如果影响行数为0说明已经有别人抢先处理了这条咨询本次提交就视为重复操作。这种方式不需要引入任何额外组件实现成本低逻辑也容易理解非常适合这种业务规模不大但需要保证数据一致性的系统。5.3 管理员功能用户管理、分类管理、咨询监管管理后台是这套系统的“调度中心”管理员角色通常负责三件事管理用户账号、维护咨询分类、监督咨询回复质量。用户管理功能的核心是列表分页查询。前端传current和size参数给后端后端用MyBatis-Plus的Page对象接收通过selectPage方法查询返回给前端一个包含总记录数、当前页数据、总页数的结果对象。前端用Element UI的el-table展示数据配合el-pagination实现分页切换。分类管理相对简单就是一组增删改查接口。需要留意的是删除分类时如果该分类下已经有咨询记录出于数据完整性考虑不能物理删除应该做逻辑删除即加一个deleted字段默认值为0删除时更新为1。这样历史咨询记录依然能关联到分类名称不会出现“咨询单上的分类已经不存在了”的尴尬。监管功能这块管理员可以查看所有咨询记录和律师的回复内容如果发现回复质量不过关可以下架或要求律师重新解答。这些操作本质上还是对状态字段的修改技术难度不高但业务意义很大。在项目文档或简历中能讲清楚这套“申诉—分派—答复—质检”的闭环流程比单纯说“做了一个带增删改查的项目”要高级得多。5.4 说明文档的实操价值如何用好这份资料这篇博文前面提过说明文档不能不看那具体怎么看才算“会用”呢我有一套自己的方法。第一次拿到项目我会把说明文档当成“甲方需求书”来读只关心三件事这套系统给谁用、主要功能是什么、跑起来需要哪些环境。读完后心里对系统边界有个整体认知。开始动手部署时我又把文档当成“实施手册”来用每一步都对照文档操作。文档写了“导入SQL脚本”我就按它的步骤来文档如果没写才去翻代码自己摸索。最后项目跑通了我会回头在文档的基础上补充自己的部署记录、问题笔记形成一份“升级版说明文档”。这样做的理由是说明文档往往保留了原作者对这个系统的第一手理解包括他设想的部署方式、默认配置项、注意事项。这些信息是代码本身不会告诉你的属于项目开发过程中积累的隐性知识。会利用这些信息是衡量一个开发者项目驾驭能力的隐形指标。6. 常见启动报错与避坑经验速查手册6.1 后端启动类问题排查报错现象可能原因解决方案端口被占用8081端口已被其他程序使用修改application.yml端口号或用netstat -ano命令查占用进程Failed to configure a DataSource未配置数据库连接信息检查application.yml的spring.datasource配置项Access denied for user数据库用户名或密码错误用命令行验证账号密码检查访问权限Unknown database数据库不存在或库名不一致执行create database或修改连接串库名MalformedByteSequenceExceptionSQL脚本编码问题把SQL文件另存为UTF-8编码重新导入java.sql.SQLSyntaxErrorException表名或字段名大小写/关键字冲突检查表名是否包含user、order等SQL保留字必要时加反引号端口被占用的问题是新手最容易碰到的。在Windows上可以用cmd执行netstat -ano | findstr 8081最后面一列是进程PID然后打开任务管理器找到这个PID对应的进程结束它。注意有些进程是电脑系统服务结束前要确认不是重要程序。Linux和macOS上用lsof -i:8081比较方便。还有一个隐蔽问题是IDEA中的Maven配置文件指向了错误的本地仓库。有时候你明明把maven配置配好了IDEA还是用它内置的Maven。解决办法是在IDEA的Settings里找到Build Tools下的Maven把Maven home path改成你本地的Maven目录并确认User settings file指向你自己的settings.xml否则每次下载依赖都会跑到默认的C盘用户目录里时间长了还会把磁盘撑爆。6.2 前端启动与联调问题排查报错现象可能原因解决方案Vue packages version mismatchvue和vue-template-compiler版本不一致执行npm install vue-template-compiler版本号匹配package.json中的vue版本Error: Cannot find module node-sass依赖未正确安装优先删掉node_modules重新npm installnode-sass安装失败时改用sassProxy error: Could not proxy request前端代理地址配置错误查找vue.config.js或vite.config.js中的proxy目标地址确认与后端端口一致404 Not Found接口路径错误打开Network面板查看请求URL和后端controller的RequestMapping路径比对请求头缺少token导致401登录状态失效重新登录检查前端请求拦截器是否正确读取了token前端依赖安装这块我见过最频繁的问题是node-sass安装失败。node-sass是一个需要本地编译的库不同Node版本对它的兼容性要求非常苛刻。现在很多新项目已经放弃node-sass改成dart-sass了如果你手里的项目还在用node-sass且安装报错可以尝试在package.json里把node-sass换成sass依赖名称改变后代码里的import语法基本不受影响。6.3 数据相关问题的排查思路数据库相关的坑往往最隐蔽因为代码看起来完全没问题就是数据不对。最常见的几个现象是列表数据为空、数据重复、乱码。列表数据为空的第一排查点是数据库里到底有没有数据。很多人导入SQL脚本时报了一堆错但没细看继续启动项目结果页面上空荡荡的。先查数据再查代码。第二排查点是表名映射MyBatis-Plus默认是按实体类名转下划线去找表如果实体叫LegalConsultation映射的表名是legal_consultation而你的表叫consultation就需要用TableName注解显式指定。这种问题多发生在二次开发过程中自己新加表时容易忽略。数据重复的问题大概率出在多表关联查询上像是前面说的“一条咨询多条回复”造成的重复记录。排查方法是把生成的SQL打印出来在数据库客户端里手动执行一遍看结果集长什么样再决定是去重还是改查询逻辑。乱码问题分为前后端两侧。前端乱码很可能是页面编码没设置UTF-8在index.html加一句即可。后端返回乱码需要检查Spring的编码过滤器和数据库连接串里的characterEncodingutf8参数。还有一个小细节IDEA里项目源码文件的编码如果不是UTF-8硬编码的中文字符串发送到前端就会出现中文变问号。在IDEA设置里把File Encoding全部切换成UTF-8再重编译一次通常能把这类问题解决。7. 基于这套系统做二次开发的进阶方向7.1 补齐消息通知功能目前的系统结构里用户提交咨询、律师提交回复都是被动的“去页面查看”模式体验相对原始。如果要做功能升级我最推荐补充消息通知模块。技术实现路径不复杂回复表中增加一个是否已读字段用户每次登录后前端调一个“未读消息数”的接口后端根据登录用户ID去回复表里统计未读数量在页面顶部展示一个红点或角标。再进一步的话可以引入WebSocket当律师提交回复时主动向前端推送一条通知用户页面无需刷新就能看到新消息提醒。WebSocket在Spring Boot里的集成方式已经非常成熟通过实现WebSocketConfigurer和WebSocketHandler就能完成基础能力。这个升级的价值在于它把一个“纯被动查询”的系统变成了“有主动触达能力”的系统用户体验会有质的变化而且技术实现门槛并不高是简历上很好写的一个优化点。7.2 接入文件上传让咨询内容更丰富法律咨询的场景里用户很多时候需要上传合同照片、法院传票截图等证据材料。现在的系统如果只能填写文本内容功能是不完整的。补充文件上传功能可以从两个层面做。最简单的方案是后端新增一个upload接口接收MultipartFile类型参数把文件保存到本地的upload目录下然后把访问路径返回给前端。前端用一个el-upload组件上传成功后把返回的URL一并提交到咨询表单里。这个方案实现简单适合学习阶段或小规模使用。规模大一点的话应该把文件存到云存储或专用文件服务器上避免本地磁盘回收和扩容问题。不过从项目学习的角度先把本地文件上传跑通理解整个流程的请求—存储—回显—访问闭环就已经达到了练习目的。7.3 管理端数据看板管理后台如果只有表格和列表看起来总觉得少了点“数字化”的味道。加一个数据统计看板是整个项目颜值和完成度提升最快的方式。看板可以展示以下核心指标今日新增咨询量、待处理咨询量、律师回复平均时长、热门咨询分类TOP5、近七日咨询趋势。实现手段上用ECharts这个图表库结合后端提供的统计接口。统计接口的SQL复杂程度不高比如“近七日咨询趋势”就是在咨询记录表里按日期分组计数SELECT DATE(create_time) AS query_date, COUNT(*) AS total FROM consultation WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY query_date把结果集封装成前端图表要求的格式前端用ECharts的折线图渲染即可。这个功能做完系统的视觉完成度和“含金量”都能提升一个档次。8. 写在最后一个老开发者的实际体会翻完这套法律援助与咨询系统的完整工程我最大的感受是它不是一个能让你“看一遍就会”的项目而是一个需要你亲自把每个模块跑通、每张表理清、每个接口调通才能内化的项目。它的价值不在于代码本身有多高超而在于它完整呈现了一个业务系统从数据库设计到前后端联调的标准路径。我个人的经验是拿到这类项目后不要急着改代码、加功能先在不修改任何源码的前提下把整套系统跑起来。哪怕只是成功登录一次、提交一条测试咨询、看到律师端能查到这条咨询这套系统的“运行逻辑”就开始在你脑子里建立起来了。然后你再去看代码之前云里雾里的地方会突然变得清晰——因为你已经见过它运行时的样子。最后再说一个小技巧。在你研究这个项目时把所有的报错信息都复制到一个专门的笔记文件里包括你当时是怎么解决的。这样整理出来的材料不仅是你面试时的谈资也是你未来做其他项目时最靠谱的排错手册。踩过的坑变成文档记录下来才真正变成了你自己的经验。本文还有配套的精品资源点击获取
返回列表