从社区老人健康管理这个业务场景出发，结合SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0这套组合，我陆续整理过好几个类似的信息管理系统，这个“健康信息管理系统”算是其中业务链条最完整、也最能体现全栈能力的一个。如果你正准备做Java Web方向的毕设、课设，或者想在简历里多一个有业务深度的项目，这篇分享应该能帮你省掉不少弯路。我会把从数据库建模、后端接口设计到前端页面联调的关键环节全部拆开讲，同时把实际开发中踩过的坑也一并交代清楚。

1. 项目整体设计与技术选型

1.1 业务需求拆解：社区老人健康管理到底在管什么

社区老人健康信息管理系统，听起来像是普通的增删改查，但真去梳理业务的时候会发现，它其实覆盖了“社区管理人员 + 老人家属 + 医护/管理员”三类角色的协作场景。核心要管的事情大概有这么几块：老人基本档案信息（姓名、年龄、联系方式、紧急联系人、居住地址）、健康档案信息（既往病史、过敏史、血型、医保情况）、定期体检记录（体检日期、各项指标数值）、慢病随访记录（高血压、糖尿病等慢性病的日常随访情况）、健康预警规则（如血压超标、心率异常时提醒管理人员），以及系统层面的用户登录、权限分配、操作日志等。

很多开发者容易犯的第一个错误，就是把这个系统做成“老人信息登记表”，只做了第一块和第五块，中间的健康档案和随访记录全砍掉了。但从实际项目答辩和简历筛选的角度看，健康档案、体检记录、预警规则这几个模块，恰恰是体现系统设计能力的地方，也是面试官最容易追问的场景点。比如他会问你：体检指标允许多条记录怎么设计表？历史血压数据和最近一次血压数据如何高效查询？预警规则做成配置化还是写死在代码里？这些问题在后面都会涉及。

1.2 为什么是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0

这套技术组合，近几年在Java Web项目里已经算“标准答案”了，但我还是想解释一下每个组件选它的理由，因为面试和答辩时一定会被问到。

• SpringBoot2：快速搭建项目骨架、自动配置、内嵌Tomcat，省去大量XML配置。它跟Spring Cloud、Spring Security、定时任务、邮件发送这些生态都能无缝集成，非常适合做中小型管理系统。
• MyBatis-Plus：在MyBatis基础上增强了单表CRUD、条件构造器、分页插件，项目里绝大多数单表操作不用写SQL，多表关联再手写XML，开发效率比纯MyBatis高不少。
• Vue3 + Vite + Element Plus：Vue3的Composition API在管理后台中写起来比Options API更清爽，配合Vite开发服务器，热更新几乎是秒级。
• MySQL8.0：支持窗口函数、公用表表达式（CTE），默认字符集utf8mb4，对JSON类型也有更好的支持。其实8.0的JSON字段在存储体检指标扩展项时很好用。

还有一点很关键，这个项目标题里写了“含文档”，说明设计文档、数据库说明文档、操作手册这些材料也是系统的一部分，后面第7章我会专门说这块内容怎么组织。

1.3 项目模块划分与目录设计

拿到需求后，我习惯先把后端拆成几个Maven子模块或者单模块下的多包结构。为了方便部署和演示，这个项目用的是单模块多包结构，但包名划分得很清晰：

code复制com.health.community
├── config          // 配置类：MyBatis-Plus分页插件、跨域、拦截器、定时任务
├── controller      // 控制层
├── service         // 业务层（接口 + 实现类）
├── mapper          // 数据访问层
├── entity          // 数据库实体
├── dto             // 前端交互参数对象
├── vo              // 视图返回对象，比如体检指标趋势VO
├── common          // 统一返回结果、异常处理、常量、枚举
└── utils           // JWT、日期处理等工具

前端用Vue3 + Vite创建项目后，src目录下按views、components、api、router、store、utils进行组织。这里的重点不是目录本身，而是你能否把“老人档案-体检记录-预警信息-随访记录”这条业务线的代码完整串联起来。目录清晰了，后续每加一个功能模块都有固定的套路可以套用。

2. 数据库设计：MySQL8.0下的核心表结构与关系

2.1 核心数据表设计思路

数据库设计在我看来是整个项目的地基。很多同学一开始就急着写代码，结果表结构设计不合理，后面每个接口都在凑数据，改来改去非常痛苦。这个项目的核心表我建议至少包含下面这几张：

老人基本信息表（elder）

体检记录表（health_check_record）

健康预警记录表（health_warning）

其他表，比如系统用户表（sys_user）、角色表（sys_role）、菜单权限表（sys_menu）、随访记录表（follow_record）、家属绑定表（family_bind）等，就按照常规管理系统的设计方式来就可以了。我在这里要特别强调两点：一是id_card、手机号这类查询频率高的字段要加索引，二是所有业务表都保留create_time、update_time、deleted三个通用字段，这样MyBatis-Plus的逻辑删除和自动填充功能才能派上用场。

2.2 为什么MySQL8.0 + utf8mb4对这类项目很重要

很多老项目还在用MySQL5.7或更早版本，但新项目直接上8.0，最大的感受是省心。8.0默认字符集就是utf8mb4，不需要像5.7那样单独配置才支持emoji和生僻字。老人档案里可能会出现一些生僻字姓名，如果数据库用的utf8mb3，插入就会报错。另外8.0的JSON类型做体检扩展指标很方便，比如体检时有人测了骨密度、有人测了肺功能，字段不固定，用JSON类型存起来就很灵活。

关于MySQL8.0还有一个常见坑：驱动类和连接URL都变了。老项目用com.mysql.jdbc.Driver，8.0必须用com.mysql.cj.jdbc.Driver，URL中也需要加上serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&useSSL=false这些参数，否则在连接时很容易报时区错误。

如果要快速在本地把MySQL8.0环境跑起来，我建议直接用Docker，简单省事：

bash复制docker run -d \
  --name mysql8 \
  -p 3306:3306 \
  -e MYSQL_ROOT_PASSWORD=123456 \
  -e MYSQL_DATABASE=community_health \
  mysql:8.0

这个容器启动后，再用Navicat或DataGrip连接就能看到community_health库。开发环境用Docker，生产环境用云数据库RDS，基本是这两年最常见的部署方式了。

2.3 表关系与联表查询的实用设计

表关系上，最核心的就是elder表和health_check_record表的一对多关系。按老人的维度去查体检记录，MyBatis-Plus里可以这么写分页查询：

java复制// 分页查询某个老人的体检记录
Page<HealthCheckRecord> page = new Page<>(current, size);
LambdaQueryWrapper<HealthCheckRecord> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(HealthCheckRecord::getElderId, elderId)
       .orderByDesc(HealthCheckRecord::getCheckDate);
healthCheckRecordMapper.selectPage(page, wrapper);

但更多场景下，页面列表需要显示老人姓名、年龄、所属社区这些冗余信息，这时就建议写一个自定义VO，通过XML里的联表SQL查询：

sql复制SELECT
    hcr.*,
    e.name AS elder_name,
    e.age AS elder_age,
    e.community_id
FROM health_check_record hcr
LEFT JOIN elder e ON hcr.elder_id = e.id
WHERE hcr.deleted = 0
ORDER BY hcr.check_date DESC

有人问，为什么不把所有联表查询都交给MyBatis-Plus，还是单表操作省事。我的看法是：单表查询优先用Wrapper，多表查询还是写SQL更直观，也更容易优化，MyBatis-Plus的宗旨就是“简单操作不用写SQL，复杂查询还是要会SQL”，你把这个度把握好，开发效率会非常高。

3. 后端核心实现：SpringBoot2工程搭建与业务落地

3.1 工程搭建的若干细节

用Spring Initializr创建工程时，建议选择SpringBoot 2.7.x版本，因为2.7是2.x生命周期里最稳定的版本之一，而且兼容性比2.5、2.6更好。依赖需要加入Spring Web、MySQL Driver、Lombok，后面再手动把MyBatis-Plus和JWT相关依赖加进来。

pom.xml中MyBatis-Plus的依赖要特别注意版本：

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-boot-starter</artifactId>
    <version>3.5.3.1</version>
</dependency>

这里有个常见坑：MyBatis-Plus 3.5.x和SpringBoot3.x默认结合，如果你用的SpringBoot2.7.x，必须选3.5.1或3.5.2、3.5.3.1这些兼容2.x的版本。如果不小心搞混，启动时会出现Failed to configure a DataSource或各种奇怪的ClassNotFoundException。

application.yml基础配置如下：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/community_health?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true
    username: root
    password: 123456
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

这里的allowPublicKeyRetrieval=true也很重要，MySQL8.0默认使用caching_sha2_password认证方式，某些客户端连接时会报Public Key Retrieval is not allowed。虽然这是数据库连接配置的小事，但确实是8.0换新认证插件后最常见的错误之一。

3.2 统一返回结果与全局异常处理

我做管理系统时，一定会先写一个统一返回结果类，否则每个Controller返回的数据结构五花八门，前端接起来非常痛苦。这个项目里我用了一个很简单的泛型类：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("操作成功");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

配合@RestControllerAdvice统一处理业务异常和参数校验异常，前端只需要判断code是否为200，如果不是就把message弹出提示，既减少重复代码，也方便统一控制日志记录。

Controller层的代码风格，我尽量做到“薄”，也就是Controller只负责接收参数、调用Service、返回VO，业务逻辑都下沉到Service层，这样Service层的复用性和可测试性都会更好。具体来看，比如新增体检记录时，Controller只做一件事：调用HealthCheckService.addRecord(dto)，然后在Service里判断老人是否存在、指标是否触发预警、是否需要发送通知。

3.3 健康预警的业务实现：定时扫描 + 规则判断

预警功能是这个系统里最有亮点也最容易出问题的地方。我的实现思路是：在体检记录插入和更新时，立刻做一次实时预警判断；同时再用@Scheduled定时任务，每天凌晨扫描一次近7天未处理的预警记录，把漏掉的补上。这两种方式结合，既保证了实时性，又避免漏判。

预警规则的判断逻辑比较简单，比如血压、血糖、心率的阈值表：

这个规则我建议把阈值定义成配置项或枚举，不要写死在业务逻辑里。有些同学喜欢用一连串if-else判断，虽然也能跑通，但后续维护和答辩都很尴尬。如果用枚举定义预警规则，规则本身就可以作为项目的亮点来介绍。

定时任务代码大概长这样：

java复制@Component
@EnableScheduling
@RequiredArgsConstructor
public class HealthWarningTask {

    private final ElderMapper elderMapper;
    private final HealthCheckRecordMapper recordMapper;
    private final HealthWarningMapper warningMapper;

    @Scheduled(cron = "0 0 2 * * ?")
    public void scanUnhandledWarning() {
        // 查询近7天有体检记录但未产生预警的老人
        List<HealthWarning> warnings = pendingWarningList();
        warnings.forEach(warning -> warningMapper.insert(warning));
    }
}

这里要特别注意一个问题：如果老人一天之内有多条体检记录（比如上午测了一次、下午复测了一次），每秒扫描不做去重就会出现重复预警。我的处理方式是给health_warning表加一个唯一索引(elder_id, warning_type, create_date)，这样重复插入时会直接报错，再从代码里捕获这个异常返回“该预警已存在”，结合业务语义决定是否更新时间。这个问题去重看似小事，但在实际使用中特别影响体验。

3.4 身份认证与权限控制：JWT + 拦截器方案

管理系统的权限控制我用的是JWT + Spring拦截器 + 用户角色，整体比较简单但够用。用户登录成功后，后端生成一个包含用户ID和角色的token返回给前端，前端每次请求带上Authorization: Bearer token请求头，拦截器统一校验token有效性并识别当前登录用户。

核心拦截器代码：

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String [token](https://taotoken.net?utm_source=general) = request.getHeader("Authorization");
        if (StringUtils.isNotBlank(token) && token.startsWith("Bearer ")) {
            token = token.substring(7);
        }
        try {
            Claims claims = JwtUtil.parseToken(token);
            request.setAttribute("userId", claims.get("userId"));
            request.setAttribute("role", claims.get("role"));
            return true;
        } catch (Exception e) {
            response.setStatus(401);
            response.getWriter().write("{\"code\":401,\"message\":\"登录状态已过期，请重新登录\"}");
            return false;
        }
    }
}

权限控制上，我做了两级：接口层面用@RequireRole("admin")这类自定义注解或根据用户角色在拦截器中判断是否放行；菜单显示层面，前端根据用户角色动态生成不同的菜单路由。后端的权限校验是安全底线，前端只是做体验优化，这个次序绝对不能反过来。

4. 前端Vue3实现：从工程初始化到核心页面

4.1 用Vite搭建Vue3项目并集成Element Plus

Vue3项目我都是用Vite来创建，命令很简单：

bash复制npm create vite@latest health-web -- --template vue
cd health-web
npm install
npm install vue-router@4 pinia element-plus axios

Element Plus使用全局引入还是按需引入，我建议小型后台项目直接用全局引入，开发效率高，打包体积的问题对后台项目影响不大。如果后续项目规模变大，再改成unplugin-auto-import按需引入也不迟。

main.js的关键初始配置：

javascript复制import { createApp } from 'vue'
import { createPinia } from 'pinia'
import ElementPlus from 'element-plus'
import 'element-plus/dist/index.css'
import App from './App.vue'
import router from './router'

const app = createApp(App)
app.use(createPinia())
app.use(router)
app.use(ElementPlus)
app.mount('#app')

前端工程化这步，很多初学者会卡在环境上。Node.js版本不要太高也不要太低，建议用18或20的LTS版本，npm install如果因为网络问题安装得很慢，可以用淘宝镜像源临时切一下，但项目提交时不要提交node_modules目录。

4.2 路由设计：动态路由与权限守卫

后台管理系统的路由设计，我一直采用“静态路由 + 动态路由”结合的方案。静态路由包括登录页、404页，动态路由是根据当前登录用户的角色从后端获取菜单权限后动态注册的路由。

Pinia里存储一个menus状态，登录后请求后端接口拿到当前用户的菜单列表：

javascript复制export const useUserStore = defineStore('user', {
  state: () => ({
    token: localStorage.getItem('token') || '',
    userInfo: {},
    menus: []
  }),
  actions: {
    async fetchUserInfo() {
      const res = await getUserInfoApi()
      this.userInfo = res.data.userInfo
      this.menus = res.data.menus
    }
  }
})

路由守卫里做权限判断：

javascript复制router.beforeEach(async (to, from, next) => {
  const userStore = useUserStore()
  if (!userStore.token && to.path !== '/login') {
    next('/login')
    return
  }
  if (userStore.token && !userStore.userInfo.username) {
    await userStore.fetchUserInfo()
    // 动态注册路由
    const dynamicRoutes = generateRoutes(userStore.menus)
    dynamicRoutes.forEach(route => router.addRoute(route))
  }
  next()
})

这里有个开发时很容易踩的坑：动态路由已经注册了，但刷新页面后菜单和路由丢失，页面直接白屏或404。原因是因为Pinia里的状态在刷新后清空，需要在路由守卫里重新加载用户信息和动态路由。所以每次路由跳转前都要判断userStore.userInfo是否为空，为空就先加载再放行。这个问题我在自己做后台时遇到过好几次，几乎每个用动态路由的方案都会碰到。

顺便提一下，Vue3 Router有几种模式，默认是createWebHistory，这种模式在静态服务器部署时，刷新二级页面会出现404，需要在nginx里配置try_files $uri $uri/ /index.html;，开发时则没问题。如果不想配nginx，就用createWebHashHistory，虽然URL里多个#号，但部署省事。

4.3 老人健康档案页面：表格、搜索、表单弹窗一套流程

以老人列表页为例子，前端页面主要分三块：搜索区（老人姓名、社区、状态）、表格区（老人基本信息和操作按钮）、弹窗表单区（新增/编辑老人）。

表格区用Element Plus的el-table，绑定后端分页接口返回的数据：

vue复制<el-table :data="tableData" v-loading="loading" border stripe>
  <el-table-column prop="name" label="姓名" width="120" />
  <el-table-column prop="gender" label="性别" width="80">
    <template #default="{ row }">
      <el-tag :type="row.gender === 1 ? '' : 'info'">
        {{ row.gender === 1 ? '男' : '女' }}
      </el-tag>
    </template>
  </el-table-column>
  <el-table-column prop="age" label="年龄" width="80" />
  <el-table-column prop="phone" label="联系电话" width="130" />
  <el-table-column prop="address" label="居住地址" show-overflow-tooltip />
  <el-table-column label="操作" width="260" fixed="right">
    <template #default="{ row }">
      <el-button type="primary" link @click="openDetail(row)">详情</el-button>
      <el-button type="primary" link @click="openEdit(row)">编辑</el-button>
      <el-button type="primary" link @click="viewRecords(row)">体检记录</el-button>
    </template>
  </el-table-column>
</el-table>

分页用el-pagination组件，需要注意:total="total"、v-model:current-page="queryParam.current"、v-model:page-size="queryParam.size"这几个绑定的区别。实际操作中表单校验用el-form的rules属性，身份证号、手机号、年龄范围都写上正则校验，既让数据更规范，也能在项目展示时加分。

4.4 体检指标趋势图：ECharts可视化展示

体检记录页面除了列表外，我还加了一个“最近10次血压趋势”的图表，用的ECharts。这个功能并不复杂，但视觉效果很好，适合作为项目演示时的亮点。

关键是后端提供一个接口，返回最近N次体检记录的日期和血压数据：

java复制@Override
public List<BloodPressureTrendVO> getBloodPressureTrend(Long elderId, Integer limit) {
    LambdaQueryWrapper<HealthCheckRecord> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(HealthCheckRecord::getElderId, elderId)
           .orderByDesc(HealthCheckRecord::getCheckDate)
           .last("LIMIT " + limit);
    List<HealthCheckRecord> records = recordMapper.selectList(wrapper);
    // 逆序排列，让日期从左到右由旧到新
    Collections.reverse(records);
    List<BloodPressureTrendVO> result = records.stream().map(record -> {
        BloodPressureTrendVO vo = new BloodPressureTrendVO();
        vo.setCheckDate(record.getCheckDate().toString());
        vo.setHigh(record.getBloodPressureHigh());
        vo.setLow(record.getBloodPressureLow());
        return vo;
    }).collect(Collectors.toList());
    return result;
}

前端再把这些数据交给ECharts渲染，用双折线分别显示收缩压和舒张压，正常人看起来非常直观。如果不想额外拉ECharts依赖，也可以用Element Plus里的el-progress或简单的CSS柱状图代替，但趋势图我认为更符合“健康管理系统”的气质。这里需要提醒一下，ECharts5.x按需引入和完整引入的体积差别比较大，后台管理项目直接用完整引入就行，别为了优化而引入一堆模块管理代码，反而降低了开发速度。

4.5 Vue3开发中的几个小技巧与常见问题

第一，vue-quill-editor在Vue3项目里直接使用会有兼容问题。如果你要在随访记录或健康建议里用到富文本编辑器，建议用@vueup/vue-quill这个Vue3版本，或者直接用wangeditor的Vue3版本，都亲测可用。

第二，Vue3的自定义指令很方便。比如做权限控制时，我定义了一个v-permission指令，在按钮上控制是否有权限显示：

javascript复制app.directive('permission', {
  mounted(el, binding) {
    const userStore = useUserStore()
    const requiredPermission = binding.value
    if (!userStore.permissions.includes(requiredPermission)) {
      el.parentNode?.removeChild(el)
    }
  }
})

第三，Vue3的computed在编辑弹窗时特别好用。比如新增体检记录时，页面要根据录入的身高体重自动计算BMI指数，并显示在界面上：

javascript复制const bmiValue = computed(() => {
  const heightInMeter = formData.height / 100
  if (!heightInMeter) return 0
  return (formData.weight / (heightInMeter * heightInMeter)).toFixed(2)
})

这种实时计算逻辑用computed写是真的方便，数据变化自动重新计算，不需要额外监听。

第四，Vue3里调用子组件方法或者跨层组件通信，用defineExpose配合ref就很方便，不需要动不动就上全局状态管理。只有像用户信息、菜单列表这样的全局状态才需要放Pinia里。

5. 一条核心业务链路：从老人建档到预警处理的全流程

5.1 操作流程串联

如果只用一句话概括这个系统是做什么的，那就是——通过健康数据采集和规则判断，帮社区管理人员及时发现老人的健康风险。所以整条核心业务链路应该是完整的：

1. 社区管理员登录系统，在“老人档案”页面登记老人基本信息和既往病史。
2. 录入老人的体检记录（身高、体重、血压、心率、血糖等），系统在保存时自动判断指标是否异常。
3. 如果某指标超出阈值，自动生成一条健康预警记录，预警列表同步出现待办。
4. 社区管理人员看到预警后，在预警列表点击“处理”，填写处理结果，比如：已通知家属、建议复查、电话随访等。
5. 如果老人患有慢性病，管理人员定期在“随访记录”里添加随访情况，形成连续的健康管理闭环。

在这个链路里，老人档案是基础数据，体检记录是动态数据，预警记录是分析结果，随访记录是后续干预行为。四块数据有机构成了一个真正可用的业务闭环，而不是零散的增删改查。

5.2 新增体检记录时触发预警的代码实现

核心逻辑放在Service层，完整代码我简化如下：

java复制@Transactional(rollbackFor = Exception.class)
public void addRecord(HealthCheckRecordDTO dto) {
    // 1. 校验老人是否存在
    Elder elder = elderMapper.selectById(dto.getElderId());
    if (elder == null) {
        throw new BusinessException("老人不存在");
    }

    // 2. 保存体检记录
    HealthCheckRecord record = new HealthCheckRecord();
    BeanUtils.copyProperties(dto, record);
    record.setCreateTime(LocalDateTime.now());
    record.setUpdateTime(LocalDateTime.now());
    recordMapper.insert(record);

    // 3. 判断是否触发预警
    List<HealthWarning> warnings = HealthWarningRule.check(record);
    for (HealthWarning warning : warnings) {
        warning.setElderId(elder.getId());
        warning.setStatus(0);
        warning.setCreateTime(LocalDateTime.now());
        try {
            warningMapper.insert(warning);
        } catch (DuplicateKeyException e) {
            // 同一老人同一天同一类型预警如果已存在，则跳过
        }
    }
}

这里用到的HealthWarningRule.check是预警规则类的静态方法，根据体检记录的指标值返回一个或多个预警对象，业务层只负责编排，规则判断封装在独立类里。这样预警规则即使要调整，也不需要动主要业务流程，代码结构清晰，也方便测试人员针对不同指标组合写测试用例。

5.3 预警列表的处理流程

预警列表页面支持按老人姓名搜索、按预警级别筛选，还支持批量处理。批量处理的话，后端接口接收一批预警ID和处理结果，循环更新状态：

java复制@PostMapping("/batchHandle")
public Result<Void> batchHandle(@RequestBody BatchHandleDTO dto) {
    dto.getIds().forEach(id -> {
        HealthWarning warning = new HealthWarning();
        warning.setId(id);
        warning.setStatus(1);
        warning.setHandleUser(dto.getHandleUserId());
        warning.setHandleResult(dto.getHandleResult());
        warning.setUpdateTime(LocalDateTime.now());
        warningMapper.updateById(warning);
    });
    return Result.success(null);
}

这个接口虽然业务不复杂，但演示的时候能明显提升系统的“完成度”。面试时描述这个功能，可以强调“预警任务的批量流转处理缩短了社区管理人员对健康异常老人的响应时间”，这个价值点比“我写了个状态更新接口”听起来有分量得多。

6. 常见问题与排查技巧实录

6.1 数据库连接与MySQL8.0时区问题

我见过很多同学第一次连MySQL8.0时都卡在连接这一步，报错大致是The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized或者Could not create connection to database server。

解决办法就是在JDBC URL里显式指定时区和编码：

properties复制jdbc:mysql://localhost:3306/community_health?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true

如果你用的是Docker部署的MySQL8.0，进入容器查看时区：

bash复制docker exec -it mysql8 mysql -uroot -p

在MySQL命令行里执行SELECT NOW();，如果返回的时间和你本地时间不一致，就需要在容器启动时加-e TZ=Asia/Shanghai环境变量。这种问题和SpringBoot本身关系不大，但排查起来确实费时间，我自己也被坑过，所以这里特意写出来提醒。

6.2 MyBatis-Plus字段映射与逻辑删除

MyBatis-Plus默认开启map-underscore-to-camel-case=true，数据库字段create_time会自动映射到实体属性createTime。但如果你在XML里写自定义SQL，返回的结果映射就需要在XML中配置好resultMap，或者保证SQL别名的驼峰和实体属性一致。

逻辑删除这块，我遇到最多的问题是：配置了logic-delete-field: deleted，但自定义SQL里查询还是把已删除的数据查出来了。这是因为逻辑删除只对MyBatis-Plus内置方法生效，比如selectById、selectList，它会在SQL后面自动追加deleted=0。但你自己在XML里写的select * from elder不会自动追加。解决方法是手写SQL时，在where条件里也加上deleted = 0，或者直接复用MyBatis-Plus生成的SQL。

还有一个大家比较容易忽略的细节：数据库字段is_deleted、deleted这种布尔语义字段，在Java实体里如果用Integer类型，MyBatis-Plus配置逻辑删除值时必须是数字，logic-delete-value: 1、logic-not-delete-value: 0。如果你用了Boolean类型，配置逻辑上要改写成true/false，否则也会出现意想不到的映射问题。

6.3 跨域问题与前端联调

前后端分离部署时，跨域问题几乎一定会遇到。前端的请求端口是5173（Vite默认），后端接口是8080，浏览器会直接拦截跨域请求。解决方式有两种：

第一种，后端配置CORS跨域：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

第二种，前端在Vite的vite.config.js里配置代理：

javascript复制export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true
      }
    }
  }
})

这两种方案我推荐第二种，因为生产环境前端部署到Nginx也常用反向代理转发接口，思路一致。但要注意配置了代理后，前端请求的baseURL应写成/api，而不是http://localhost:8080，否则代理不会生效。经常有同学改了代理不生效，其实就是请求地址没有走代理前缀。

6.4 前端构建打包后的部署问题

开发完成以后，前端执行npm run build会在dist目录下生成静态文件，后端SpringBoot项目则需要打成Jar包。部署方案有几种，最简单的是把dist目录放到SpringBoot项目的src/main/resources/static目录下，然后统一打成Jar包，这样访问Tomcat端口就能看到整个系统。缺点是如果前后端想分开部署就不灵活；优点是学生项目、演示项目非常方便，进程少，不容易出错。

正式一点的部署方案是前端dist丢到Nginx的html目录，后端Jar包独立跑在8080端口，Nginx配置代理转发api请求：

nginx复制server {
    listen 80;
    server_name your-domain.com;

    location / {
        root /usr/share/nginx/html;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里涉及一个相对路径和绝对路径的问题，建议前端请求接口时统一用相对路径，比如/api/user/login，这样不管部署在哪个域名下，都能通过Nginx代理正确转发。否则硬编码http://localhost:8080，部署到服务器上还得改代码重新打包，非常麻烦。

6.5 启动失败常见原因速查表

这个表是我在实际项目中遇到频率最高的几类问题，基本上每个新项目启动时都会碰上一两样。建议遇到报错时先看完整堆栈，不要只看第一行，很多时候关键信息在底下caused by那一堆里。比如mybatis启动报错经常是XML文件少了某个标签属性，页面上报错信息却只显示一个笼统的BindException。

7. 含文档的项目材料如何组织才加分

7.1 文档内容概览与写作思路

这个项目标题里特别写了“含文档”，所以文档质量也是项目的一部分。虽然我不是专门做文档岗位的，但写多了以后，我觉得一份能帮助别人看懂项目的文档，至少应该包含四个部分：

• 项目说明文档：项目背景、业务范围、技术栈选择理由、模块功能介绍。
• 数据库设计文档：核心表结构说明、E-R图、字段含义、索引设计。
• 接口文档：主要接口的请求方式、参数说明、返回值示例。
• 部署运行文档：环境要求、数据库初始化SQL、前后端启动步骤、常见问题。

这里我要强调，数据库设计文档不只贴一张建表SQL就完事，应该把每个表的核心字段含义写清楚，比如status有哪几个枚举值，0代表什么、1代表什么。这类信息只有设计者自己最清楚，其他人在接手项目时最缺的也是这种说明。

7.2 如何用示例数据提升系统可用性

项目演示时最怕空数据演示，展示效果大打折扣。我建议在数据库初始化脚本里附带一部分模拟数据：比如10位老人信息、每位老人3-5次体检记录、若干条预警记录、一个管理员账号。这样打开系统后能看到完整的数据效果，趋势图也有折线可以展示，预警列表也不是空荡荡的。

模拟数据也有讲究：体检指标要“一半正常、一半有异常”，这样才能展示预警功能；年龄范围建议覆盖60岁到85岁，更接近真实社区场景；紧急联系人电话、身份证号要用虚构的格式正确的号码，不要用真实信息。这样演示时随手点开一个老人，就能看到他的健康档案和趋势图，比临时造数据自然得多。

8. 适用于Java Web项目的架构复盘与可扩展方向

8.1 如果换成微服务架构，这个系统该怎么拆分

如果后续有扩展需求，比如加了一个“用药提醒系统”或“护工排班系统”，这个单体项目可以按业务域拆分成几个微服务模块。当然对于这个体量的项目，我个人不建议一上来就上微服务，除非你面试时想展示自己对微服务的理解。比较合理的拆分度是：老人档案管理服务、体检健康数据服务、预警与通知服务、系统用户权限服务。SpringCloud Alibaba的Nacos做注册中心，OpenFeign做服务间调用，网关用Spring Cloud Gateway。

关于高并发场景，这种社区健康管理系统的并发量不会特别高，但是体检季的时候，多个社区同时录入体检数据，写入和查询压力会明显上升。优化的思路一般是：MySQL读写分离 + Redis缓存老人档案热点数据 + 定时任务异步处理预警通知。先做好索引和SQL优化，再上缓存，按性价比排序，不要一上来就堆中间件。

8.2 能力扩展建议：给系统添上更智能的玩法

如果你想在毕设或项目展示时增加一些亮点，可以考虑以下几个方向的扩展：

• 老人标签画像：根据体检指标和随访记录自动生成健康等级标签，比如“血压偏高”、“血糖偏高”、“需重点关注”。
• 报告导出功能：按老人导出PDF版健康报告，用OpenPDF或iText实现，很多社区确实需要纸质档案。
• 消息通知渠道：预警产生时通过钉钉机器人或企业微信通知家属，或者发送短信，这种场景在社区养老场景很常见。
• 移动端适配：不用单独开发APP，做一个H5版本的家属端，或者直接适配微信小程序，让家属查询老人健康数据。

这里面我认为消息通知是最有实际落地价值的扩展。社区管理人员不可能一直盯着系统看，预警产生后如果能通过钉钉或短信通知到人，系统的闭环才算真正完整。

9. 一些实际的开发体会

这套系统我前前后后带过好几个同学完整做过，每次做都有新的感受。第一个体会是，做管理和信息类项目，最花时间的并不是写代码本身，而是把业务边界理清理顺。比如“体检记录”和“随访记录”到底什么关系，“预警”是自动产生还是手动添加，这些一开始就要和项目定义的人确认清楚，否则后面返工非常难受。

第二个体会是，Java Web项目的学习曲线其实可以很短，关键是不要在框架的细枝末节里陷得太深。快速把SpringBoot + Vue3 + MyBatis-Plus这一套打通，让数据从数据库显示到页面上，先把主流程跑通，再回头做优化和补功能，你会更有成就感，也更不容易放弃。

第三个体会是，文档的写法尽量按照“能复现”的标准来。你写下来的每一句“为什么选择这个设计”，将来都有可能成为答辩时的“为什么这样实现”答案。数据库设计、接口设计、权限设计这些内容在文档里讲清楚，项目完成度会整整高一个档次，面试官或答辩老师很容易看得出你是真正做了完整思考的。

最后一个小技巧：在开发前，把系统里所有页面和接口列成一张表，前端页面对应后端的接口路径、请求方式、参数，每次开发完一个模块就勾掉一项。这样项目进度一目了然，也不会做到一半发现有功能遗漏。我自己做这类系统一直用这个方法，实测非常管用。