资讯动态

法律援助与咨询系统全栈实战:Spring Boot+Vue+MySQL部署解析

发布时间:2026/10/8 15:58:22 来源:尧图企业网站定制
简介这是一份面向Java Web初学者的毕业设计项目实现法律援助与咨询系统的完整前后端功能。前台提供站内新闻、在线留言、用户注册、系统公告与在线申请援助等模块后台涵盖系统用户、用户信息、法律咨询、站内新闻、援助申请及系统公告的管理注册用户还可修改资料并跟踪自己的援助申请。项目基于JSPServlet技术搭配MySQL 5.7数据库环境配置清晰适合课程设计或毕业设计参考。压缩包共669个文件以jsp页面、Java类、HTML/CSS/JS前端资源、SQL建库脚本及说明文档为主总大小约4.49MB目录划分明确便于按前台、后台与配置文档分别学习。目前已有33人浏览学习。下载后可获得可直接导入Eclipse/IDEA运行的工程源码、数据库脚本及配套说明文档可快速了解法律援助业务场景下的前后端交互与增删改查实现。1. 先搞清楚法律援助与咨询系统到底是个什么项目拿到名为「法律援助与咨询系统」的 Java 项目压缩包里面装的是完整前后端源码、说明文档和 MySQL 数据库脚本。这套系统本质是一个典型的 Java Web 信息管理系统普通用户注册后可以提交法律咨询、浏览律师档案、发起线下预约律师登录后接单并给出文字回复管理员负责审核用户、管理律师入驻和查看全部咨询流转。它解决的痛点很具体——法律服务机构日常接待咨询时记录散乱、分配靠口头传达这套系统把咨询从提交、分配到回复的整条链路搬上线。对开发者来说它是少见的「一套代码同时覆盖 Spring Boot 后端、Vue 前端、MySQL 库表设计」的完整前后端分离项目实战样本常被拿来当毕业设计、求职作品也是 Java 面试前复习 CRUD 与权限流程的现成素材。2. 架构与技术选型拆解Spring Boot Vue MySQL 各自管哪一块拿到压缩包先别急着解压跑代码。第一步是把包里的内容按职责分清楚哪个目录是后端工程哪个是前端工程哪个是数据库脚本哪个是说明文档。这类 Java Web 模板项目的通用结构是「后端 Spring Boot 前端 Vue 数据库 MySQL 5.7/8.0」三个部分独立成目录靠 HTTP 接口对话。理解了这条主线后面跑通和改功能才有方向。2.1 Spring Boot 后端为什么这类模板默认用它如果你打开后端目录常见做法是看到一个 Maven 工程pom.xml 里引着 spring-boot-starter-web、mybatis-plus、mysql-connector-java 这几个核心依赖。Spring Boot 之所以是这类项目的默认选择不在于它功能多而在于它把「能让 Web 项目跑起来」这件事压缩到了最低成本内嵌 Tomcat 不需要单独装服务器application.yml 里配好端口和数据源就能启动MyBatis-Plus 又帮你省掉了大部分单表 CRUD 的 SQL 编写。后端工程的代码分层基本是固定的四层Controller 接收前端请求并返回 JSONService 写业务逻辑Mapper 操作数据库实体类对应每张表。以咨询提交流程为例用户在前端点「提交咨询」前端把标题和内容 POST 到 /api/consultationController 接到参数后交给 Service 层校验用户身份、插入 t_consultation 表最后返回带主键的结果给前端。这条链路里 Spring Boot 管的是请求怎么进、参数怎么绑定、异常怎么统一处理MyBatis-Plus 管的是数据怎么落库。看后端代码时我建议先看 application.yml再看 Controller 层的路由最后才看 Service 实现。因为配置决定你能不能跑起来路由决定系统有哪些功能Service 决定业务规则怎么写的。很多新手一上来就翻 Mapper XML结果被一堆动态 SQL 绕晕其实这个项目里 80% 的数据库操作都是单表增删改查MyBatis-Plus 的 BaseMapper 已经帮你实现了真正需要手写 SQL 的只有多表联查和统计报表。2.2 前端页面与后端接口前后端分离的边界在哪前后端分离是这套系统最值得研究的设计。所谓分离是指前端工程和后端工程是两个独立项目、两套独立进程、两个不同端口它们之间只通过 JSON 格式的 HTTP 接口通信。前端跑在 3000 端口Vue 开发服务器默认端口后端跑在 8080 端口浏览器访问页面时页面里的 JavaScript 代码会向 8080 发起 Ajax 请求拿数据。分离的边界在于「谁管界面渲染谁管数据」前端管页面长什么样、用户点了什么、表单校验、路由跳转后端管数据对不对、权限够不够、业务规则怎么执行。这种拆分的好处是前端可以单独开发单独测试后端接口也可以拿 Postman 或 curl 单独验证。代价是引入了跨域问题——浏览器会拦截从一个端口页面发往另一个端口的请求所以前端工程里通常会配一个转发规则把 /api 开头的请求转发到后端的 8080 端口这个配置写在 vue.config.js 这类构建配置文件里。看前端目录时重点关注三个地方src/router 目录下的路由表决定页面有哪些src/api 目录下的接口封装决定前端调后端的地址和方式src/views 目录下的 .vue 文件是每个页面的具体实现。这套系统的前端页面一般是 Vue 2 Element UI 的组合Element UI 提供表格、表单、弹窗这些现成组件所以你看到的大部分页面代码是在组装组件而不是从零写 HTML。2.3 说明文档的正确阅读顺序先需求、再库表、后接口压缩包里带说明文档是这类项目比普通开源项目更友好的地方但很多人不会用。我拿到手会按固定顺序读先读需求说明或项目介绍搞清楚这个系统有哪些角色、每个角色能干什么然后打开数据库设计文档对着实体类看表结构接着看接口文档里的 URL 列表和前端 api 目录做对照最后才看启动手册准备跑代码。需求文档解决的是「系统应该长什么样」的问题。常见的法律援助与咨询系统至少要覆盖三类角色普通用户能注册登录、查律师、提咨询、约时间律师能登录、接单、回复、管理自己的咨询列表管理员能审核用户、管理律师档案、查看全部咨询和预约记录。你拿需求文档里列的功能点去后端 Controller 里找对应路由再去找前端页面三个点连成一条线一个功能就算真正看懂了。接口文档通常是一个表格或 Markdown 文件列出每个接口的请求方式、路径、参数和返回结构。读接口文档时别只看路径要看请求参数的必填性和返回码的含义。比如登录接口失败时返回什么 code、什么 message前端拿到后怎么提示用户这条链路的容错设计才是面试时能讲出东西的地方。3. MySQL 数据库设计与建库脚本法律援助业务怎么落表数据库脚本是这套系统的地基。法律援助与咨询系统的数据模型不算复杂核心是用户、律师、咨询、预约四类实体的关系。先把这几张表的设计逻辑讲清楚再直接给出可以照着执行的建库建表脚本最后用一个真实业务场景串起多表联查这是我认为跑通项目前最应该花时间的一章。3.1 五张核心业务表的设计思路与建表 SQL典型的法律援助与咨询系统表设计围绕角色和业务流转展开常见做法是包含五张表用户表 t_user 存所有账号和角色律师表 t_lawyer 存律师的执业信息咨询表 t_consultation 存用户提问和律师回复预约表 t_appointment 存线下约见记录公告表 t_notice 存后台发布的通知。用户表通过 role 字段区分普通用户、律师和管理员三种角色律师表通过 user_id 关联到用户表这是「账号与档案分离」的设计——登录凭据归用户表专业信息归律师表。下面是核心表的建表语句数据库名我用 legal_aid表名前缀 t_ 是这类模板项目的常见风格。先建数据库和用户表CREATE DATABASE IF NOT EXISTS legal_aid DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE legal_aid; CREATE TABLE t_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录账号, password VARCHAR(100) NOT NULL COMMENT 密码MD5加密存储, real_name VARCHAR(50) NULL COMMENT 真实姓名, phone VARCHAR(20) NULL COMMENT 手机号, role TINYINT NOT NULL DEFAULT 0 COMMENT 角色0普通用户 1律师 2管理员, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态0禁用 1正常, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间 ) ENGINE InnoDB COMMENT 用户表;这段 SQL 的关键点有三个。第一是字符集必须用 utf8mb4它才能完整存储中文和生僻字如果用了 utf8 会在插入某些特殊字符时报错。第二是 role 字段用 TINYINT 而不是字符串节省空间且方便后端用数字判断权限。第三是 status 字段做逻辑删除和禁用标记业务系统不会真的把用户数据从表里删掉而是把 status 置为 0 实现「软禁用」这也是 Java 面试常问的点。接着建咨询表和预约表。咨询表是这套系统最核心的表它要记录谁问的、谁答的、问的什么、有没有回复CREATE TABLE t_consultation ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, user_id BIGINT NOT NULL COMMENT 提问用户ID, lawyer_id BIGINT NULL COMMENT 接单律师ID, title VARCHAR(200) NOT NULL COMMENT 咨询标题, content TEXT NOT NULL COMMENT 咨询内容, reply_content TEXT NULL COMMENT 律师回复内容, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待分配 1已接单 2已回复 3已关闭, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 提交时间, reply_time DATETIME NULL COMMENT 回复时间 ) ENGINE InnoDB COMMENT 咨询记录表; CREATE TABLE t_appointment ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 主键, user_id BIGINT NOT NULL COMMENT 预约用户ID, lawyer_id BIGINT NOT NULL COMMENT 律师ID, appoint_time DATETIME NOT NULL COMMENT 预约见面时间, content VARCHAR(500) NULL COMMENT 预约事由, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态0待确认 1已确认 2已完成 3已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 提交时间 ) ENGINE InnoDB COMMENT 预约表;咨询表里 lawyer_id 允许为空是因为用户提交咨询时系统还没分配律师这是业务状态的自然反映。status 字段用数字表示流转状态后端每步操作只改状态值前端根据状态值渲染不同的按钮和标签。预约表的 appoint_time 是业务时间字段和 create_time 这种系统时间要区分开——一个是用户选的一个是系统记的。3.2 建库、账号授权与初始化数据数据库建好之后还要解决「用什么账号连库」和「初始化数据从哪来」两个问题。压缩包里一般带 sql 脚本文件用 Navicat 或命令行执行即可但执行前建议先手动建一个专门的项目账号避免直接用 root 账号跑业务代码。下面这段 SQL 创建账号并授权CREATE USER legal_userlocalhost IDENTIFIED BY Legal123456; GRANT ALL PRIVILEGES ON legal_aid.* TO legal_userlocalhost; FLUSH PRIVILEGES;这样做的实际意义是把数据库账号和业务系统绑定即使业务代码里的密码泄露攻击者拿到的也只是 legal_user 对 legal_aid 库的权限而不是整个 MySQL 实例的管理权限。初始化数据方面至少要有管理员账号和测试律师账号才能体验完整流程常见做法是往 t_user 表插入三条不同角色的记录INSERT INTO t_user (username, password, real_name, phone, role, status) VALUES (admin, MD5(123456), 系统管理员, 13800000000, 2, 1), (lawyer1, MD5(123456), 张律师, 13800000001, 1, 1), (user1, MD5(123456), 测试用户, 13800000002, 0, 1);注意密码用 MD5 函数加密存储这是这类 Java 模板项目的惯例。如果你后端的登录逻辑用的是 BCrypt 而不是 MD5这段初始化脚本要对应调整否则登录时密码永远比对不上。判断方法很简单看实体类里密码字段的长度或者看后端代码里有没有引入 spring-security-crypto 依赖。3.3 多表联查与索引咨询列表页背后的三句 SQL单表 CRUD 用 MyBatis-Plus 的 BaseMapper 就能搞定但咨询列表页要展示提问人姓名、接单律师姓名和当前状态这些信息分散在 t_consultation、t_user、t_lawyer 三张表里必须手写联查 SQL。这类 SQL 是评估开发者数据库功底的地方也是这个项目 Mapper XML 里最值得读的部分。典型的咨询列表查询长这样SELECT c.id, c.title, c.content, c.status, c.create_time, u.real_name AS asker_name, l.name AS lawyer_name FROM t_consultation c LEFT JOIN t_user u ON c.user_id u.id LEFT JOIN t_lawyer l ON c.lawyer_id l.id ORDER BY c.create_time DESC;这里用 LEFT JOIN 而不是 INNER JOIN 是刻意的咨询记录在律师还没接单时 lawyer_id 是空的INNER JOIN 会把这些记录过滤掉而业务上管理员恰恰需要看到「待分配」状态的记录所以必须用 LEFT JOIN。同理user_id 理论上不会为空但如果用户被删除了LEFT JOIN 也能保证咨询记录不丢。联查表一多性能就要靠索引兜底。外键字段必须建索引不然数据量过万后联查会全表扫描。经验上t_consultation 表要加两个索引一个给 user_id一个给 lawyer_id状态字段如果经常做条件查询也可以加一个普通索引ALTER TABLE t_consultation ADD INDEX idx_user_id (user_id); ALTER TABLE t_consultation ADD INDEX idx_lawyer_id (lawyer_id); ALTER TABLE t_consultation ADD INDEX idx_status (status);索引不是越多越好写多读少的表加太多索引反而拖慢插入速度。这个项目的业务特点是读多写少咨询、预约这种核心表的查询条件字段建索引就够了不要每列都加。用 EXPLAIN 关键字可以验证索引是否生效——如果 type 列是 ALL说明还在全表扫描索引没建对或者 SQL 写法有问题。4. 本地跑通全流程从 JDK 环境到前后端同时启动跑通这个项目是大多数人拿到压缩包后的首要目标也是翻车最集中的环节。按我的经验只要遵守「版本对齐、先库后端、后端先行」三个原则大部分问题都能提前规避。版本对齐指 JDK、Maven、MySQL、Node 的版本要和项目依赖匹配先库后端指先导入数据库再启动后端后端先行指先把后端 8080 跑起来确认接口能返回数据再启动前端页面。4.1 环境准备JDK、Maven、MySQL 的版本怎么匹配先检查本机环境打开命令行窗口依次执行下面四条命令缺哪个补哪个java -version mvn -v mysql --version node -v这套系统的常规要求是 JDK 1.8 或 JDK 11、Maven 3.6 以上、MySQL 5.7 或 8.0、Node 14 以上。JDK 版本尤其关键——如果项目用的是 Spring Boot 2.xJDK 17 可能编译报错因为某些依赖的字节码版本不兼容如果项目是 Spring Boot 3.x那就必须配 JDK 17。压缩包里的说明文档一般会写明版本要求你解压后先看文档里的环境说明别急着开 IDE。MySQL 版本影响的是驱动类名和连接参数。MySQL 5.7 用 com.mysql.jdbc.DriverMySQL 8.0 必须用 com.mysql.cj.jdbc.Driver连接串里还需要带 serverTimezone 参数否则会报时区相关的异常。如果你本机装的是 MySQL 8.0而项目配置写的是 MySQL 5.7 驱动最常见的报错是 ClassNotFoundException 或 Communications link failure这时候去改 pom.xml 里的 mysql-connector-java 版本到 8.0 系列即可。4.2 后端启动修改数据源配置并用 Maven 跑起来环境就绪后用 IDEIDEA 或 Eclipse导入后端工程。导入时选择 Maven 项目等待依赖下载完成这个过程在网络状况差的时候可能要十几分钟。依赖拉完后第一步不是点运行而是打开 src/main/resources/application.yml 修改数据源配置server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/legal_aid?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalse username: legal_user password: Legal123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath:mapper/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl配置里有三个点容易踩坑。第一url 里的 characterEncoding 要写 utf8mb4 而不是 utf8否则中文写入可能乱码serverTimezone 必须写MySQL 8.0 不指定时区会直接报错。第二username 和 password 要和你第 3 章创建的数据库账号一致如果你直接用 root那就要确认 root 的密码。第三mybatis-plus 的 log-impl 配置开启 SQL 日志打印跑起来后控制台能看到每条 SQL这是后面排查问题最有力的工具。配置改完直接运行启动类里带 SpringBootApplication 注解的 main 方法或者用 Maven 命令启动mvn clean package -DskipTests java -jar target/legal-aid-0.0.1-SNAPSHOT.jar启动成功的标志是控制台出现 Tomcat started on port(s): 8080 之类的日志。如果启动失败优先看控制台前三十行里有没有红色异常堆栈特别是 Caused by 部分那里才是真正的原因。最常见的启动失败是数据库连不上错误信息里会明确写 Access denied 或 Communications link failure回到第 3 章检查账号权限和 MySQL 服务状态。4.3 前端启动npm 安装依赖与接口地址对齐后端跑通后启动前端。进入前端目录先看有没有 package.json这是前端工程的标志。然后执行安装和启动命令npm install npm run servenpm install 的时间取决于网络和依赖数量Vue 2 Element UI 的项目依赖通常有几百 MB装完后再启动。启动成功的标志是控制台输出 App running at 和 Local: http://localhost:3000 这样的地址。浏览器打开这个地址如果看到登录页说明前端框架跑起来了。接下来验证前后端是否打通。在浏览器登录页面随便输入账号密码提交然后按 F12 打开开发者工具切到 Network 面板看发出的请求是 200 还是 404、500。如果请求 404多半是接口地址对不上检查前端 api 目录里封装的基础路径和后端 Controller 的路由前缀是否一致如果请求 500切到后端控制台看异常堆栈。这里要特别提一下前后端联调时的接口地址问题前端项目里一般会把所有请求封装在一个 request.js 或 axios.js 文件里里面定义了 baseURL这个值要和开发服务器配的转发规则对齐否则请求根本到不了后端。页面能登录、能打开列表、数据能正常显示这套系统就算跑通了。跑通之后别急着关把登录、查看咨询列表、提交一条测试咨询这几个动作在页面上完整走一遍顺带在后端控制台观察打印的 SQL你会对这个项目的数据流转建立直观认识——这比看十遍代码都管用。5. 避坑新手跑这个项目最常见的 5 个翻车现场这章全是血泪经验。我在帮别人排查这类 Java 模板项目时遇到的高频问题高度集中在这五个场景。每一条都按「现象 → 原因 → 解决」的顺序写你可以把这章当成排错手册遇到问题时直接对号入座。5.1 数据库连不上Access denied 与时区报错现象后端启动时控制台报 Access denied for user legal_userlocalhost或者报 The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。原因Access denied 是账号或密码不对常见于初始化脚本里建的账号密码和后端配置文件里写的不一致或者 SQL 脚本里 GRANT 语句没执行成功。时区报错是 MySQL 8.0 的已知问题8.0 要求客户端显式指定时区否则服务端返回的时区名无法解析。解决Access denied 先用命令行手动登录验证账号密码mysql -ulegal_user -p能登进去就说明数据库侧没问题问题在配置文件登不进去就用 root 重新执行建号授权脚本。时区问题在连接 URL 后面加上 serverTimezoneAsia/Shanghai 即可这是最稳妥的解决办法不要在 MySQL 全局配置里改时区那样会影响这台机器上其他项目。5.2 8080 端口被占用启动即失败现象后端启动不到两秒就退出控制台提示 Web server failed to start. Port 8080 was already in use。原因本机已有其他进程占用了 8080 端口可能是之前启动过没关掉的后端进程也可能是其他软件占用了 8080。端口监听失败后 Spring Boot 默认直接终止启动不会自动换端口。解决先找到占用进程。Windows 下执行 netstat -ano | findstr 8080Linux 或 Mac 下执行 lsof -i:8080拿到占用的 PID 后用任务管理器或 kill 命令结束它。如果你不想动那个进程也可以改 application.yml 里 server.port 改为 8081改完记得前端转发配置里的目标地址也要同步改否则前后端还是对不上。5.3 接口通了但页面拿不到数据跨域与拦截器现象前端页面能打开但列表数据为空开发者工具 Network 面板里看到请求是 200Response 里却没有数据或者请求直接在 Console 里报 CORS error。原因200 但没数据十有八九是后端接口返回的 JSON 结构里 data 字段为空前端解析时拿错字段CORS error 才是真正的前后端跨域问题——前端工程和后端工程的端口不同浏览器按同源策略拦截了响应。另一个高频原因是后端有登录拦截器前端请求头里没带 token接口被拦下来返回 401 或自定义错误码前端拿到后没做处理就直接丢弃了。解决先分清是哪一种。看后端控制台如果拦截器日志有输出说明请求到达了后端但被拦截去前端检查登录后 token 是否存储并在请求拦截器里注入到了 header。如果是 CORS检查后端有没有加跨域配置——Spring Boot 里常见做法是写一个 WebMvcConfigurer 配置类allowOrigin、allowMethods、allowHeaders 三个参数都要用开发环境允许的宽松值别在生产配置里照抄。5.4 中文乱码三处编码设置缺一不可现象页面上显示的中文是问号或者乱码数据库里读出来的中文也是乱码但命令行里查 SQL 结果却是正常的。原因编码问题在这类系统里是三层叠加的。第一层是数据库字符集建库时如果没指定 utf8mb4默认可能是 latin1第二层是数据库连接的编码参数连接 URL 里没带 characterEncodingUTF-8第三层是后端响应编码Spring Boot 的 server.servlet.encoding 配置不对。三层里只要有一层不对中文就可能在某个环节变成乱码。解决按顺序排查。第一步确认数据库字符集执行 SHOW CREATE DATABASE legal_aid看到不是 utf8mb4 就用 ALTER DATABASE legal_aid CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci 修改。第二步检查 application.yml 的连接 URL 是否带 characterEncodingutf8mb4。第三步在后端配置里显式指定响应编码在 application.yml 加上 server.servlet.encoding.forcetrue 和 charsetUTF-8。这三处都对齐后把已存在的乱码数据删掉重插因为改字符集不会修复已经存坏的记录。5.5 启动后 404静态资源路径与接口前缀对不上现象前端页面正常但点击任何按钮请求接口都返回 404后端控制台没有任何日志输出。原因404 且后端无日志说明请求根本没到达后端工程是路径错了。这类项目里前端请求一般统一带 /api 前缀后端 Controller 的 RequestMapping 却不一定带这个前缀两者对不上时就会出现前端请求 /api/consultation/list后端却只监听 /consultation/list差了 /api 这一段。解决打开前端 api 目录下的请求封装文件看 baseURL 是什么再打开后端 Controller 类看类级别的 RequestMapping 注解。如果前端 baseURL 是 /api后端 Controller 是 /consultation那前端发出的 /api/consultation 请求就 404。解决办法有两个方向要么在前端转发规则里做路径重写把 /api 前缀剥掉再转发到后端要么在后端所有 Controller 类上统一加 /api 前缀。改之前先确认项目模板原本是怎么设计的跟着原设计走别按自己的习惯改——这类项目的前后端约定是打包提供的乱改会踩更多坑。6. 进阶加一个「咨询统计」功能并验证整个链路项目跑通只是起点真正值钱的是你能在这个项目上做增量。我建议你拿「咨询统计」练手统计每个律师的接单数和平均回复时长这是这类系统的常见报表需求也是面试官喜欢问的场景。实现路径是从数据库到后端再到前端完整走一遍 CRUD 之外的业务逻辑链路。第一步写统计 SQL按律师分组统计接单量并计算平均回复耗时SELECT l.name AS lawyer_name, COUNT(c.id) AS total_count, AVG(TIMESTAMPDIFF(MINUTE, c.create_time, c.reply_time)) AS avg_reply_minutes FROM t_lawyer l LEFT JOIN t_consultation c ON c.lawyer_id l.id WHERE c.status 2 GROUP BY l.id, l.name;第二步在后端加一个统计接口Controller 里定义路由Service 里执行上面的 SQL把结果封装成 JSON 返回。第三步把前端一个空白页改成统计展示页用表格渲染返回数据。这个练手任务虽然没有复杂算法但它覆盖了「新功能从数据库到页面的完整落地方案」做完你会发现项目的骨架已经被你看透了。功能加完要用工具验证接口是否可用不需要依赖前端页面用 curl 就能做冒烟测试curl -X POST http://localhost:8080/api/user/login \ -H Content-Type: application/json \ -d {username:admin,password:123456}把返回结果里的 token 截取出来再带着 token 请求统计接口curl -H Authorization: Bearer token \ http://localhost:8080/api/consultation/statistics如果这两个接口都返回预期的 JSON 数据说明后端整条链路是通的。我现在每次拿到新项目都习惯先做一遍「登录 → 核心列表 → 新增一条数据 → 验证列表刷新」的冒烟测试再开始读源码——这套动作用不了五分钟但能帮你把项目是否健康、环境是否对齐一次摸清省掉后面大量排查的功夫。希望帮到你。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑