简介：这是一份面向Java Web初学者的毕业设计项目，实现法律援助与咨询系统的完整前后端功能。前台提供站内新闻、在线留言、用户注册、系统公告与在线申请援助等模块，后台涵盖系统用户、用户信息、法律咨询、站内新闻、援助申请及系统公告的管理，注册用户还可修改资料并跟踪自己的援助申请。项目基于JSP+Servlet技术，搭配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 接收前端请求并返回 JSON，Service 写业务逻辑，Mapper 操作数据库，实体类对应每张表。以咨询提交流程为例，用户在前端点「提交咨询」，前端把标题和内容 POST 到 /api/consultation，Controller 接到参数后交给 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_user'@'localhost' IDENTIFIED BY 'Legal@123456'; GRANT ALL PRIVILEGES ON legal_aid.* TO 'legal_user'@'localhost'; 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.x，JDK 17 可能编译报错，因为某些依赖的字节码版本不兼容；如果项目是 Spring Boot 3.x，那就必须配 JDK 17。压缩包里的说明文档一般会写明版本要求，你解压后先看文档里的环境说明，别急着开 IDE。
MySQL 版本影响的是驱动类名和连接参数。MySQL 5.7 用 com.mysql.jdbc.Driver，MySQL 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 跑起来
环境就绪后，用 IDE（IDEA 或 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?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false username: legal_user password: Legal@123456 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_user'@'localhost'，或者报 The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。
原因：Access denied 是账号或密码不对，常见于初始化脚本里建的账号密码和后端配置文件里写的不一致，或者 SQL 脚本里 GRANT 语句没执行成功。时区报错是 MySQL 8.0 的已知问题，8.0 要求客户端显式指定时区，否则服务端返回的时区名无法解析。
解决：Access denied 先用命令行手动登录验证账号密码，mysql -ulegal_user -p，能登进去就说明数据库侧没问题，问题在配置文件；登不进去就用 root 重新执行建号授权脚本。时区问题在连接 URL 后面加上 &serverTimezone=Asia/Shanghai 即可，这是最稳妥的解决办法，不要在 MySQL 全局配置里改时区，那样会影响这台机器上其他项目。
5.2 8080 端口被占用：启动即失败
现象：后端启动不到两秒就退出，控制台提示 Web server failed to start. Port 8080 was already in use。
原因：本机已有其他进程占用了 8080 端口，可能是之前启动过没关掉的后端进程，也可能是其他软件占用了 8080。端口监听失败后 Spring Boot 默认直接终止启动，不会自动换端口。
解决：先找到占用进程。Windows 下执行 netstat -ano | findstr 8080，Linux 或 Mac 下执行 lsof -i:8080，拿到占用的 PID 后用任务管理器或 kill 命令结束它。如果你不想动那个进程，也可以改 application.yml 里 server.port 改为 8081，改完记得前端转发配置里的目标地址也要同步改，否则前后端还是对不上。
5.3 接口通了但页面拿不到数据：跨域与拦截器
现象：前端页面能打开，但列表数据为空，开发者工具 Network 面板里看到请求是 200，Response 里却没有数据；或者请求直接在 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 里没带 characterEncoding=UTF-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 是否带 characterEncoding=utf8mb4。第三步在后端配置里显式指定响应编码，在 application.yml 加上 server.servlet.encoding.force=true 和 charset=UTF-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 数据，说明后端整条链路是通的。我现在每次拿到新项目，都习惯先做一遍「登录 → 核心列表 → 新增一条数据 → 验证列表刷新」的冒烟测试，再开始读源码——这套动作用不了五分钟，但能帮你把项目是否健康、环境是否对齐一次摸清，省掉后面大量排查的功夫。希望帮到你。
本文还有配套的精品资源，点击获取