企业官网建设流程全解析

简介：一份基于JavaWeb的阿尔茨海默症早期康复系统毕业设计论文资料，面向专科与本科计算机及相关专业毕业生，可用作毕业论文撰写与系统设计参考。论文围绕阿尔茨海默症早期康复这一主题，系统梳理了研究背景、目的意义、国内外进展，并对疾病病因、发病机制、临床表现与诊断方法作了科普，同时分析了早期康复识别率低、手段有限、数据管理不规范等难点。在设计层面，文档给出了需求分析、系统架构、功能模块（如用户管理、康复计划定制、训练模块、数据分析）及测试评估思路，有助于读者理解从选题到系统落地的完整流程。压缩包内为1个docx文档，体积约33KB，内容结构清晰、章节完整。目前已有93人学习，适合需要快速获取论文框架与JavaWeb医疗康复系统设计思路的毕业生参考。

1. 基于JavaWeb的阿尔茨海默症早期康复系统：设计思路与落地路径

阿尔茨海默症早期康复系统，本质上是把「认知训练」和「康复进度跟踪」这两件线下靠纸笔完成的事搬进浏览器。这类系统常见于社区医疗站和康复机构，患者端做记忆、计算、注意力训练，家属和医生端看训练记录与评估趋势，技术栈是经典的 JavaWeb（Servlet + JSP + MySQL + Tomcat）。适合三类人看：准备做毕业设计的开发者、想把社区康复流程信息化的基层医疗人员、以及想快速搭一套「前端网页 + 后台管理」原型的Java工程师。这套系统最反直觉的一点是：它的核心难点不在算法，而在「训练题目防重复」「数据时序记录准确」「患者操作免打扰」这三个细节上。设计得当，一个中等规模的团队一两个月就能交付可用的版本；设计不当，数据表拆得再多也撑不起康复师对趋势判断的需求。下面按从架构到实现、再到避坑的顺序，把一套能跑通的最小闭环完整拆开讲。

2. 系统架构与数据模型：先把康复场景拆成表结构

做这类系统，最容易犯的错是一上来就画「用户管理」「系统管理」这类功能树，把核心的「训练—记录—评估—跟进」关系丢在一边。康复系统的业务闭环应该是：医生评估患者 → 家属给患者安排每日训练任务 → 患者完成后自动留痕 → 医生下次评估时看趋势曲线调整方案。这个闭环不先立住，代码写得再多也是边缘功能堆砌。本章先划定角色边界，再把核心表结构落到可执行的建表语句上。

2.1 角色与功能边界：先分清谁能看到什么

一套阿尔茨海默症早期康复系统里，角色至少要有三类：患者、家属、医生/评估员。患者和家属经常共用同一个浏览器访问，这点和普通管理系统很不一样，设计时必须考虑操作界面的大字体和极简步骤。角色边界划分如下：

• 患者：只进入训练页面，完成当天布置的认知训练任务，做完后看到鼓励性反馈，不接触后台数据。
• 家属：帮患者创建账号、安排训练时段、查看训练完成情况与简单趋势，异常时提醒医生。
• 医生/评估员：录入量表评估结果（如MMSE、MoCA这类通用认知评估量表），查看某位患者一段时间的训练正确率、完成时长、训练次数曲线，据此调整下一阶段的难度参数。
• 系统管理员：负责人员开通、密码重置、数据备份，不参与医疗业务。

角色权限不需要做得像Spring Security那样重，一个登录后的session角色判断加一个Filter拦截就够了。关键是把「数据归属」约束住：家属只能看自己绑定的患者数据，医生能看自己分管的多位患者，患者看完自己当天任务后落库的记录不允许自行删除。删除操作在业务层上对患者角色直接隐藏。

2.2 数据库表设计：五张表支撑一个完整康复闭环

康复系统的核心表不必多，五张表能撑起一个早期版本：用户表（含角色）、患者档案表、训练任务表、训练记录表、评估记录表。下面给出可执行的MySQL建表脚本。

-- 用户表：患者/家属/医生统一存放，用role区分 CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) UNIQUE NOT NULL, password VARCHAR(64) NOT NULL, role CHAR(1) NOT NULL DEFAULT '2', -- 1=医生 2=家属 3=患者 real_name VARCHAR(32), create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 患者档案表：与用户表通过user_id关联 CREATE TABLE t_patient ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, name VARCHAR(32) NOT NULL, gender CHAR(1), birth_date DATE, stage VARCHAR(16), -- 早中晚期，训练难度参考用 caregiver_id INT, -- 绑定家属用户ID doctor_id INT, -- 分管医生用户ID create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 训练任务表：每天给某位患者布置的一组训练 CREATE TABLE t_training_task ( id INT PRIMARY KEY AUTO_INCREMENT, patient_id INT NOT NULL, train_type CHAR(1) NOT NULL, -- 1=记忆 2=计算 3=注意力 difficulty TINYINT DEFAULT 1, -- 1低 2中 3高 status TINYINT DEFAULT 0, -- 0未开始 1已完成 task_date DATE NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 训练记录表：每次作答的明细，前端提交后逐条落库 CREATE TABLE t_training_record ( id INT PRIMARY KEY AUTO_INCREMENT, task_id INT NOT NULL, patient_id INT NOT NULL, question_id VARCHAR(16), -- 题目唯一标识 answer VARCHAR(16), is_correct TINYINT DEFAULT 0, duration_seconds INT, -- 单题耗时 create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 评估记录表：医生录入的认知量表结果 CREATE TABLE t_assessment_record ( id INT PRIMARY KEY AUTO_INCREMENT, patient_id INT NOT NULL, doctor_id INT NOT NULL, scale_name VARCHAR(32), -- 如 MMSE / MoCA score DECIMAL(5,1), assessment_date DATE, remark VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这套设计的几个关键取舍先说清楚。第一，用户表和患者档案表分开，是因为一位家属可以绑定多位患者（比如老伴和父亲），一位患者也可能有不止一位家属在照看，拆开后绑定关系更灵活。第二，训练任务表和训练记录表分开，任务是「今天该做的一组训练」，记录是「每道题做了没、对不对」，分开之后医生看完成率、看单题耗时都很方便。第三，记录表里必须有 question_id 和 duration_seconds 两个字段。前者用来排查题目是否重复，后者是判断患者注意力是否下降的重要信号——同样是记忆训练，上个月平均每题8秒，这个月涨到20秒，这就是需要人工介入的信号。

2.3 模块划分：JSP页面与后台Servlet的映射关系

界面层按「训练端」和「管理端」拆成两大模块，不用做过细的微服务划分。训练端面向患者，页面要少、字号要大、按钮要稀疏，常见的有这几个页面：

• /train/list.jsp：今日训练任务列表，患者点进来就看到今天有几组训练，每组显示难度和预计用时。
• /train/memory.jsp：记忆翻牌训练页面，牌面是水果图片，患者翻开两张找配对。
• /train/calc.jsp：计算训练页面，显示加减法算式，患者输入结果。
• /report/summary.jsp：家属和医生查看的患者进度页面，用折线图展示正确率变化。

后台Servlet按功能边界拆，一个Servlet负责一个聚合根。常见规划是：LoginServlet（登录）、PatientServlet（患者档案维护）、TrainingTaskServlet（任务下发与完成状态更新）、TrainingRecordServlet（记录上报）、AssessmentServlet（评估结果录入）。不推荐把「根据类型字段分发动作」写成一个万能ActionServlet，因为康复系统后面每加一种训练题型，都要改分发逻辑，维护成本会迅速累加。

技术选型方面，项目如果以毕业设计或内网部署为目标，JDK 8 + Tomcat 9 + MySQL 5.7是稳定组合。如果团队里有人熟悉Spring Boot，直接用Spring Boot 2.x替换Servlet层也没问题，数据模型和页面结构可以完全复用。习惯用MyBatis的加一层MyBatis，但不要在一开始就引入Mapper接口的泛型工厂这些抽象，体量用不上，反而让新手看不懂数据流向。

3. 核心功能落地：从登录鉴权到认知训练的关键实现

这一章解决的是「系统到底怎么转起来」的问题。围绕阿尔茨海默症早期康复系统的三个高频操作：登录进入系统、完成记忆训练、完成计算训练，给出具体的Servlet实现、前端交互逻辑和参数设定。所有代码都以可编译、可运行的最小版本为目标，读者在本地用Maven构建后直接部署到Tomcat即可验证。

3.1 登录与会话管理：Session + Filter 双重控制

登录是每个JavaWeb系统的入口，康复系统也不例外。因为涉及患者医疗数据，会话的管理比普通系统要严格一点：除了用户名密码校验外，还需要设置会话超时时间，并在Filter里拦截未登录请求。下面给出LoginServlet的核心代码。

@WebServlet("/login") public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException { req.setCharacterEncoding("UTF-8"); String username = req.getParameter("username").trim(); String password = req.getParameter("password").trim(); // 加盐MD5加密后与数据库比对，明文不落库 String hashed = MD5Util.md5(password + "@rehab_salt"); User user = UserDao.findByUsernameAndPassword(username, hashed); if (user == null) { resp.sendError(401, "用户名或密码错误"); return; } HttpSession session = req.getSession(); session.setAttribute("loginUser", user); session.setAttribute("role", user.getRole()); // 不同角色跳转不同首页 String home = "1".equals(user.getRole()) ? "/doctor/home.jsp" : "/patient/home.jsp"; resp.sendRedirect(req.getContextPath() + home); } }

这段代码有三个要点。第一，密码用「原密码 + 固定盐值」做MD5，不加随机盐是因为康复系统体量小，固定盐足以防住误复制数据库明文泄露的场景；但如果项目要过等保测评，需要换成BCrypt。第二，session里只存必要信息，包括用户对象和角色，不要存密码。第三，登录成功后按角色跳转不同页面，医生进入管理首页，家属和患者进入任务首页。

配套需要一个拦截未登录请求的Filter。

@WebFilter("/*") public class AuthFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; HttpSession session = request.getSession(false); String uri = request.getRequestURI(); boolean isLoginPage = uri.endsWith("login.jsp"); boolean loggedIn = (session != null && session.getAttribute("loginUser") != null); if (isLoginPage || loggedIn || uri.startsWith("/assets/")) { chain.doFilter(req, resp); } else { response.sendRedirect(request.getContextPath() + "/login.jsp"); } } }

Filter的映射范围是 /* ，意味着静态资源（CSS、JS、图片）也会被拦截，所以在放行条件里加上 /assets/ 前缀，这是新手最容易踩的拦截器误伤问题。注意「会话超时」的参数定义：在 web.xml 中配置 session-config 时，单位是分钟，综合考虑康复训练实际场景，建议配30分钟，既不至于患者中途离开太久失去数据，也不至于频繁重登打断训练节奏。

3.2 记忆训练模块：翻牌配对与防重复随机

记忆训练是早期患者最常做的认知任务，常见交互是翻牌配对，页面上展示若干张卡片，患者逐一翻开，找到相同图案的两张即配对成功。这部分的实现重点有两个：一是题目的随机生成不能每次刷新都一样，二是时长统计的起点必须从任务真正开始算。

服务端生成题目的核心逻辑如下。

@WebServlet("/training/memory/generate") public class MemoryTrainServlet extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { int difficulty = Integer.parseInt(req.getParameter("difficulty")); int pairCount = difficulty; // 1低=4张(2对) 2中=6张(3对) 3高=8张(4对) List<String> pool = Arrays.asList("apple", "banana", "grape", "peach", "strawberry", "mango", "watermelon", "orange"); Collections.shuffle(pool); List<String> selected = pool.subList(0, pairCount); List<String> cards = new ArrayList<>(); for (String item : selected) { cards.add(item); cards.add(item); // 每张图案出现两次 } Collections.shuffle(cards); // 用当前时间戳做种子，保证同一患者两次训练拿到不同排列 String seed = String.valueOf(System.currentTimeMillis()); req.getSession().setAttribute("cards_" + req.getParameter("taskId"), cards); req.getSession().setAttribute("seed_" + req.getParameter("taskId"), seed); resp.setContentType("application/json;charset=UTF-8"); resp.getWriter().write(buildJson(cards, seed)); } }

这段代码里最关键的是把牌面数组存进session而不是写死在前端。原因是：如果卡片生成逻辑只在前端JS里做，患者刷新页面后牌面顺序会变，记录上报时服务端无从判断患者到底翻了哪些牌，训练记录的可靠性和真实性就无法保证。服务端存储牌面后，每次翻牌操作的校验都由服务端比对，前端只负责把卡片渲染出来。

牌面生成之后，前端翻牌交互用原生JavaScript就够了。翻牌配对的核心逻辑如下。

let firstCard = null; let lockBoard = false; let correctPairs = 0; let totalPairs = 4; function flipCard(card) { if (lockBoard) return; if (card === firstCard) return; card.classList.add('flipped'); if (!firstCard) { firstCard = card; return; } lockBoard = true; const isMatch = firstCard.dataset.item === card.dataset.item; if (isMatch) { correctPairs++; firstCard = null; lockBoard = false; if (correctPairs === totalPairs) { // 全部配对完成，上报成绩 reportResult("finished", Date.now() - startTime); } } else { setTimeout(() => { firstCard.classList.remove('flipped'); card.classList.remove('flipped'); firstCard = null; lockBoard = false; }, 800); } }

这段逻辑要关注三个参数：配对判定的对比依据是 dataset.item 而不是卡片名称，避免不同卡片不同水果但名称相同的情况；翻牌不匹配时锁定棋盘 800毫秒，这个时间是根据早期患者的认知反应速度定的，太短患者看不清，太长训练节奏拖沓；正确配对不是 100% 的来判断，而是等所有卡片都翻开后再上报，这保证单次任务持续时长的统计完整。

3.3 计算训练模块：服务端出题与结果校验

计算训练的难度在早期康复中分为两级：低难度只出20以内加减法，中难度出两位数加减法，高难度可以加入一位数乘法。很多项目组在这个模块上翻过车，原因是把出题和判分都放到了前端，前端改一个数字就能伪造满分成绩。正确做法是每次题目由服务端生成，答案也只在服务端保存。

@WebServlet("/training/calc/next") public class CalcTrainServlet extends HttpServlet { private static final Random RANDOM = new Random(); protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { int difficulty = Integer.parseInt(req.getParameter("difficulty")); int a, b, op; boolean useAddition = RANDOM.nextBoolean(); if (difficulty == 1) { a = RANDOM.nextInt(20); b = RANDOM.nextInt(20); } else if (difficulty == 2) { a = 10 + RANDOM.nextInt(90); b = 1 + RANDOM.nextInt(99); } else { a = 2 + RANDOM.nextInt(9); b = 2 + RANDOM.nextInt(9); useAddition = false; } int answer; String display; if (difficulty >= 3) { op = 2; // 乘法 answer = a * b; display = a + " × " + b + " = ?"; } else if (useAddition) { op = 0; answer = a + b; display = a + " + " + b + " = ?"; } else { op = 1; if (a < b) { int t = a; a = b; b = t; } // 保证减法不出现负数 answer = a - b; display = a + " − " + b + " = ?"; } // 答案只存session，不返回给前端 String questionId = "calc_" + UUID.randomUUID().toString().substring(0, 8); req.getSession().setAttribute("answer_" + questionId, answer); resp.setContentType("application/json;charset=UTF-8"); resp.getWriter().write("{\"questionId\":\"" + questionId + "\",\"display\":\"" + display + "\"}"); } }

这段出题逻辑里有一个细节常被忽略：减法场景在 a < b 时交换两个数的值，保证算式永远是非负的。早期阿尔茨海默症患者对负数没有概念，出现「3−8=？」会直接卡住，训练体验会变得非常差，这是一线使用后才会发现的调整。answer 存session意味着单独一个number也会过期，所以患者长时间停留不做题，下一次作答可能拿不到答案，因此前端每次请求next后要马上渲染题目让患者尽快作答。

前端拿到题目后把 display 渲染成大号字体，患者输入答案后提交。提交接口接收 questionId 和 answer，在服务端比对session里的正确答案，写入记录表，然后返回下一题。

function submitAnswer() { const inputVal = document.getElementById("answerInput").value.trim(); if (!inputVal) return; fetch(contextPath + "/training/calc/check", { method: "POST", headers: { "Content-Type": "application/x-www-form-urlencoded" }, body: "questionId=" + currentQid + "&answer=" + inputVal }) .then(resp => resp.json()) .then(data => { document.getElementById("feedBack").innerText = data.correct ? "正确，真棒！" : "再想想看"; if (data.correct) { correctCount++; } totalCount++; if (totalCount >= 10) { reportCalcFinished(); } else { loadNextQuestion(); } }); }

每次作答都调用check接口，而不是全部做完统一提交。这保证了单题时长的记录能精确到秒，也给前端实时反馈留出了空间。患者答完一题立刻看到对错，这是康复训练中很关键的正反馈机制，比全部做完再统一看结果更能维持注意力。一组训练默认10题，难度的差异通过数字范围和运算类型体现，不通过题目数量体现——同样10题，低难度患者两分钟完成，高难度可能五分钟，这个时长差异正好可以作为康复进展的参考指标。

3.4 进度查看：训练记录的聚合查询

进度页面是家属和医生最常看的页面，也是最需要技术设计的地方。记录表里沉淀的是逐题数据，页面展示的是按天聚合的趋势。这里最忌讳的是在JSP里写复杂的循环嵌套去遍历记录并计算百分比，正确做法是服务端写好聚合SQL，页面只管展示。

SELECT task_date, ROUND(SUM(is_correct) * 100.0 / COUNT(*), 1) AS accuracy_rate, ROUND(AVG(duration_seconds), 1) AS avg_seconds_per_question, COUNT(*) AS total_questions FROM t_training_record r JOIN t_training_task t ON r.task_id = t.id WHERE r.patient_id = ? AND t.train_type = ? AND task_date BETWEEN DATE_SUB(CURDATE(), INTERVAL 14 DAY) AND CURDATE() GROUP BY task_date ORDER BY task_date ASC;

这条SQL输出的数据，直接喂给前端图表库渲染折线图。accuracy_rate 是正确率，avg_seconds_per_question 是单题平均耗时，两者放在同一张图上可以看出一个重要的康复信号：正确率平稳但耗时明显上升，往往提示注意力和反应速度在变化，需要调整训练难度或安排面诊。14天的查询窗口是康复师比较常用的观察周期，太短看不出趋势，太长数据点太密集反而不利于观察。

4. 避坑指南：JavaWeb项目最常见又最容易被忽略的五个坑

项目代码能跑通和能长期稳定运行是两回事。阿尔茨海默症早期康复系统涉及大量日期数据、患者敏感信息和定时任务，下面这五个坑是同类项目里反复出现的，按「现象→原因→解决」的顺序逐一拆开，每一条都是可以对照自查的排错清单。

4.1 连接MySQL 8.x时报驱动找不到或时间差八小时

现象：项目在本机用MySQL 5.7开发没问题，部署到服务器后数据库是MySQL 8.x，启动时直接报 ClassNotFoundException，或者能连上但时间字段差了8个小时。

原因：MySQL 8.0 开始驱动类从 com.mysql.jdbc.Driver 改成了 com.mysql.cj.jdbc.Driver，同时新版驱动强制要求JDBC URL里带上 serverTimezone 参数。很多开发者的jdbc.properties还停留在老版本的写法。

解决：把驱动升级到mysql-connector-java 8.0.33，jdbc.url加上参数。给出可直接改的配置：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/rehab_system?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 jdbc.username=root jdbc.password=your_password

参数的三个要点：serverTimezone=Asia/Shanghai 确保写入DATETIME字段的是北京时间；characterEncoding=utf8 解决中文乱码；useSSL=false 是因为内网部署不需要ssl握手，能减少连接耗时。如果服务器在云上且公网访问，才建议去掉这个参数改用SSL。

4.2 Tomcat 10 下 JSP 与 Servlet 包名不兼容

现象：用IDEA新建的JavaWeb项目默认选了Tomcat 10，代码里 import javax.servlet.http.HttpServlet 编译时报错，或者部署后启动报 NoClassDefFoundError。

原因：Tomcat 10 对应 Jakarta EE 9，Servlet API 的包名从 javax.* 整体迁移到 jakarta.*，旧的第三方库和代码如果还按 javax 写，在新容器里就找不到类。

解决：最省事的方案是换回Tomcat 9.0.x，JDK 8 + Tomcat 9 + Servlet 3.1的经典组合在社区资料最多，遇到问题搜出来基本都是可用的答案。如果坚持用Tomcat 10，需要把所有 import javax.servlet 改成 jakarta.servlet，注意是全部，包括隐式依赖的jstl标签库也要换成jakarta版本。对新手项目，我建议走换Tomcat这条路，成本最低、资料最全。

4.3 JSP页面路径404且样式全丢

现象：浏览器地址栏输入http://localhost:8080/login.jsp 能打开页面，但登录表单提交后跳转404，或者页面样式、图片全部失效。

原因：项目部署到Tomcat后有上下文路径，通常形如 /rehab_system/，直接写相对路径 action="login" 时，浏览器会把它解析成 http://localhost:8080/login，跳过了上下文路径这一层，当然404。样式失效也是同样的原因，css路径没带项目上下文。

解决：所有JSP里的跳转地址和静态资源引用都拼上 request.getContextPath()，有两种写法。在JSP页面顶部声明：

<% String ctx = request.getContextPath(); %> <link rel="stylesheet" href="<%=ctx%>/assets/css/main.css"> <form action="<%=ctx%>/login" method="post">

或者用更推荐的c:url标签，它能自动处理上下文：

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <form action="<c:url value='/login'/>" method="post">

检查时如果项目里大面积出现硬编码路径，重点排查两个地方：login.jsp 的form action，以及页面头部的css和js引用。

4.4 训练题目每次刷新都一样，患者背答案

现象：患者做了三天记忆训练，发现第三天翻开的第一张卡和第二张卡位置跟第一天完全一样，训练数据一路飘高，但医生面诊时发现患者认知水平并没有明显变化。

原因：前端逻辑是在服务端把题目列表一次性写死到JSP渲染的，顺序固定；或者随机函数每次都从同一个种子初始化，导致洗牌结果一致。

解决：把「题目生成 + 顺序洗牌」完全放到服务端，并且用当前时间戳作为随机种子。更保险的一点是，同一患者同一天内不重复生成同一组题——procedure是在生成新一组题时，先去数据库查最近一次会话的questionId集合，做一次排除。后者实现起来稍重，但训练数据的可信度会提高很多。系统里训练数据的价值完全建立在「患者没见过原题」这个前提上，这个前提一旦失效，趋势分析就全失真了。

4.5 Session超时导致训练中提交丢失

现象：患者在训练中途去喝了杯水，回来继续做完一组训练，点击提交后页面跳转登录页，刚才的10道题记录全部丢失，白做了。

原因：Tomcat默认session超时时间为30分钟，从session创建时间算起。如果患者在训练页停留超过这个时间，页面上的AJAX提交会携带一个已过期的sessionId，服务端判定未登录并重定向。

解决：方案分两层。第一层，在web.xml里适当延长超时时间到45分钟甚至60分钟，因为康复训练本身节奏慢，患者会有大量停顿：

<session-config> <session-timeout>45</session-timeout> </session-config>

第二层，也是更根本的——训练记录的提交服务不要强制校验session，可以改为「session已过期时允许提交，但标记该记录为待确认状态，患者下次登录时再确认」。这个做法在医疗记录场景里很有用，因为它保证了数据的连续性，同时在操作层面给患者一个「训练白做了」的后悔药入口。

5. 从能跑到能验收：验证方法、参数调优与进阶改造

系统开发到基本功能可用，距离真正交付还有一段路。最后这一章聚焦三件事：怎么验证训练数据的有效性、哪些参数值得在试运行后调整、以及从JavaWeb向Spring Boot迁移时怎么少走弯路。

5.1 验证清单：上线前逐项自查的十个问题

我把同类项目验收时最常被问到的检查点列成一份自查表，建议部署完成后逐条打勾。这份清单不是为了应付检查，每条背后都对应一个真实运营中可能出现的风险。

这份清单里，第四项「医生趋势图准确性」是出现频率最高的问题，多因为SQL里GROUP BY日期时没有处理时区导致日期偏移一天。验证时直接用命令行查一遍两天的数据再去页面对比，能少走很多弯路。

5.2 调整训练参数：按数据说话而不是拍脑袋

试运行两周之后，训练参数大概率需要调整。最常见的调整方向有三个：单次训练的题目数量、翻牌倒计时时长、无操作自动提交的宽限时间。给出适合的初始值和建议调整逻辑。

• 题量：计算训练默认10题，记忆训练默认4对卡片。如果患者连续三天正确率都超过90%，把计算训练题量增加到15题，记忆训练对子增加到5对；正确率低于50%则反向降低难度。
• 翻牌时间：单张卡片翻开放置的宽限期建议从15秒起步。如果平均翻牌耗时低于5秒且正确率高于90%，说明难度不够，可以减少宽限期或者增加对子数量；如果连续多次超时，说明认知负担过重，需要降低难度。
• 每日训练次数：早期患者建议每日1次完整训练即可，频率比时长重要。系统里可以在t_training_task里加一个day_count字段，超过设定次数后患者端自动显示「今日训练已完成，明天见」。

这个调整过程必须记录在系统里，不能靠口头约定。可以在t_assessment_record表里扩展一个adjust_desc字段，医生每次调整难度参数时把理由和依据填进去，后续复盘时可以看到难度调整和评估分数之间的关联。

5.3 从Servlet/JSP向Spring Boot迁移的路线图

JavaWeb项目做到中期，很多团队会考虑要不要迁到Spring Boot。以阿尔茨海默症早期康复系统的体量，迁不迁取决于一个核心问题：未来是否需要支持多个康复机构远程访问。如果只需要在内网的单台服务器上部署，Servlet/JSP方案完全够用，甚至更轻快——不需要引入一堆依赖，也不需要考虑自动配置带来的版本冲突。

但如果有以下三个信号，值得启动迁移：一是有计划给手机端做H5训练页面，需要提供RESTful接口给新前端；二是想接消息推送（比如患者当天没完成训练推送给家属），Servlet层面做定时任务和消息通道都比较笨重；三是团队后续会持续迭代，希望用更标准的工程化结构管理依赖。

迁移路线建议分三步走，不要一次性重写。第一步，把数据库访问层换成Spring JDBC或MyBatis，Service接口保持；第二步，用Spring Boot的@RestController替换Servlet入口，所有请求路径保持一致，前端页面只改请求地址；第三步，逐模块验证功能一致性后再删除旧Servlet。整个过程里最不要动的就是表结构和训练业务逻辑，这两个是系统最核心的资产，动了容易引入回归性缺陷。

训练数据是这套系统最值钱的资产。我做过几轮康复类系统，最大的教训是：页面好不好看、交互炫不炫都是次要的，真正决定系统价值的，是你记录的每次作答能不能经得起推敲。题目的随机性、时间的准确性、归属关系的严谨性，这三样守住，系统就有持续使用的价值；守不住，做得再好看也只是个玩具。希望这篇文章能帮你少踩几个坑，把这套系统做成真正能给康复人员和患者带来长期价值的东西。

本文还有配套的精品资源，点击获取