SpringCloud+Layui+AI大模型：智能政务老年卡办理微服务系统实践-平芜编程栈

老年卡办理这类政务系统，在高校毕业设计里出现的频率一直不低。传统写法大多是 SSM 或者 SpringBoot 单机版，功能上无非是增删改查加一个页面。但这套课题做成 SpringCloud 微服务架构，同时把 AI 大模型接进业务流程，技术含量和答辩亮点一下就拉开了。

这次我们来看一个非常典型的选题：基于 SpringCloud + Layui + AI 大模型的智能政务微服务老年卡办理系统。它面向的是政务场景中的老年卡在线申请、材料提交、进度查询、后台审核等业务，但在技术实现上走了微服务拆分，并利用 AI 大模型做智能客服和材料辅助审核。对准备 Java 方向毕业设计、或者想熟悉 SpringCloud 微服务开发流程的同学来说，是一个很有参考价值的完整项目。

先说这条课题最值得关注的几个点：

微服务架构：按业务拆分为多个服务，覆盖注册中心、网关、业务服务和 AI 服务；
AI 大模型接入：不只是演示，而是把大模型能力落到材料审核、智能问答这类具体政务场景；
前端采用 Layui：传统服务端渲染型后台界面，适合快速开发和答辩演示；
毕业设计配套完整：源码、论文（LW）、PPT、讲解视频一体，适合直接修改二开。

本文会从项目架构、核心功能、本地部署、启动方式、接口测试、性能观察、常见问题和答辩建议几个方面展开。如果你正在做 SpringCloud 相关的毕设，并且纠结微服务模块怎么拆、AI 能力怎么集成、接口怎么设计，这篇文章可以一路看到底。

1. 核心能力速览

能力项	说明
项目类型	Java Web 毕业设计 / 微服务项目实战
后端技术栈	SpringBoot、SpringCloud、SpringCloud Alibaba、MyBatis-Plus、MySQL
前端技术栈	Layui、HTML、Thymeleaf（或前后端分离静态页）
AI 能力	大模型 API 接入，用于智能问答、材料辅助初审
微服务组件	注册中心、网关、配置中心、业务服务
核心业务	老年卡在线申请、材料上传、审核流转、卡片发放记录、进度查询
后台管理	管理员登录、申请单管理、材料查看、审核操作、数据统计
启动方式	按服务逐个 Maven 打包启动，微服务模式运行
接口能力	REST API，供前端页面或第三方系统调用
是否支持批量任务	支持审核任务列表批量处理，AI 辅助审核可批量触发
推荐环境	JDK 1.8 / JDK 17、Maven 3.6+、MySQL 5.7 / 8.0、Node 非必需

从材料来看，这个项目不是那种“只有一个 SpringBoot 启动类”的简化版，而是真正按微服务思路拆分了模块。这意味着部署时不是启动一个服务，而是按顺序把注册中心、网关、业务服务、AI 服务分别跑起来，再用统一端口进入前端页面。

2. 系统架构与微服务模块设计

2.1 整体架构

这一类政务老年卡办理系统，核心流程可以概括为：用户在线申请 -> 提交材料 -> 系统初审 -> 人工复核 -> 制卡发卡 -> 进度公示。

在微服务架构下，这几个环节会被拆分到不同服务中，避免把所有业务塞进一个单体应用。常见的模块划分方式如下：

模块	职责
注册中心	服务注册与发现，维护各服务实例地址
网关服务	统一入口，路由转发、鉴权、限流
用户服务	老年人用户注册、登录、个人信息管理
申请服务	老年卡申请单填写、材料上传、进度查询
审核服务	申请单审核流程、AI 辅助初筛、人工复核
AI 服务	对接大模型 API，实现智能问答、材料信息提取
后台管理端	Layui 前端页面，调用网关接口完成管理操作

这个拆法比较规整。每个服务独立打包、独立数据库表或独立 Schema，服务之间通过 Feign 或 RestTemplate 调用。答辩的时候，你可以直接针对“为什么拆分老年卡申请和审核两个服务”来展开，解释点在于：申请是高频写入操作，审核是低频但涉及材料校验的操作，拆开后可以独立伸缩。

2.2 微服务核心组件

SpringCloud 项目通常不会只用到一个组件，这套系统从课题关键词看，至少涉及以下内容：

SpringCloud Gateway：统一入口，路由配置中把/api/user/**、/api/apply/**、/api/audit/**转发到对应服务；
Nacos / Eureka：服务注册与发现，维护微服务实例列表；
OpenFeign：服务间声明式 HTTP 调用，比如审核服务调用 AI 服务；
SpringCloud Config / Nacos Config：配置文件集中管理，便于切换不同环境的数据库和 AI 服务参数。

如果你们毕业设计要求必须画架构图，建议预留一张“客户端 -> 网关 -> 微服务集群 -> 数据库 / AI 服务”的分层图。这也是一类评阅老师愿意看到的亮点图。

2.3 客户端与前端

前端使用 Layui，这是国内使用面很广的轻量后台 UI 框架。相比 Vue + Element UI，Layui 不需要 Node 构建流程，直接引入静态资源文件就能跑。对毕业设计来说，Layui 的学习成本低，表格、表单、弹出层、分页等组件开箱即用，非常适合快速做一个后台管理面板。

老年卡办理系统的前端一般包括两套：

用户端申请页面：填写申请人信息、上传身份证和照片、提交申请；
管理后台：申请单审核列表、材料预览、AI 初审结果展示、统计面板。

两套页面都可以通过 Layui 的 table 模块渲染数据。数据来源是网关暴露的 REST 接口，格式建议统一为{ code, msg, data }。

3. 适用场景与使用边界

3.1 适合谁用

这个项目最适合下面三类人：

Java 方向毕业设计学生：课题已经明确了 SpringCloud + Layui + AI 的组合，模块多、工作量足，论文有内容可写；
想快速了解微服务落地的开发者：比起空读 SpringCloud 文档，跑通一个完整的微服务系统更能理解注册中心、网关、Feign 之间是怎么协作的；
做智慧政务课题的小组：老年卡办理只是一个业务载体，把审核服务替换成其他政务审批流程，系统骨架可以复用。

3.2 能解决什么问题

从业务角度，它解决的核心问题是“老年人办卡流程线上化”。传统线下办卡需要到街道或政务大厅提交材料，对行动不便的老年人不够友好。线上申请加上 AI 辅助材料初审，可以降低审核人员的工作量。

从技术角度，它演示了微服务架构在实际业务系统中的落地方式：不同业务功能被拆分成独立服务，服务之间通过网络通信协作，前端不需要关心某个功能部署在哪台机器上。

3.3 使用边界与合规提醒

这里要特别强调几条边界：

AI 辅助审核不能替代人工审核。老年卡涉及身份信息、证件有效性，AI 只适合做材料完整性预检，不能作为最终审批依据；
系统内如果涉及身份证号、手机号、住址等个人信息，开发测试阶段必须使用脱敏数据。正式上线涉及真实公民信息，需要按相关规定做数据安全和隐私保护设计；
AI 大模型接口产生的内容需要人工复核。大模型输出可能不稳定，不能直接把 AI 结论写入数据库作为最终审核结果；
不要在网络公开环境存放数据库密码、AI 接口密钥。论文截图和演示视频要注意脱敏。

这些内容既是合规要求，也是评阅老师大概率会追问的问题。答辩前把这几点想清楚，反而能体现你的工程意识。

4. 环境准备与前置条件

4.1 基础软件环境

部署这套老年卡办理系统前，需要准备好以下基础环境。具体版本请以项目内 pom.xml 和说明文档为准：

软件	建议版本	用途
JDK	1.8 或 17	Java 运行环境
Maven	3.6+	项目构建与依赖管理
MySQL	5.7 或 8.0	业务数据存储
Redis（可选）	5.0 / 6.0	会话与缓存
Nacos / Eureka	按项目说明	服务注册中心
Layui 静态资源	2.6 / 2.8	前端页面依赖

团队版或课程设计版可能不强制用 Redis。判断依据很简单：如果服务配置里有spring.redis相关配置，并且启动类上有@EnableCaching之类的注解，就需要准备 Redis；否则可以跳过。

4.2 项目目录结构参考

一个多模块 Maven 工程的结构通常如下：

senior-card-system/ ├── pom.xml ├── sr-card-common/ # 公共模块 ├── sr-card-gateway/ # 网关服务 ├── sr-card-auth/ # 认证与用户服务 ├── sr-card-apply/ # 老年卡申请服务 ├── sr-card-audit/ # 审核服务 ├── sr-card-ai/ # AI 服务 ├── sr-card-admin-web/ # Layui 管理后台静态资源 └── sql/ └── senior_card.sql # 初始化脚本

具体模块名称未必一致，但总体思路相同。公共模块用于存放统一返回结果、异常处理、工具类；网关服务统一暴露接口；业务服务之间通过 Feign 通信。

4.3 数据库初始化

拿到项目后，先在 MySQL 中创建数据库并导入 SQL 脚本。

CREATE DATABASE senior_card CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后用命令行或 Navicat 执行项目中sql目录下的脚本。老年卡办理系统的核心表大致包括：用户表、申请单表、材料表、审核记录表、卡片信息表、操作日志表。如果脚本里已经带测试数据，建议保留，方便第一次启动后直接看到列表效果。

5. 本地部署与启动方式

5.1 启动顺序

微服务项目不像单体应用那样只有一个启动类。启动时要注意先后顺序，基本原则是：先启动基础设施，再启动注册中心，再启动具体业务服务。

推荐顺序：

MySQL、Redis（如果使用）;
Nacos 注册中心（或 Eureka Server）;
网关服务；
认证服务 / 用户服务；
申请服务；
审核服务；
AI 服务；
后台管理前端页面的静态资源服务（可通过 SpringBoot 或 Nginx 托管）。

在 IDEA 中，每个服务对应一个启动类。比如网关服务启动类名可能为GatewayApplication，AI 服务为AiServiceApplication。逐个 Run 即可。

5.2 配置文件调整

启动前需要检查每个服务的application.yml或 bootstrap 配置文件。重点关注三处：

第一处是数据库地址。把url、username、password改成自己本机的值。

spring: datasource: url: jdbc:mysql://localhost:3306/senior_card?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

第二处是注册中心地址。以 Nacos 为例：

spring: cloud: nacos: discovery: server-addr: 127.0.0.1:8848

如果项目用的是 Eureka，则配置：

eureka: client: service-url: defaultZone: http://localhost:8761/eureka/

第三处是 AI 服务配置。这类毕设项目的 AI 能力通常通过调用大模型 API 实现，需要在配置文件中填写接口地址和密钥。

ai: api-url: https://your-llm-api.example.com/v1/chat/completions api-key: sk-xxxxxxxxxxxxxxxx model: your-model-name

具体字段名以项目代码为准。如果你没有可用的 API 密钥，AI 辅助审核模块会调用失败，但申请和审核主流程仍然可以跑通，这一点要提前清楚。

5.3 使用 Maven 启动

在项目根目录执行 Maven 命令，先完成整体编译：

mvn clean install -DskipTests

然后将各服务模块分别启动。以 IDEA 为例，直接运行各模块下的Application类最省事。如果要在命令行启动，可以进入各模块目录：

cd sr-card-gateway mvn spring-boot:run

需要注意，直接mvn spring-boot:run可能会受到依赖模块未安装影响，所以前面那步mvn clean install -DskipTests很重要。

5.4 启动验证

启动过程中观察每台服务的控制台日志。比较理想的日志状态是出现类似以下内容：

Registered instance with registry: sr-card-apply/192.168.1.100:8082

这表示该服务已经成功注册到注册中心。如果使用 Nacos，打开管理控制台http://localhost:8848/nacos，在“服务管理”界面可以看到服务列表中包含gateway、apply、audit、ai等实例。

网关启动后，前端页面通过网关端口访问。假设网关端口是8080，那么管理后台地址一般为：

http://localhost:8080/admin/index.html

如果页面打不开，优先检查静态资源是否放在网关服务的resources/static目录下，或者是否独立部署。

6. 功能测试与效果验证

部署完成后，需要逐项验证功能是否正常。下面按测试顺序整理一套操作流程。

6.1 用户注册与登录

打开用户端申请页面，先注册一个测试账号。需要注意，老年卡办理系统的注册信息通常比普通网站多，至少包含姓名、身份证号、出生日期、手机号、户籍地址等字段。

测试要点：

身份证号填写错误时，后端是否有格式校验；
手机号是否做了^1[3-9]\d{9}$格式校验；
提交成功后，数据库user表是否新增记录。

预期结果：注册成功后自动跳转到登录页，输入账号密码能正常进入用户中心。

6.2 老年卡在线申请

登录测试账号后，进入“老年卡申请”页面。按页面要求填写申请表单，并上传相关材料图片。

上传材料一般包括：

身份证正面照片；
身份证反面照片；
个人近期免冠照片；
居住证明或户口本照片（视课题要求）。

提交申请后，需要确认几件事：

申请单是否生成唯一编号，规则通常类似SC202506010001；
申请状态是否变为“待初审”；
材料图片是否成功保存到本地磁盘或对象存储目录；
数据库申请单表是否写入完整记录。

6.3 AI 辅助材料审核

这是这套课题最有区分度的演示点。管理员在后台看到一条申请单后，可以点击“AI 辅助审核”按钮，系统将申请单文本和材料图片信息发送给大模型接口，返回该申请单的材料完整性和异常提示。

演示时可以这样操作：

管理员登录后台；
进入申请单审核列表；
点击某条申请单；
选择“AI 预审”或“智能校验”按钮；
页面返回结果，例如：材料是否齐全、身份证号与姓名是否匹配、照片是否存在疑似不合规项。

预期结果：AI 服务返回一段结构化文本或 JSON 结果，前端对话区域展示 AI 的分析结论，例如“该申请单材料齐全，身份证信息格式正确，照片清晰度达标”。同时，审核列表中的 AI 预审状态从“未预审”变为“已预审”。

这里需要特别提醒：如果 AI 配置了安全合规参数，材料图片涉及人脸的，只能用于该业务系统的审核流程，不能把图片转发给无关的第三方接口。答辩演示时尽量使用模拟数据。

AI 服务返回后，审核员仍需要人工判断是否通过。从材料来看，这个项目的设计思路比较稳妥：AI 是辅助，不是最终裁决。

6.4 人工审核与发卡

管理员对 AI 预审通过的申请单进行人工复核。复核操作通常包括“通过”或“退回”。

选择“通过”后，申请单状态变为“审核通过”，进入制卡环节；
选择“退回”时，需要填写退回原因，用户端可以看到该原因；
制卡完成后，管理员录入卡片编号，系统将状态更新为“已发卡”。

测试时建议同时验证用户端的进度查询功能。用户登录后应能看到当前申请处于哪个节点，进度条或状态文字需要与后台审核状态保持一致。

6.5 数据统计与导出

管理后台一般会包括数据统计面板，常见指标有：

今日新增申请数；
待审核申请数；
已发卡数量；
各街道或区县申请量排行。

这类功能通过 SQL 聚合统计实现，适合在答辩时展示数据分析思路。如果系统提供导出功能，可以验证导出的 Excel 文件能否正常打开，以及文件编码是否为 UTF-8。

7. 接口 API 与批量任务对接

7.1 接口设计规范

老年卡办理系统的接口建议统一走网关，返回格式统一为：

{ "code": 200, "msg": "操作成功", "data": { "applyId": 1001, "status": "AUDITING" } }

前端 Layui 表格解析这类数据非常方便。比如table.render中配置parseData时，直接返回res.data.list即可。

7.2 典型接口示例

下面列出几个核心接口的通用调用方式，实际路径以项目代码为准。

用户登录：

curl -X POST http://localhost:8080/api/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"123456"}'

创建申请单：

curl -X POST http://localhost:8080/api/apply/create \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{ "name": "张建国", "idCard": "110101196001011234", "phone": "13800138000", "address": "北京市朝阳区某某街道", "materialIds": [12, 13, 14] }'

查询申请单详情：

curl -X GET http://localhost:8080/api/apply/detail/1001 \ -H "Authorization: Bearer <token>"

AI 预审接口：

curl -X POST http://localhost:8080/api/ai/preview \ -H "Content-Type: application/json" \ -H "Authorization: Bearer <token>" \ -d '{"applyId": 1001}'

7.3 后端 AI 服务接入模板

如果自己实现 AI 服务，可以用 RestTemplate 或 Hutool 的 HttpUtil 调用大模型接口。下面是一个简化示例：

@Service public class AiAuditService { @Value("${ai.api-url}") private String apiUrl; @Value("${ai.api-key}") private String apiKey; public String aiPreviewApply(ApplyInfo applyInfo) { String prompt = "你是老年卡办理系统审核助手。请检查以下申请信息是否完整，" + "包括姓名、身份证号、手机号、户籍地址。只输出结论和建议。" + "申请信息：" + applyInfo.toString(); Map<String, Object> requestBody = new HashMap<>(); requestBody.put("model", "your-model"); requestBody.put("messages", new Object[]{ Map.of("role", "user", "content", prompt) }); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.set("Authorization", "Bearer " + apiKey); HttpEntity<Map<String, Object>> request = new HttpEntity<>(requestBody, headers); RestTemplate restTemplate = new RestTemplate(); ResponseEntity<String> response = restTemplate.postForEntity(apiUrl, request, String.class); // 实际项目中需要解析响应体，这里只做演示 return response.getBody(); } }

这个示例需要注意：不同大模型厂商的请求体格式不同，字段名model、messages、max_tokens等要以实际接入的 API 文档为准。

7.4 批量审核任务

政务场景下，管理员面对的不是一条申请单，而是几十上百条待审核记录。如果项目支持批量操作，通常会提供“批量 AI 预审”和“批量通过/退回”能力。

批量 AI 预审的后端思路：

查询所有状态为“待初审”的申请单 ID 列表；
遍历列表，逐条调用 AI 服务；
将每条预审结果写回数据库；
汇总成功条数和失败条数，返回给前端。

public BatchAiPreviewResult batchAiPreview(List<Long> applyIds) { int successCount = 0; int failCount = 0; List<String> failMessages = new ArrayList<>(); for (Long applyId : applyIds) { try { ApplyInfo info = applyMapper.selectById(applyId); String aiResult = aiAuditService.aiPreviewApply(info); applyMapper.updateAiPreview(applyId, aiResult); successCount++; } catch (Exception e) { failCount++; failMessages.add("申请单 " + applyId + " AI 预审失败：" + e.getMessage()); } } return new BatchAiPreviewResult(successCount, failCount, failMessages); }

批量任务里最容易被评阅老师追问的点是：如果某一批里面有一条失败，是继续执行还是整体回滚？正确的做法是针对失败的服务降级处理，记录失败原因，不阻塞其他申请单的审核。这也是微服务系统中很重要的容错思维。

8. 资源占用与性能观察

很多同学做微服务毕设时会发现电脑风扇开始狂转，原因很简单：同时运行了注册中心、网关、多个业务服务，每个服务都是一个 Java 进程，默认堆内存可能都是几百 MB 到 1G 以上。

8.1 观察方式

在 IDEA 中同时运行多个服务时，可以在底部 Tools 窗口的 “Services” 面板里看到各服务的内存和 CPU 占用。也可以使用 JDK 自带的jvisualvm连接每个应用端口进行观察。

命令行下可以使用：

jps -l

查看当前运行的 Java 进程，再通过jinfo、jstat查看 JVM 参数和 GC 情况。

8.2 降低资源占用的常用手段

如果本机配置不高，同时跑五六个微服务确实吃力。建议在不影响功能演示的前提下做以下调整：

为 IDEA 中每个 SpringBoot 服务设置较低的最大堆内存。

在 IDEA 的 Run/Debug Configurations 中，VM options 填入：

-Xms256m -Xmx512m

这会限制每个服务最大 512 MB 堆内存。网关、注册中心这类非业务服务可以调得更小。

只启动必要服务。

第一次跑通时不需要把所有模块都启动。最小可运行组合是：

注册中心；
网关；
用户/认证服务；
申请服务；
审核服务；
管理后台静态资源。

如果 AI 服务暂时不调试，可以先不启动，不影响申请和审核主流程。

关闭非必要的自动启动任务。

检查代码中是否有定时任务在启动时执行大量初始化操作，如果影响启动速度，可以调整触发策略。

8.3 数据库连接池配置

微服务多个业务服务连接同一个 MySQL 时，要注意数据库连接数。各服务默认连接池大小如果都是 10，三个业务服务就会占到 30 个连接。本地开发时可以把连接池最大值调小：

spring: datasource: hikari: maximum-pool-size: 5

这样能减少数据库连接占用，避免 MySQL 默认连接数被占满。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
启动注册中心后，服务无法注册	注册中心地址配置错误	检查各服务`application.yml`的注册中心地址	统一改为`127.0.0.1:8848`或对应端口
网关路由 404	路由配置缺失或服务未启动	查看网关日志，检查服务注册列表	确认路由 id、uri、predicates 配置正确
前端页面白屏	静态资源目录配置错误	检查浏览器开发者工具 Network 面板	将 Layui 静态资源放到正确目录
数据库连接失败	数据库未启动或账号密码错误	检查数据源配置	测试本机 MySQL 能否正常连接
接口返回 401	未携带 Token 或 Token 过期	检查登录接口返回和前端请求头	重新登录，确保请求头携带 Token
AI 接口调用超时	网络问题或 API 密钥错误	单独测试 AI API 连通性	检查密钥和接口地址，增大超时时间
批量 AI 预审部分失败	某几条数据格式异常	查看丸款日志，定位失败 ID	排除异常数据后重新执行
上传材料图片后无法显示	文件保存路径或访问映射错误	检查图片保存目录和虚拟路径映射	配置静态资源映射或改用对象存储
多服务启动后端口冲突	默认端口被占用	查看日志中的端口绑定异常	修改`server.port`后重启

推荐一个比较顺手的排查思路：出现问题先看网关日志，因为所有前端请求都经过网关，网关日志里能看到请求转发到了哪个服务、是否超时、是否找不到实例。网关没问题再往下定位具体业务服务。

9.1 微服务调用链路定位

当审核服务调用 AI 服务失败时，在分布式环境下日志分散在不同应用中，定位难度比单体大。推荐在项目中使用一个简单的全局 TraceId 工具：

public class TraceIdUtil { private static final ThreadLocal<String> TRACE_ID = new ThreadLocal<>(); public static String getTraceId() { return TRACE_ID.get(); } public static void setTraceId(String traceId) { TRACE_ID.set(traceId); } public static void remove() { TRACE_ID.remove(); } }

在网关过滤器里为每个请求生成 TraceId，放入请求头，业务服务在日志中打印这个 TraceId，就能把一次请求在多个服务中的日志串联起来。这个技巧写到论文里也很加分。

9.2 常见启动坑

依赖模块没有安装：直接在子模块里启动，提示找不到sr-card-common相关类，需要先在根目录执行mvn clean install -DskipTests；
JDK 版本不匹配：项目如果是基于 JDK 8 开发，使用 JDK 17 运行可能报依赖反射异常；
MySQL 时区问题：连接串未加serverTimezone=Asia/Shanghai，启动报 SQLException；
Layui 资源请求 404：确认静态资源是否被打包进target/classes/static，或者是否配置了资源映射。

10. 最佳实践与毕业设计答辩建议

10.1 代码与配置管理建议

这种课题的工程结构相对完整，但在实际开发和答辩准备中，建议注意以下几点：

保留一套最小可运行配置。

把所有服务启动后，导出一份运行说明，包含启动顺序、访问地址、测试账号。答辩时直接照着说明复现。

分目录管理材料文件。

上传的身份证照片、个人照片不要和项目源码混在一起。建议统一放到某个独立的 upload 目录，并在配置中记录基础路径。

数据库脚本和测试数据要一起提供。

评阅老师很可能在自己电脑上导入你的 SQL 脚本。如果脚本里没有任何测试数据，老师打开页面发现列表全空，第一印象会打折扣。

10.2 AI 能力展示技巧

AI 在这套系统里能不能成为答辩亮点，关键在于演示效果是否稳定。

建议在答辩前准备一组固定的测试数据，确保 AI 服务返回的结果是正面、稳定、可解释的。不要答辩现场临时输入，因为大模型接口在高峰期可能超时，也可能返回格式不稳定的内容。

另外一个加分做法是：在 AI 服务里增加一个“兜底逻辑”。比如调用大模型失败时，自动返回一个固定的提示语“AI 预审服务暂时不可用，请人工审核”。这样做不会让演示中断，还能体现出工程上的容错考虑。

10.3 微服务设计答辩点

评阅老师大概率会问以下几个问题，建议提前准备答案：

为什么要用微服务而不是单体架构？答案可以围绕独立部署、独立扩展、失败隔离来展开，同时承认微服务也有复杂性，这种机遇与挑战分析更容易拿高分；
服务之间如何通信？如果项目用的是 OpenFeign，重点解释声明式调用、负载均衡；
如果某个服务挂了怎么办？网关是否有熔断降级策略，业务服务是否配置了重试机制；
数据库是独立还是共享？大多数毕设项目会使用共享数据库，但如果能解释清楚“每一个服务都应该有自己独有的数据访问边界”会更好。

10.4 技术债务与边界承认

不要回避项目的局限性。如果没有做分布式事务，可以直接讲：当前系统在跨服务调用时采用最终一致性思路，核心申请单数据以申请服务为准，审核结果通过接口同步更新。如果接入了消息队列，则单独说明。比起夸夸其谈，承认边界并解释应对方案更符合工程实践。

11. 总结与下一步

这个 SpringCloud + Layui + AI 大模型的老年卡办理系统，最值得体验的点是“微服务架构 + 政务业务 + 大模型应用”的完整组合。它把真实政务场景拆成了用户注册、在线申请、材料上传、AI 预审、人工复核、制卡发卡等环节，对毕设来说，业务链路完整，技术层次分明，并且有大模型这个当下的热点加成。

拿到项目后，第一步不应该改代码，而是先把服务跑起来。先启动注册中心和网关，再启动业务服务，用提供的测试数据走通一条完整的申请与审核流程。中间如果 AI 接口调用失败，优先检查配置里的 API 地址和密钥；如果前端页面 404，优先检查静态资源配置。最快的验证方式是：管理员登录后台看到申请列表，点击 AI 预审返回结果，审核通过后发卡，整个过程全部走通，项目就有了一个可以展示的闭环。

后续如果要在这个基础上升级，有三个方向值得考虑：

把 AI 辅助审核从“文本提示”升级为“结构化输出”，让大模型直接返回可解析的 JSON 审核结果，减少人工判断成本；
增加消息队列，把申请提交和 AI 预审变成异步任务，避免审核量大时接口阻塞；
引入 Redis 缓存热数据，提升用户查询申请进度和高频列表访问的响应速度。

光是把这套系统跑通还不够，建议把你修改过的模块、新增的表、调整的接口单独记录下来。答辩时明确说清“哪些是你实现的，哪些在原来的基础上改过”，比笼统说一个完整项目更有说服力。

如果你正在准备 Java 微服务方向毕业设计，这个课题可以作为一个非常完整的参考模板。先模仿它的微服务拆分思路，再根据自己的业务理解做二次开发，最后把 AI 能力和审核流程串起来展示。整个项目做完，SpringCloud 核心组件、Layui 后台开发、AI 服务集成这三块经验都能写到简历上。建议收藏备用。