这个标题给得很长拆开看其实就是三句话做一个微信小程序端的法律咨询系统后端用 Java 写既能在线答疑也能沉淀知识库。项目名字里反复出现的“法律服务咨询与互助平台”和“律师在线答疑与法律知识库系统”对应的是同一个项目的不同侧重点设计时把这三句话合并成一张需求图落地工作量就不会散。这个项目适合两类人参考一类是做毕业设计想选“小程序Java”方向的同学另一类是刚学完 Spring Boot 想找一个完整业务练手的新手开发者。网上很多教程只给你一个简单的 CRUD而这个题目天然自带用户、律师、管理员三种角色有身份认证、内容审核、消息通知、搜索匹配这些真实业务要素做完之后简历上能写的东西会厚实很多。下面我从需求拆解、技术选型、数据库设计、后端业务逻辑、小程序端交互到踩坑记录完整过一遍实现思路。全程按我实际带项目的方式来讲不绕弯子只讲能落地的。1. 需求拆解这个系统到底要做什么1.1 三类角色与核心功能边界先不要急着写代码把角色摆清楚。法律咨询这件事线下场景是“用户提问、律师回答、平台做撮合”搬到小程序上以后核心角色就是普通用户、律师、平台管理员。普通用户要做的事很明确注册登录、浏览法律知识库、发布自己的法律问题、查看律师回答、收藏有用内容。这里面“互助”体现在哪里我一般建议系统允许普通用户对问题发表简短的经验分享但是普通用户的回答不带“律师认证”标识权威性明显弱于律师回答这样既保留互助氛围又不至于让非专业回答误导别人。律师角色要单独设计一套入驻审核流程。用户提交入驻申请时要填真实姓名、律师执业证号、执业机构、擅长领域、个人简介管理员在后台审核通过后才拥有“律师”身份。律师进入答疑页面后可以按自己的擅长领域筛选问题填写专业回答回答内容会以较高权重展示给提问用户。管理员是容易被忽略但又必须有的角色。问题需要审核律师资质需要审核知识库文章需要编辑和上下架再加上查看用户数、问题数、回答数这样的基础统计。哪怕毕业设计里的管理后台做简单一点这三类用户也缺一不可否则“系统”就变成单机问答工具了。1.2 功能模块清单与优先级我习惯用优先级来梳理需求免得做到一半被各种小功能拖住节奏。下面这张表基本就是整个系统的功能边界P0 是第一阶段必须完成的P1 是时间充裕再补的。模块功能点角色优先级登录认证微信登录、token 鉴权用户/律师P0法律咨询发布问题、问题列表、问题详情用户P0在线答疑律师回答、回答列表律师P0知识库文章列表、文章详情、搜索用户P0互助评论普通用户经验分享、评论用户P1律师入驻提交资料、后台审核用户/管理员P0个人中心我的提问、我的回答、我的收藏用户/律师P1管理后台内容审核、用户管理、数据统计管理员P1我见过不少同学一上来就加点赞、评论、积分、排行榜结果核心问答链路还没走通这种优先级划分是踩过坑以后留下的习惯。先把 P0 做完系统已经能演示出“提问—答疑—知识库”的完整闭环。2. 技术选型与项目结构设计2.1 为什么选 Spring Boot MyBatis-Plus 原生小程序后端选 Spring Boot 基本是毕业设计的主流标准不是因为它多炫而是因为生态成熟、资料多、部署简单。配上 MyBatis-Plus 之后单表 CRUD 几乎不用手写 SQL这对压缩开发周期非常关键。数据库用 MySQL缓存和消息通知这种场景一般不会太复杂毕业设计用不上重型的中间件别给自己加戏。小程序端我建议直接用原生微信小程序而不是 uni-app。原因很现实这个项目要演示的核心是业务逻辑和微信生态对接原生小程序对 wx.login、wx.request、模板消息这些 API 支持最直接调试也最方便。如果你以后想同时打包成 App 或 H5换 uni-app 是另一套分支但就当前这个毕业设计题目来看原生足够。前端管理后台可以不用做太复杂。课程设计或者毕业设计如果时间紧可以直接写一个简单的 Vue Element UI 页面或者干脆在项目里放一个单独的管理端 Web 模块。我这里默认你后端拆成两个入口小程序 API 服务和管理后台 API 服务共用一套 Java 工程只是接口路径和权限不同。2.2 后端工程结构与统一返回格式工程结构我建议按功能分包而不是按技术类型分包。具体区别是不要搞出 controller / service / mapper 三个大包然后全部往里塞而是按 user、question、lawyer、knowledge 这些业务模块分包。这样项目后面扩展维护会爽很多。com.example.law ├── common // 统一返回、异常处理、工具类 ├── config // 拦截器、Web 配置、微信配置 ├── controller // 接口入口 │ ├── UserController │ ├── QuestionController │ ├── AnswerController │ └── KnowledgeController ├── service // 业务逻辑 ├── mapper // MyBatis-Plus Mapper ├── entity // 数据库实体 └── dto // 接口入参出参统一返回格式是一开始就要定死的规矩否则后面联调小程序端会非常痛苦。我的习惯是后端所有接口都返回同一个结构{ code: 200, message: success, data: {} }错误时 code 返回非 200message 放错误描述。小程序端只需要封装一次请求统一处理 code不用每个接口单独判断。后端对应一个 Result 类再配一个全局异常处理器把业务异常和未知异常分别处理问题回答状态不对、参数校验失败这一类错误都能稳定返回给前端。3. 数据库设计核心表结构与关系说明3.1 用户、律师、问题的表设计数据库设计这一步直接决定后面写代码的时候是顺滑还是拧巴。我建表有个原则先确定核心业务主链路再根据主链路拆表。主链路是“用户登录—用户提问—律师回答—知识库文章”所以核心表是 user、question、answer、knowledge_article。用户和律师的关系是一对一扩展不建议拆成两张平行表而是在 user 表上增加角色字段再用 lawyer_profile 表存律师专用信息。user 表设计如下CREATE TABLE user ( id int(11) unsigned NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(50) DEFAULT COMMENT 昵称, avatar varchar(255) DEFAULT COMMENT 头像, phone varchar(20) DEFAULT COMMENT 联系电话, role 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), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;question 表是提问业务的核心。关键字段是 user_id、category_id、title、content、is_anonymous、status。CREATE TABLE question ( id int(11) unsigned NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL COMMENT 提问用户ID, category_id int(11) NOT NULL COMMENT 法律领域分类ID, title varchar(100) NOT NULL COMMENT 问题标题, content text NOT NULL COMMENT 问题描述, is_anonymous tinyint(1) DEFAULT 0 COMMENT 是否匿名 0否 1是, status tinyint(1) DEFAULT 0 COMMENT 0待回答 1已回答, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status 字段是最容易被忽略的但它的价值很大。提问之后状态是“待回答”律师一旦回答状态立刻变成“已回答”小程序端可以根据这个字段判断是否显示“我来回答”按钮。这个字段撑起了整个答疑链路的状态流转。3.2 知识库与多表关联设计知识库、分类、收藏这三块属于内容体系。知识分类单独建一张 category 表question 和 knowledge_article 都通过 category_id 关联以后做首页分类筛选就很方便不用写死条件。answer 表要同时记录问题 ID 和回答人 ID。回答人可能是律师也可能是普通用户所以加一个 user_type 字段用于判断回答者身份。回答的“权威性”就靠这个字段区分律师回答在展示时多显示一个认证标签。knowledge_article 表我一般会加 source 字段记录文章来源recom_flag 标记是否在首页推荐。搜索功能不需要单独建搜索服务后端用简单的 title/content 模糊查询 分类筛选就能满足毕业设计演示需求没必要上全文搜索引擎。4. 后端核心业务逻辑实现4.1 小程序登录与 token 鉴权机制微信小程序登录是整个系统的入口很多同学在这里第一次翻车。典型错误是把 appid 和 secret 直接写进小程序前端代码这是绝对不能做的事。正确的流程是小程序端 wx.login 获取临时 code小程序把 code 传给后端后端拿 code 加上 appid、secret 去微信接口换 openid后端查库找到或创建用户后端生成 token 返回给小程序小程序后续请求在 header 里带 tokentoken 我习惯用 JWT理由很直接Spring Boot 对 JWT 的支持很成熟用户信息放进 token后端用拦截器统一解析不需要依赖 Session更符合前后端分离的思路。JWT 的有效期设置为 7 天小程序端在 401 响应时自动跳转重新登录。String openid wechatService.getOpenid(code); User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getOpenid, openid)); if (user null) { user new User(); user.setOpenid(openid); user.setRole(0); userMapper.insert(user); } String token JwtUtil.createToken(user.getId(), user.getRole());登录接口返回 token 和用户信息小程序端把 token 存到 storage。这里提醒一下JWT 密钥不要硬编码在代码里可以放到 application.yml 配置文件中答辩时老师如果问配置管理这就是一个加分回答。4.2 提问—回答—消息通知的完整链路提问接口要做的事情不是单纯的 insert而是要把整条链路打通。用户提交问题后后端需要做三件事写入 question 表、根据 question 的状态字段标记“待回答”、在律师端待答列表里暴露这条新问题。我实际开发时还会在 service 层加一个敏感词过滤。法律咨询平台上用户问题里偶尔会出现不合适的表达毕业设计不需要上复杂的算法一个简单的敏感词工具类就够了命中敏感词就打回提示修改。这一步虽然小但答辩时讲出来很加分因为这说明你考虑了内容安全。律师回答接口是核心中的核心。律师进入待答问题列表点击某个问题进入详情页看到用户描述后编辑回答内容提交。后端收到回答请求后先校验当前用户角色是否为律师再校验问题状态是否为“待回答”防止一题多答或者非律师回答。然后插入 answer 记录同时把 question.status 更新为“已回答”。用户提交问题 - 问题状态置为待回答 - 律师按分类刷新待答列表 - 律师提交回答 - 插入answer记录 - 更新question状态为已回答 - 生成站内消息通知提问用户站内消息通知是很多同学会遗漏的设计。我在 message 表里记录一条消息内容包括通知对象、相关业务 ID、消息类型和是否已读。用户打开“我的消息”时就能看到“你的问题收到新的律师回答”。如果时间充裕还可以接入小程序的订阅消息推送但毕业设计阶段站内信已经足够完整。4.3 知识库搜索与首页聚合接口知识库功能相对简单就是要做好搜索和分类筛选。后端接口接受 keyword 和 categoryId 两个参数keyword 做标题和内容的模糊查询categoryId 做精确筛选。然后统一按发布时间排序。更好的做法是给阅读量加一个 read_count 字段每次点击详情自增一次首页知识库推荐默认按阅读量排序。首页需要同时展示推荐问题、推荐律师、知识库热门文章我一般单独写一个聚合接口返回首页所需的全部数据小程序端只调一次接口就把首页渲染出来。避免前端多次请求导致页面加载慢也避免答辩演示时因为网络闪断而出丑。5. 小程序端页面与交互实现5.1 页面架构与底部导航规划小程序端页面结构直接对应功能模块。底部 tabBar 我建议配四个入口首页、问答、知识库、我的。这样用户能快速触达核心功能页面层级也清晰。首页推荐律师、热门问题、知识库入口问答问题列表、问题详情、我要提问知识库文章分类、文章列表、文章详情、搜索我的个人中心、我的提问、我的回答、我的收藏、律师入驻问答页承载的是核心互动场景可以默认列出所有问题列表顶部加分类筛选 tab点进问题详情后能看到普通用户的经验分享和律师专业回答两类回答在 UI 上要能区分开。我通常会建议在律师回答区域加一个金色“律师认证”角标这种细节能让演示效果提升不少。5.2 请求封装、登录态维护与关键页面实现小程序端写接口请求时一定要做统一封装。我习惯在 utils 下建一个 request.js把 wx.request 包成 Promise统一设置请求头、统一处理错误码和 401 跳转。const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.message, icon: none }); } }, fail: (err) { reject(err); } }); }); };提问页面用一个表单页承载标题输入框、问题描述 textarea、领域分类 picker、匿名发布 switch。提交时校验标题不能为空、描述不能小于 10 个字。这里要注意的是如果用户选了匿名提交给后端的 user_id 仍然要保留只是展示层把昵称换成“匿名用户”。真实用户 ID 不能丢律师还是需要知道回答给谁但问题列表和详情页不泄露身份。律师端答疑入口放在“我的”页面审核通过的律师可以看到“待答问题”列表点击进入写出回答。这个页面的关键是仅展示当前律师擅长领域分类下的问题并且把已经回答过的问题过滤掉不然列表会越攒越长。6. 常见问题与踩坑记录6.1 登录、鉴权与用户角色相关的坑微信登录这块我见过最多的报错是 code 无效。原因是 wx.login 返回的 code 只能用一次前端如果重复调用 wx.login后面的接口就会拿到失效的 code后端换不来 openid。解决方法是每次登录流程只调一次 wx.login拿到 code 后立刻传给后端不要在多个页面反复触发登录。角色判断也是一个容易踩坑的地方。用户注册时默认 role 是普通用户律师入驻审核通过后 role 才变为律师。有同学把角色信息直接写死在用户表结果管理员在后台修改了角色前端还显示旧身份这是因为没有让用户信息接口每次都从数据库读最新角色。解决方案是登录后重新请求用户信息接口而不是用缓存里的旧数据。还有 token 过期的问题。如果后端返回 401小程序端只是弹出“登录已过期”却没有清理本地 token 和跳转登录页用户就会被卡在原地。统一请求封装中一定要有 401 的全局处理。6.2 数据库、部署与演示相关的问题数据库字符集必须用 utf8mb4这一点很多同学会忽略。用户昵称里经常有表情符号utf8 会报错只有 utf8mb4 才能存下来。建库的时候直接指定默认字符集不要在项目做到一半再改否则迁移数据很麻烦。部署方面小程序后端接口必须是 HTTPS 地址而且要提前在微信公众平台配置服务器域名。开发阶段可以在开发者工具中关闭域名校验但体验版和预览版必须走正式域名。我建议答辩前至少预留一天时间处理域名备案和证书问题否则本地跑得好好的一上体验版接口全部不通。演示时有三类账号会稳妥很多一个普通用户账号、一个已审核律师账号、一个管理员账号。演示顺序可以这样走普通用户发布一条问题切换律师账号回答这个问题再切换普通用户看到回答最后到管理员后台审核一条内容。这样整个业务闭环一次走完比零散演示各个页面要有说服力得多。我个人在带项目时的体会是这个题目的难点不在技术而在于“能不能把流程讲清楚”。只要做到角色清晰、状态流转明确、用户看得见律师认证信息、知识库能搜能点答辩老师基本不会为难你。最后再分享一个小技巧所有接口返回的时间字段后端统一处理成格式化字符串返回给小程序不要把小程序的格式化逻辑写得到处都是省下来的时间足够你把答辩演示练熟三遍。
这个标题给得很长拆开看其实就是三句话做一个微信小程序端的法律咨询系统后端用 Java 写既能在线答疑也能沉淀知识库。项目名字里反复出现的“法律服务咨询与互助平台”和“律师在线答疑与法律知识库系统”对应的是同一个项目的不同侧重点设计时把这三句话合并成一张需求图落地工作量就不会散。这个项目适合两类人参考一类是做毕业设计想选“小程序Java”方向的同学另一类是刚学完 Spring Boot 想找一个完整业务练手的新手开发者。网上很多教程只给你一个简单的 CRUD而这个题目天然自带用户、律师、管理员三种角色有身份认证、内容审核、消息通知、搜索匹配这些真实业务要素做完之后简历上能写的东西会厚实很多。下面我从需求拆解、技术选型、数据库设计、后端业务逻辑、小程序端交互到踩坑记录完整过一遍实现思路。全程按我实际带项目的方式来讲不绕弯子只讲能落地的。1. 需求拆解这个系统到底要做什么1.1 三类角色与核心功能边界先不要急着写代码把角色摆清楚。法律咨询这件事线下场景是“用户提问、律师回答、平台做撮合”搬到小程序上以后核心角色就是普通用户、律师、平台管理员。普通用户要做的事很明确注册登录、浏览法律知识库、发布自己的法律问题、查看律师回答、收藏有用内容。这里面“互助”体现在哪里我一般建议系统允许普通用户对问题发表简短的经验分享但是普通用户的回答不带“律师认证”标识权威性明显弱于律师回答这样既保留互助氛围又不至于让非专业回答误导别人。律师角色要单独设计一套入驻审核流程。用户提交入驻申请时要填真实姓名、律师执业证号、执业机构、擅长领域、个人简介管理员在后台审核通过后才拥有“律师”身份。律师进入答疑页面后可以按自己的擅长领域筛选问题填写专业回答回答内容会以较高权重展示给提问用户。管理员是容易被忽略但又必须有的角色。问题需要审核律师资质需要审核知识库文章需要编辑和上下架再加上查看用户数、问题数、回答数这样的基础统计。哪怕毕业设计里的管理后台做简单一点这三类用户也缺一不可否则“系统”就变成单机问答工具了。1.2 功能模块清单与优先级我习惯用优先级来梳理需求免得做到一半被各种小功能拖住节奏。下面这张表基本就是整个系统的功能边界P0 是第一阶段必须完成的P1 是时间充裕再补的。模块功能点角色优先级登录认证微信登录、token 鉴权用户/律师P0法律咨询发布问题、问题列表、问题详情用户P0在线答疑律师回答、回答列表律师P0知识库文章列表、文章详情、搜索用户P0互助评论普通用户经验分享、评论用户P1律师入驻提交资料、后台审核用户/管理员P0个人中心我的提问、我的回答、我的收藏用户/律师P1管理后台内容审核、用户管理、数据统计管理员P1我见过不少同学一上来就加点赞、评论、积分、排行榜结果核心问答链路还没走通这种优先级划分是踩过坑以后留下的习惯。先把 P0 做完系统已经能演示出“提问—答疑—知识库”的完整闭环。2. 技术选型与项目结构设计2.1 为什么选 Spring Boot MyBatis-Plus 原生小程序后端选 Spring Boot 基本是毕业设计的主流标准不是因为它多炫而是因为生态成熟、资料多、部署简单。配上 MyBatis-Plus 之后单表 CRUD 几乎不用手写 SQL这对压缩开发周期非常关键。数据库用 MySQL缓存和消息通知这种场景一般不会太复杂毕业设计用不上重型的中间件别给自己加戏。小程序端我建议直接用原生微信小程序而不是 uni-app。原因很现实这个项目要演示的核心是业务逻辑和微信生态对接原生小程序对 wx.login、wx.request、模板消息这些 API 支持最直接调试也最方便。如果你以后想同时打包成 App 或 H5换 uni-app 是另一套分支但就当前这个毕业设计题目来看原生足够。前端管理后台可以不用做太复杂。课程设计或者毕业设计如果时间紧可以直接写一个简单的 Vue Element UI 页面或者干脆在项目里放一个单独的管理端 Web 模块。我这里默认你后端拆成两个入口小程序 API 服务和管理后台 API 服务共用一套 Java 工程只是接口路径和权限不同。2.2 后端工程结构与统一返回格式工程结构我建议按功能分包而不是按技术类型分包。具体区别是不要搞出 controller / service / mapper 三个大包然后全部往里塞而是按 user、question、lawyer、knowledge 这些业务模块分包。这样项目后面扩展维护会爽很多。com.example.law ├── common // 统一返回、异常处理、工具类 ├── config // 拦截器、Web 配置、微信配置 ├── controller // 接口入口 │ ├── UserController │ ├── QuestionController │ ├── AnswerController │ └── KnowledgeController ├── service // 业务逻辑 ├── mapper // MyBatis-Plus Mapper ├── entity // 数据库实体 └── dto // 接口入参出参统一返回格式是一开始就要定死的规矩否则后面联调小程序端会非常痛苦。我的习惯是后端所有接口都返回同一个结构{ code: 200, message: success, data: {} }错误时 code 返回非 200message 放错误描述。小程序端只需要封装一次请求统一处理 code不用每个接口单独判断。后端对应一个 Result 类再配一个全局异常处理器把业务异常和未知异常分别处理问题回答状态不对、参数校验失败这一类错误都能稳定返回给前端。3. 数据库设计核心表结构与关系说明3.1 用户、律师、问题的表设计数据库设计这一步直接决定后面写代码的时候是顺滑还是拧巴。我建表有个原则先确定核心业务主链路再根据主链路拆表。主链路是“用户登录—用户提问—律师回答—知识库文章”所以核心表是 user、question、answer、knowledge_article。用户和律师的关系是一对一扩展不建议拆成两张平行表而是在 user 表上增加角色字段再用 lawyer_profile 表存律师专用信息。user 表设计如下CREATE TABLE user ( id int(11) unsigned NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(50) DEFAULT COMMENT 昵称, avatar varchar(255) DEFAULT COMMENT 头像, phone varchar(20) DEFAULT COMMENT 联系电话, role 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), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;question 表是提问业务的核心。关键字段是 user_id、category_id、title、content、is_anonymous、status。CREATE TABLE question ( id int(11) unsigned NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL COMMENT 提问用户ID, category_id int(11) NOT NULL COMMENT 法律领域分类ID, title varchar(100) NOT NULL COMMENT 问题标题, content text NOT NULL COMMENT 问题描述, is_anonymous tinyint(1) DEFAULT 0 COMMENT 是否匿名 0否 1是, status tinyint(1) DEFAULT 0 COMMENT 0待回答 1已回答, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_category (category_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;status 字段是最容易被忽略的但它的价值很大。提问之后状态是“待回答”律师一旦回答状态立刻变成“已回答”小程序端可以根据这个字段判断是否显示“我来回答”按钮。这个字段撑起了整个答疑链路的状态流转。3.2 知识库与多表关联设计知识库、分类、收藏这三块属于内容体系。知识分类单独建一张 category 表question 和 knowledge_article 都通过 category_id 关联以后做首页分类筛选就很方便不用写死条件。answer 表要同时记录问题 ID 和回答人 ID。回答人可能是律师也可能是普通用户所以加一个 user_type 字段用于判断回答者身份。回答的“权威性”就靠这个字段区分律师回答在展示时多显示一个认证标签。knowledge_article 表我一般会加 source 字段记录文章来源recom_flag 标记是否在首页推荐。搜索功能不需要单独建搜索服务后端用简单的 title/content 模糊查询 分类筛选就能满足毕业设计演示需求没必要上全文搜索引擎。4. 后端核心业务逻辑实现4.1 小程序登录与 token 鉴权机制微信小程序登录是整个系统的入口很多同学在这里第一次翻车。典型错误是把 appid 和 secret 直接写进小程序前端代码这是绝对不能做的事。正确的流程是小程序端 wx.login 获取临时 code小程序把 code 传给后端后端拿 code 加上 appid、secret 去微信接口换 openid后端查库找到或创建用户后端生成 token 返回给小程序小程序后续请求在 header 里带 tokentoken 我习惯用 JWT理由很直接Spring Boot 对 JWT 的支持很成熟用户信息放进 token后端用拦截器统一解析不需要依赖 Session更符合前后端分离的思路。JWT 的有效期设置为 7 天小程序端在 401 响应时自动跳转重新登录。String openid wechatService.getOpenid(code); User user userMapper.selectOne( new LambdaQueryWrapperUser().eq(User::getOpenid, openid)); if (user null) { user new User(); user.setOpenid(openid); user.setRole(0); userMapper.insert(user); } String token JwtUtil.createToken(user.getId(), user.getRole());登录接口返回 token 和用户信息小程序端把 token 存到 storage。这里提醒一下JWT 密钥不要硬编码在代码里可以放到 application.yml 配置文件中答辩时老师如果问配置管理这就是一个加分回答。4.2 提问—回答—消息通知的完整链路提问接口要做的事情不是单纯的 insert而是要把整条链路打通。用户提交问题后后端需要做三件事写入 question 表、根据 question 的状态字段标记“待回答”、在律师端待答列表里暴露这条新问题。我实际开发时还会在 service 层加一个敏感词过滤。法律咨询平台上用户问题里偶尔会出现不合适的表达毕业设计不需要上复杂的算法一个简单的敏感词工具类就够了命中敏感词就打回提示修改。这一步虽然小但答辩时讲出来很加分因为这说明你考虑了内容安全。律师回答接口是核心中的核心。律师进入待答问题列表点击某个问题进入详情页看到用户描述后编辑回答内容提交。后端收到回答请求后先校验当前用户角色是否为律师再校验问题状态是否为“待回答”防止一题多答或者非律师回答。然后插入 answer 记录同时把 question.status 更新为“已回答”。用户提交问题 - 问题状态置为待回答 - 律师按分类刷新待答列表 - 律师提交回答 - 插入answer记录 - 更新question状态为已回答 - 生成站内消息通知提问用户站内消息通知是很多同学会遗漏的设计。我在 message 表里记录一条消息内容包括通知对象、相关业务 ID、消息类型和是否已读。用户打开“我的消息”时就能看到“你的问题收到新的律师回答”。如果时间充裕还可以接入小程序的订阅消息推送但毕业设计阶段站内信已经足够完整。4.3 知识库搜索与首页聚合接口知识库功能相对简单就是要做好搜索和分类筛选。后端接口接受 keyword 和 categoryId 两个参数keyword 做标题和内容的模糊查询categoryId 做精确筛选。然后统一按发布时间排序。更好的做法是给阅读量加一个 read_count 字段每次点击详情自增一次首页知识库推荐默认按阅读量排序。首页需要同时展示推荐问题、推荐律师、知识库热门文章我一般单独写一个聚合接口返回首页所需的全部数据小程序端只调一次接口就把首页渲染出来。避免前端多次请求导致页面加载慢也避免答辩演示时因为网络闪断而出丑。5. 小程序端页面与交互实现5.1 页面架构与底部导航规划小程序端页面结构直接对应功能模块。底部 tabBar 我建议配四个入口首页、问答、知识库、我的。这样用户能快速触达核心功能页面层级也清晰。首页推荐律师、热门问题、知识库入口问答问题列表、问题详情、我要提问知识库文章分类、文章列表、文章详情、搜索我的个人中心、我的提问、我的回答、我的收藏、律师入驻问答页承载的是核心互动场景可以默认列出所有问题列表顶部加分类筛选 tab点进问题详情后能看到普通用户的经验分享和律师专业回答两类回答在 UI 上要能区分开。我通常会建议在律师回答区域加一个金色“律师认证”角标这种细节能让演示效果提升不少。5.2 请求封装、登录态维护与关键页面实现小程序端写接口请求时一定要做统一封装。我习惯在 utils 下建一个 request.js把 wx.request 包成 Promise统一设置请求头、统一处理错误码和 401 跳转。const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: wx.getStorageSync(token) }, success: (res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.removeStorageSync(token); wx.navigateTo({ url: /pages/login/login }); } else { wx.showToast({ title: res.data.message, icon: none }); } }, fail: (err) { reject(err); } }); }); };提问页面用一个表单页承载标题输入框、问题描述 textarea、领域分类 picker、匿名发布 switch。提交时校验标题不能为空、描述不能小于 10 个字。这里要注意的是如果用户选了匿名提交给后端的 user_id 仍然要保留只是展示层把昵称换成“匿名用户”。真实用户 ID 不能丢律师还是需要知道回答给谁但问题列表和详情页不泄露身份。律师端答疑入口放在“我的”页面审核通过的律师可以看到“待答问题”列表点击进入写出回答。这个页面的关键是仅展示当前律师擅长领域分类下的问题并且把已经回答过的问题过滤掉不然列表会越攒越长。6. 常见问题与踩坑记录6.1 登录、鉴权与用户角色相关的坑微信登录这块我见过最多的报错是 code 无效。原因是 wx.login 返回的 code 只能用一次前端如果重复调用 wx.login后面的接口就会拿到失效的 code后端换不来 openid。解决方法是每次登录流程只调一次 wx.login拿到 code 后立刻传给后端不要在多个页面反复触发登录。角色判断也是一个容易踩坑的地方。用户注册时默认 role 是普通用户律师入驻审核通过后 role 才变为律师。有同学把角色信息直接写死在用户表结果管理员在后台修改了角色前端还显示旧身份这是因为没有让用户信息接口每次都从数据库读最新角色。解决方案是登录后重新请求用户信息接口而不是用缓存里的旧数据。还有 token 过期的问题。如果后端返回 401小程序端只是弹出“登录已过期”却没有清理本地 token 和跳转登录页用户就会被卡在原地。统一请求封装中一定要有 401 的全局处理。6.2 数据库、部署与演示相关的问题数据库字符集必须用 utf8mb4这一点很多同学会忽略。用户昵称里经常有表情符号utf8 会报错只有 utf8mb4 才能存下来。建库的时候直接指定默认字符集不要在项目做到一半再改否则迁移数据很麻烦。部署方面小程序后端接口必须是 HTTPS 地址而且要提前在微信公众平台配置服务器域名。开发阶段可以在开发者工具中关闭域名校验但体验版和预览版必须走正式域名。我建议答辩前至少预留一天时间处理域名备案和证书问题否则本地跑得好好的一上体验版接口全部不通。演示时有三类账号会稳妥很多一个普通用户账号、一个已审核律师账号、一个管理员账号。演示顺序可以这样走普通用户发布一条问题切换律师账号回答这个问题再切换普通用户看到回答最后到管理员后台审核一条内容。这样整个业务闭环一次走完比零散演示各个页面要有说服力得多。我个人在带项目时的体会是这个题目的难点不在技术而在于“能不能把流程讲清楚”。只要做到角色清晰、状态流转明确、用户看得见律师认证信息、知识库能搜能点答辩老师基本不会为难你。最后再分享一个小技巧所有接口返回的时间字段后端统一处理成格式化字符串返回给小程序不要把小程序的格式化逻辑写得到处都是省下来的时间足够你把答辩演示练熟三遍。
