简介一份基于Spring Boot与Vue的法律咨询系统完整项目包面向Java全栈学习者、毕业设计选题学生及律师平台开发者。后端采用Spring Boot 2.7、Spring Security与JWT实现认证授权结合Redis缓存、WebSocket实时通信、MySQL 8.0存储及阿里云OSS文件服务前端由Vue 3与ElementPlus构建覆盖用户端、律师端、管理员端三大场景包含法律咨询、案件管理、知识服务、工作台、数据统计与系统监控等核心功能。压缩包共2006个文件包括1840个Markdown说明文档、87个Java源文件、71个XML配置及1个SQL脚本总大小约166.38MB目录结构可供按模块查阅系统设计、业务逻辑与数据库表结构。已有138人学习适合作为课程设计、毕业设计或商业项目二次开发的参考可帮助快速掌握前后端分离开发、权限控制与实时消息推送等关键实现。1. 法律咨询系统到底在做什么一次在线咨询的完整闭环基于SpringbootVue的法律咨询系统也就是律师在线服务平台解决的核心问题不是把律师简介放到网上而是让一次法律咨询像订单一样可以被追踪和闭环。用户发起咨询、律师接单回复、管理员审核入驻三方角色在同一套数据模型里协作。这类系统最常见的失败方式是照着通用管理后台做了一堆增删改查最后没有状态机、没有消息记录、没有审核联动跑起来才发现业务根本闭不了环。这篇笔记适合准备做毕业设计、接外包或者在公司内部搭类似服务平台的开发者。我直接把我常用的一套模型和实现路径拆开讲先立数据模型再写后端链路接着补前端最后是踩坑记录。整个方案不依赖任何商业组件Spring Boot 提供接口和事务Vue 负责多角色界面数据库用 MySQL 就能跑完整套流程。2. 先把数据模型立住双角色账号与咨询单状态机法律咨询平台最特别的地方在于角色不对称。普通用户是来提问的律师是来接单的管理员是来审核的三拨人看到的数据完全不同。如果一开始没把角色和业务状态在表结构里表达清楚后面每个接口都会被迫写一堆临时判断改一次需求就要动好几个地方。所以建表之前我会先把角色模型和咨询单状态机定死再开始写代码。2.1 用户表与律师档案表为什么用一张认证表加一张扩展表常见的错误设计是给普通用户建一张 user 表给律师单独建一张 lawyer 表。登录认证要写两套逻辑改手机号要改两张表管理员后台查用户也要做两次查询非常别扭。我一般会做成一张 user 认证表加一张 lawyer_profile 扩展表user 表管所有账号的登录状态lawyer_profile 只存律师的执业信息和审核状态。CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT, phone VARCHAR(20) NOT NULL, password VARCHAR(100) NOT NULL, role VARCHAR(20) NOT NULL DEFAULT USER, status TINYINT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE lawyer_profile ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, real_name VARCHAR(50) NOT NULL, licence_no VARCHAR(50) NOT NULL, practice_years INT DEFAULT NULL, specialties VARCHAR(100) DEFAULT NULL, intro VARCHAR(500) DEFAULT NULL, audit_status VARCHAR(20) NOT NULL DEFAULT PENDING, audit_reason VARCHAR(200) DEFAULT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;user 表里 role 字段的取值是 USER、LAWYER、ADMIN 三个常量status 表示账号状态。lawyer_profile 通过 user_id 关联 user 表一个律师账号只能有一条档案记录所以 user_id 建了唯一索引。把角色和档案分开的好处是律师审核不通过时只需要改 lawyer_profile 的 audit_status不会污染认证表的数据用户表也永远不会出现一票 NULL 字段因为普通用户根本没有执业证号。字段含义取值说明user.status账号登录状态0 未激活、1 正常、2 禁用lawyer_profile.audit_status律师资格审核状态PENDING 待审核、APPROVED 已通过、REJECTED 已驳回user.role角色标记USER 普通用户、LAWYER 律师、ADMIN 管理员这里有个关键点要提前说明user.status 决定账号能不能登录lawyer_profile.audit_status 决定律师能不能接单两个状态是独立的。审核通过时要把 user.status 从 0 改成 1驳回时保持 0这个联动关系很多初版代码都没处理好后面避坑章节我会专门展开。2.2 咨询单状态机四个状态、四类流转规则咨询单是平台的核心业务实体。用户发起咨询后这条记录要经历“还没人管 → 有律师了但没回 → 正在沟通 → 结束”四个阶段。在数据库里我建议直接用字符串存状态但要在一个地方统一定义所有合法流转不能允许任意跳转。CREATE TABLE consultation ( id BIGINT NOT NULL AUTO_INCREMENT, user_id BIGINT NOT NULL, lawyer_id BIGINT DEFAULT NULL, category VARCHAR(20) NOT NULL, title VARCHAR(100) NOT NULL, description TEXT NOT NULL, status VARCHAR(20) NOT NULL DEFAULT PENDING_ASSIGN, close_reason VARCHAR(200) DEFAULT NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_lawyer_id (lawyer_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;咨询单的状态我固定为四个PENDING_ASSIGN 待指派、WAITING_REPLY 待回复、IN_PROGRESS 咨询中、CLOSED 已关闭。设计原则是状态只往一个方向流动不允许回退。用户创建咨询单时如果指定了律师直接进 WAITING_REPLY没指定就进 PENDING_ASSIGN等待律师在待接单列表里认领。律师第一次回复后状态从 WAITING_REPLY 变成 IN_PROGRESS之后双方可以继续对话直到用户主动结束或管理员强制关闭。当前状态操作目标状态触发方PENDING_ASSIGN律师接单 / 管理员指派WAITING_REPLY律师 / 管理员WAITING_REPLY律师首次回复IN_PROGRESS律师IN_PROGRESS用户结束咨询CLOSED用户任意非 CLOSED 状态管理员强制关闭CLOSED管理员状态机看着简单真正容易出问题的是散落各处的 if 判断。我在项目里会用一个独立的类收拢所有状态迁移规则任何接口要改状态之前都先走这个类的校验方法避免出现“已关闭的咨询单还能回复”“还没接单就能看到律师消息”这类逻辑漏洞。2.3 律师入驻审核审核状态和登录状态必须一起改律师入驻是平台信任的基础。普通用户注册后注册即登录律师注册后必须补充执业信息并等待管理员审核。审核接口要同时修改 lawyer_profile 的 audit_status 和 user 的 status而且必须在同一个事务里完成否则就会出现档案显示已通过但账号仍然无法登录的情况。Transactional public void auditLawyer(Long profileId, String result, String reason) { LawyerProfile profile lawyerProfileMapper.selectById(profileId); if (profile null) { throw new BusinessException(律师档案不存在); } if (APPROVED.equals(result)) { profile.setAuditStatus(APPROVED); userMapper.updateStatus(profile.getUserId(), 1); } else { profile.setAuditStatus(REJECTED); profile.setAuditReason(reason); } lawyerProfileMapper.updateById(profile); }这段代码的逻辑要点有两个。第一Transactional 保证 audit_status 和 user.status 要么一起更新成功要么一起回滚第二驳回时只填 audit_reason不动 user.status这样律师账号还在但不具备接单资格。审核结果在律师端要能查到用户在选律师时也要能看到该律师的审核状态所以在列表查询里要过滤 audit_status 不为 APPROVED 的律师不能让一个被驳回的律师继续出现在推荐列表里。3. 后端核心链路从创建咨询单到消息收发的代码实现数据模型定好之后后端要做的事情其实是把几段标准流程串起来用户创建咨询单、律师接单回复、双方查看消息、用户结束咨询。每一段流程都涉及状态变更和消息落库我会把状态变更和消息插入放在同一个事务里保证不会出现状态改成功了但消息没发出去的情况。这一章的代码都是可以直接落地的最小实现没有引入多余的框架。3.1 创建咨询单事务包裹下的“单消息”双落库创建咨询单时用户需要提交标题、案情描述、分类还可以选择是否指定律师。指定了律师咨询单直接进入待回复状态没指定就进入待指派状态等待律师接单。无论哪种情况系统都要自动插入一条开场白消息告诉用户咨询单已经创建成功。Transactional public ConsultationVO createConsultation(ConsultationCreateDTO dto) { User user currentUserService.getCurrentUser(); if (!USER.equals(user.getRole())) { throw new BusinessException(只有普通用户可以发起咨询); } Consultation consultation new Consultation(); consultation.setUserId(user.getId()); consultation.setCategory(dto.getCategory()); consultation.setTitle(dto.getTitle()); consultation.setDescription(dto.getDescription()); consultation.setLawyerId(dto.getLawyerId()); consultation.setStatus(dto.getLawyerId() ! null ? WAITING_REPLY : PENDING_ASSIGN); consultationMapper.insert(consultation); Message message new Message(); message.setConsultationId(consultation.getId()); message.setSenderId(0L); message.setSenderRole(SYSTEM); message.setContent(咨询单已创建请耐心等待律师回复); message.setReadFlag(1); messageMapper.insert(message); return convertToVO(consultation); }参数说明dto.getLawyerId() 是用户从律师列表里手动选择时才会传的值不传则为空咨询单走待指派流程senderId 设为 0L 表示系统消息readFlag 设为 1因为系统消息不需要用户手动清除未读。Transactional 保证咨询单主记录和开场白消息同时落库避免出现咨询单创建成功但用户看不到任何反馈的尴尬情况。创建接口返回的 VO 里要包含状态码和状态描述前端根据状态码决定显示“等待律师接单”还是“已指派律师等待回复”。不要只返回一个咨询单 ID 让前端自己去猜状态状态描述直接放在接口返回值里前端渲染会省很多事。3.2 律师接单与首次回复状态变更和消息发送合并成一个事务律师接单和律师回复是两个接口。接单接口的作用是把咨询单的 lawyer_id 设置为当前律师状态从 PENDING_ASSIGN 变为 WAITING_REPLY回复接口负责插入消息内容并在首次回复时把状态从 WAITING_REPLY 变为 IN_PROGRESS。接单动作本身可以不带消息但回复动作必须连同状态变更一起做成一个事务。Transactional public void replyConsultation(Long consultationId, String content) { User lawyer currentUserService.getCurrentUser(); Consultation consultation consultationMapper.selectById(consultationId); if (consultation null) { throw new BusinessException(咨询单不存在); } if (!lawyer.getId().equals(consultation.getLawyerId())) { throw new BusinessException(只有该咨询单的接单律师才能回复); } ConsultationStateMachine.assertCanReply(consultation); Message message new Message(); message.setConsultationId(consultationId); message.setSenderId(lawyer.getId()); message.setSenderRole(LAWYER); message.setContent(content); message.setReadFlag(0); messageMapper.insert(message); String nextStatus ConsultationStateMachine.nextAfterFirstReply(consultation.getStatus()); if (!nextStatus.equals(consultation.getStatus())) { consultation.setStatus(nextStatus); consultationMapper.updateStatus(consultationId, nextStatus); } }这段代码有两条必须守住的底线。第一归属校验不能省当前登录用户必须是咨询单绑定的律师否则会出现任何律师都能回复任意咨询单的严重漏洞第二状态校验放在回复之前CLOSED 状态的咨询单直接抛异常不允许再插入消息。nextAfterFirstReply 这个方法只在 WAITING_REPLY 时把状态推进到 IN_PROGRESS咨询中状态保持不变这样后续的追问和回复不需要反复切换状态。首次回复的逻辑也可以做成自动触发律师接单后系统自动插入一条“律师已接单”的系统消息提醒用户等待回复。这个可选功能只需要在接单接口里加一次 messageMapper.insert 调用不影响整体状态机设计。3.3 查询会话与已读未读游标分页和批量已读会话列表和消息查询是咨询平台最常用的接口也是最容易写出性能问题的地方。常见误用是先把所有消息查出来再用 Java 循环逐条判断已读未读消息量一上来接口就变得很慢。我的做法是消息查询用游标分页已读未读用一条批量 UPDATE 解决。public ListMessageVO listMessages(Long consultationId, Long currentUserId, Long lastMessageId) { ListMessage messageList messageMapper.selectByConsultationId( consultationId, lastMessageId ! null ? lastMessageId : Long.MAX_VALUE, 50 ); messageMapper.markReadByConsultation( consultationId, currentUserId ); return convertToVO(messageList); }SELECT * FROM message WHERE consultation_id #{consultationId} AND id #{lastMessageId} ORDER BY id DESC LIMIT 50;游标分页的关键在于 lastMessageId。前端第一次拉取时传 0后端用 Long.MAX_VALUE 兜底查出最新 50 条下拉加载更多时传当前已加载消息里最小的 id后端只查比这个 id 更早的消息。这样翻页再深也只走索引不会出现 OFFSET 越大越慢的问题。markReadByConsultation 会把该咨询单里发送给当前用户且未读的消息一次性全改成已读避免用户一条一条点掉未读体验差数据也对不齐。已读未读这个字段建议放在 message 表里用 is_read 表示不单独建已读表。理由是这个场景没有“多端已读同步”需求单字段足够。等以后要做多端已读再拆表现在拆就是过度设计。4. 前端多角色工作台路由守卫、会话轮询与状态同步后端把接口和状态机定好之后前端的工作本质上是把同一套数据按照三种角色渲染成三种界面。Vue 侧要处理的事情是路由权限控制、消息轮询、按钮状态同步。这一章我按 Vue 3 的 Composition API 写法来拆如果你用的是 Vue 2 选项式思路完全一致只是写法不同。4.1 路由守卫与动态菜单让 USER、LAWYER、ADMIN 看到各自的界面前端路由不能只做“页面跳转”要做角色维度的权限过滤。每个路由的 meta 里声明允许访问的角色数组全局前置守卫里判断当前用户是否命中这是最直接也最不容易出错的方案。const router createRouter({ history: createWebHistory(), routes: [ { path: /login, component: Login }, { path: /user/consultations, component: UserConsultations, meta: { roles: [USER] } }, { path: /lawyer/orders, component: LawyerOrders, meta: { roles: [LAWYER] } }, { path: /admin/audit, component: AdminAudit, meta: { roles: [ADMIN] } } ] }) router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) return } const role store.state.user.role if (to.meta.roles !to.meta.roles.includes(role)) { next(/403) return } next() })路由守卫做了三层判断先看有没有 token没有就踢回登录页再看目标路由有没有角色限制有就比对当前用户角色最后放行。这里要注意的是登录接口返回的 role 一定要存进全局状态管理不要每次从 localStorage 里读字符串否则刷新页面后角色信息会和 token 脱节。侧边栏菜单同样要按角色过滤。不要把菜单写死在布局组件里而是维护一个带 roles 字段的菜单数组用 computed 过滤后渲染这样以后加新页面只需要在数组里加一行不用动模板结构。const menus computed(() { const all [ { path: /user/consultations, label: 我的咨询, roles: [USER] }, { path: /lawyer/orders, label: 接单列表, roles: [LAWYER] }, { path: /admin/audit, label: 律师审核, roles: [ADMIN] } ] return all.filter(item item.roles.includes(store.state.user.role)) })路由守卫只是前端体验层面的控制真正的安全边界在后端。我在第 5 章会专门提到如果后端接口不做角色校验任何人都可以直接用接口工具篡改数据前端守卫形同虚设。4.2 会话页轮询设计法律咨询场景为什么不需要 WebSocket很多人一听到“消息聊天”就想到 WebSocket法律咨询场景其实是轮询更合适。用户和律师之间的对话频率很低一天来回十几条已经算活跃5 秒轮询的延迟用户完全感知不到而且部署不需要维护长连接服务省掉一大块运维成本。我建议第一版无脑上轮询等用户量上来或者出现高频沟通需求再换 WebSocket接口形态提前留好就行。function useMessagePolling(consultationId) { const messages ref([]) let timer null async function load() { const { data } await api.get(/consultations/${consultationId}/messages) messages.value data } onMounted(() { load() timer setInterval(load, 5000) }) onBeforeUnmount(() { if (timer) clearInterval(timer) }) return { messages, load } }轮询接口最好带 lastMessageId 参数只拉取当前会话里比该 id 新的消息而不是每次都全量查询。我在后端接口设计里把这个参数已经加上了前端轮询时把当前消息列表里最大的 id 传给后端返回的新消息追加到列表尾部渲染性能会好很多。关于轮询间隔5 秒是常规选择也可以按页面所在路由动态调整比如会话页 3 秒、列表页 10 秒。间隔太短会给后端造成无谓压力太长用户会觉得消息来得慢。我一般建议会话页先固定 5 秒后面再根据服务器压力曲线调整。4.3 前端状态同步按钮显隐和结束咨询的交互咨询单状态决定用户和律师界面上显示什么按钮。待指派时用户端显示“等待接单中”律师端显示“接单”按钮咨询中时用户端显示“结束咨询”结束后所有按钮消失。前端最容易犯的错是把状态字符串直接写在模板里到处判断后期改一个状态值要全局搜索替换。我习惯把状态对应的按钮行为收成一个工具函数模板只调用这个函数。export function consultationActions(status, role) { if (status PENDING_ASSIGN role LAWYER) { return [{ type: ACCEPT, label: 接单 }] } if (status IN_PROGRESS role USER) { return [{ type: CLOSE, label: 结束咨询 }] } return [] }结束咨询这个操作要加二次确认因为一旦关闭用户就不能继续发消息了。确认弹窗可以用 Element Plus 的 ElMessageBox.confirm确认后调用关闭接口前端本地更新状态然后通知轮询逻辑这个会话已经结束停止继续轮询。一个常被忽略的细节是用户可能同时打开多个咨询单关掉其中一个后其他咨询单的轮询不能受影响。所以轮询定时器要按咨询单 ID 独立管理不要在组件里用一个全局 timer 处理所有会话。我在 4.2 的 useMessagePolling 里已经把 consultationId 作为参数传入每个会话页实例各自持有自己的 timer互相不干扰。5. 法律咨询系统避坑指南五条最值得记住的排查记录这一章写我在做同类型咨询平台时真实踩过的坑按“现象、原因、解决”的顺序展开。每一条都对应一段实实在在的线上故障有些问题不跑到一定数据量根本不会暴露提前知道能省很多排查时间。5.1 字段与时区最后回复时间为什么总是差 8 小时现象列表页显示的最后回复时间总比实际时间慢 8 小时用户明确表示看到的消息时间是错的。排查时发现 MySQL 里存的时间是对的但后端返回给前端的时间字符串变了。原因JDBC 连接串没写 serverTimezone 参数MySQL 驱动默认用了服务器本地时区而 Spring Boot 的 Jackson 序列化 LocalDateTime 时又按 UTC 输出两边一叠加就出现了 8 小时偏差。解决在 application.yml 里同时配置连接串时区和 Jackson 时区让整个链路统一到 Asia/Shanghai。spring: datasource: url: jdbc:mysql://localhost:3306/legal_platform?serverTimezoneAsia/Shanghai jackson: time-zone: Asia/Shanghai这里有个细节容易踩中项目里如果用了 LocalDateTime 接收前端传来的时间前端必须传带时区的 ISO 字符串否则 Jackson 会按默认时区解析。我在项目里统一规定前端传时间戳后端用 Long 接收再转 LocalDateTime彻底绕开格式解析问题。5.2 查询与索引会话页打开慢问题出在没建联合索引现象消息表数据量到几万条后会话页打开要两三秒用户反馈明显卡顿。原因message 表只建了主键索引查询会话里的消息时按 consultation_id 过滤全表扫描把速度拖垮了同时列表页用 OFFSET 翻页越翻越慢。解决给 message 表建联合索引 (consultation_id, id)翻页改成 id 游标方式。ALTER TABLE message ADD KEY idx_consultation_id_id (consultation_id, id);游标分页的写法后端部分已经展示过这里重点说索引字段顺序联合索引要按查询条件把等值字段放前面、排序字段放后面所以 consultation_id 在前id 在后。这条索引同时覆盖过滤和排序两个需求够用到百万级消息量。如果以后要按已读未读统计再单独加一个 (consultation_id, is_read) 索引不要图省事把所有场景塞进同一索引。5.3 审核状态与账号状态律师被驳回后为什么还能接单现象管理员驳回某位律师的入驻申请后发现这位律师仍然可以登录系统并且还能在待接单列表里抢单。原因审核接口只更新了 lawyer_profile.audit_status没有同步更新 user.status而律师端接口只校验了登录状态没校验审核状态。解决审核接口里把 user.status 和 audit_status 的更新放在同一个事务里同时接单接口增加一道校验强制要求当前律师的 audit_status 必须是 APPROVED。public void acceptConsultation(Long consultationId) { User lawyer currentUserService.getCurrentUser(); LawyerProfile profile lawyerProfileMapper.selectByUserId(lawyer.getId()); if (profile null || !APPROVED.equals(profile.getAuditStatus())) { throw new BusinessException(律师账号未通过审核不能接单); } // 继续接单逻辑 }这道校验看似多了一次查询但它是防止“审核状态与登录状态脱节”的最后一道防线。即使审核接口有事务保护也保不齐将来有人直接改数据库或者绕过管理端接口把 user.status 改成 1 但 audit_status 还是 REJECTED。后端接口层层校验远比依赖一个管理端页面靠谱。5.4 已读未读只存在前端变量里的后果现象用户打开会话页看完所有消息往下翻一翻再回列表页发现未读数字又开始增加刷新页面后所有消息又变回未读状态。原因打开会话时前端把消息列表存到组件变量里已读操作只改了本地数组里某个字段没有调用后端接口把数据库里的 is_read 字段更新掉。解决打开会话时调用批量已读接口后端把该咨询单发给当前用户的消息一次性标记为已读前端不需要做任何本地状态维护。Transactional public void markRead(Long consultationId, Long currentUserId) { messageMapper.markReadByConsultation(consultationId, currentUserId); }UPDATE message SET is_read 1 WHERE consultation_id #{consultationId} AND sender_id ! #{currentUserId} AND is_read 0;这里要注意 sender_id ! currentUserId 的条件否则用户自己发的消息也会被标记成已读未读数字会算错。另外批量已读这个动作在每次进入会话时调用轮询接口不要重复触发否则每条轮询都带一次 update 请求数据库压力会成倍上升。我在 3.3 里把已读操作放在查询会话接口里一次搞定前端只需要保证打开会话时调用这个接口后续轮询不带已读参数。5.5 后端鉴权角色校验不能只靠前端路由守卫现象某用户用自己的普通账号登录后直接绕过前端页面调律师接单接口管理系统数据后发现咨询单的 lawyer_id 被篡改成了这个普通用户。原因后端接口只校验了登录态没有校验当前登录用户的角色前端路由守卫只是界面层限制接口层面完全没防御。解决在每个写接口的 Service 方法开头增加角色断言或者用拦截器统一处理。我建议写一个简单的角色注解配合 Spring AOP把鉴权逻辑收敛起来。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { String[] value(); }在 Controller 方法上标注 RequireRole({LAWYER})由切面统一解析当前登录用户的 role不在列表里直接抛异常。这个方案不引入 Spring Security 全家桶适合小型团队从零起步如果项目以后要接入 OAuth2 或第三方登录再换成 Spring Security 也不迟注解的位置不用大改。6. 进阶给咨询单加一个“超时自动流转”的定时任务平台上线后你会发现一个规律总有用户发起咨询后一直没有律师接单如果不做任何处理这些咨询单会永远躺在待指派状态用户觉得平台没人管。最简单的方案是加一个定时任务把超过一定时间仍处于待指派状态的咨询单自动关闭同时插入一条系统消息告知用户。更进一步的做法是把这个规则放进数据库配置表而不是写死在代码里。Component public class ConsultationTimeoutJob { Scheduled(fixedDelay 60_000) public void autoCloseExpired() { ListConsultation expired consultationMapper.selectExpired( PENDING_ASSIGN, LocalDateTime.now().minusHours(2) ); for (Consultation consultation : expired) { consultationService.closeByAdmin( consultation.getId(), 超过2小时无人接单系统自动关闭 ); } } }这段代码的调度周期是 60 秒每次扫描 2 小时前创建且仍处于 PENDING_ASSIGN 的咨询单。fixedDelay 的含义是上一次任务执行完成后间隔 60 秒再执行下一次适合这种不需要精确到秒的清理任务。selectExpired 的 SQL 里用 create_time #{deadline} 过滤配合 idx_status 索引即使积压大量待指派单也不会导致全表扫描。验证这个定时任务最直接的方法是手动插入一条测试数据把 create_time 设为 3 小时前状态设为 PENDING_ASSIGN然后等待定时任务触发观察咨询单状态是否被改成 CLOSED、系统消息是否正常落库。我用模拟项目 X 验证时还会顺便检查 close_reason 字段有没有被填上这个字段在后续管理后台的统计报表里会用到。更灵活的做法是把“2小时”和“目标状态”抽到数据库配置表里管理员在后台可以修改超时时长不用改代码重新发布。配置表字段就是 rule_name、trigger_status、timeout_minutes、target_status、enabled 五列定时任务每次启动时读取最新配置业务逻辑完全不受影响。这个配置化的思路同样适用于第 2 章的状态机把合法流转也存成配置平台后续接付费咨询或者转人工时就不用动核心代码。写这个功能的过程中我最大的教训是状态判断一定不要散落在各个 Controller 里否则加一个超时流转要改七八个地方稍不留神就把某个分支漏掉。我现在习惯把所有状态迁移统一收进 Service 层的一个方法新规则只是新增一条配置的事。如果这篇笔记能帮你少走点弯路那就值了希望帮到你。本文还有配套的精品资源点击获取