1. 项目整体设计思路拆解做医疗类管理系统尤其是眼科患者随访这种垂直场景很多人第一反应是先急着写代码。我个人的经验是真正把业务逻辑想通透比堆技术栈重要得多。这个项目前后端分离架构选了SpringBoot Vue从业务属性和团队协作角度看都是非常稳妥的选择。1.1 眼科随访的业务痛点在哪很多医院眼科的随访工作在没系统之前基本靠Excel表和微信聊天记录撑着。护士手动录入患者复查时间到了时间打电话或发短信提醒患者来复查之后再把结果填进表里。这套流程最大问题是信息断层打电话没接通没人跟进患者失联了没人溯源随访率统计全靠月底手工汇总领导要个数据得等半天。眼科随访和普通门诊随访的区别在于强周期性和细分病种差异。白内障术后要按1天、1周、1月、3月节点跟踪视力恢复青光眼患者需要终身监控眼压随访频次和用药记录必须连续近视激光手术患者关注干眼和夜间眩光眼底病患者涉及黄斑OCT复查和抗VEGF治疗周期。不同病种的随访模板完全不一样所以系统不能做成“一张表打天下”而是要提供可配置的随访计划模板。1.2 为什么选SpringBootVue这套组合技术选型这个环节我见过不少团队被“新框架崇拜”带偏。眼科随访系统本质上是典型的业务管理系统并发量不大、操作人员是医生护士、数据安全要求高、开发周期有上限。用SpringBootVue理由很实在SpringBoot生态成熟快速构建RESTful API非常顺手自带连接池、事务管理、参数校验配合MyBatis-Plus或JPA都能省掉大量样板代码。对医疗项目来说Java在数据一致性和安全方面的表现也让人放心。Vue上手曲线平滑Element UI组件库对做后台管理页面几乎是量身定做表格、表单、弹窗、日期选择器全是现成轮子。眼科护士年纪偏大操作界面必须简单直白Vue的响应式绑定让表单联动逻辑写起来很直观。前后端分离让后端不关心页面渲染前端不碰业务逻辑后续如果要加微信小程序端后端接口可以直接复用。顺带说一句SpringBoot版本不要一味追新。我项目里用的2.7.x版本稳定、资料多、踩坑答案一搜一大把对这类管理系统完全够用。1.3 系统核心角色与业务流程闭环随访系统如果只做“记录”那顶多算个电子表格。真正能落地运行的随访系统必须覆盖计划生成→任务提醒→随访执行→结果录入→异常预警→统计复盘这个完整闭环。角色上分三种医生管自己的患者看随访计划录入复查结果接收异常指标预警。护士随访专员真正高频使用系统的人负责打电话、发提醒、标记失访、登记不能遵医嘱的原因。管理员维护用户权限、配置随访模板、查看全院随访率统计。整个核心路径是这样的患者建档时录入手术日期、病种、主治医生系统根据病种对应的随访模板自动生成随访计划。到了计划日期系统在护士工作台生成待办任务同时通过短信或公众号模板消息提醒患者。护士点击任务看到这个患者本次该问哪些问题通过电话或在线问卷采集答案录入结果后决定是“按期复查”“提前复诊”还是“列为失访”。这样一套流程下来随访率、失访原因、患者依从性都能用数据说话。2. 核心功能模块与数据库建模功能拆不好后面写代码全是坑。这个系统的功能模块我建议拆成六大块患者档案、随访计划、随访任务、问卷模板、消息通知、统计报表。每一块对应的数据库表要一开始就设计到位不然后期加字段别提多痛苦。2.1 患者档案模块怎么建患者档案是主数据所有功能都围绕它转。除了基本的人口学字段眼科随访必须带上眼科学专属信息。建议字段设计字段类型说明idbigint主键medical_record_novarchar住院号/门诊号唯一索引patient_namevarchar姓名id_card_novarchar身份证号加密存储phonevarchar联系电话gender、age-基础信息diagnosis_typetinyint病种1白内障 2青光眼 3角膜屈光 4眼底病affected_eyetinyint患眼1左眼 2右眼 3双眼surgery_datedatetime手术日期primary_doctorvarchar主治医生follow_up_statustinyint状态0待随访 1随访中 2已完成 3失访身份证号加密存储这一点很容易被忽略。医疗数据属于敏感个人信息后端业务代码里直接明文存身份证肯定不行。我实际项目用的是AES加密后落库查询时支持身份证号后四位模糊检索兼顾安全和业务需求。患者列表页要支持按病种、手术日期区间、医生、随访状态组合筛选。这个功能我用的是MyBatis-Plus的LambdaQueryWrapper动态拼条件很方便。但要注意日期范围查询必须把开始时间的00:00:00和结束时间的23:59:59都算进去不然当天数据查不全这个坑排查起来特别隐蔽。2.2 随访计划与模板机制随访计划是系统最核心的业务逻辑。逻辑上分两层第一层是模板配置管理员维护某个病种从术后第几天开始随访每隔多久随访一次每次随访用哪套问卷。举个例子白内障的模板可以配置成术后1天电话随访问卷《白内障术后早期评估》术后1周复查提醒问卷《术后恢复情况》术后1月复查提醒问卷《视力恢复评估》术后3月电话随访问卷《远期效果评估》第二层是患者实例化某个具体患者做了白内障手术系统自动从模板生成该患者的随访计划列表每条计划记录计划日期、执行的随访表单类型、当前状态。这里有个细节必须注意——模板修改后已生成的计划不受影响否则医生正在执行的计划突然变了会造成数据混乱。我在计划表里冗余存储了模板快照字段模板内容JSON序列化就是为了防止模板变更引发历史数据错乱。数据库设计上随访计划表follow_up_plan关键字段patient_id、template_id、plan_date、status0待执行 1已完成 2已过期 3已取消、actual_date、follow_up_result、next_plan_id。用next_plan_id串成链表式结构完成一次随访后系统自动检查是否还存在后续计划形成链条。2.3 问卷表单的动态渲染设计眼科随访问卷每套问题都不一样有些问题还有分支逻辑——比如“是否视力模糊”选了“是”还要追问“模糊持续多久”。传统做法是每个病种写死一套页面但模板多了维护成本直线上升。我的方案是JSON Schema驱动的动态表单。问卷模板在数据库里存JSON结构[ { type: radio, label: 术后是否有视力模糊, field: blurred_vision, options: [是, 否], required: true }, { type: text, label: 视力模糊持续时间, field: blurred_duration, visibleWhen: { field: blurred_vision, value: 是 } } ]后端只负责存储模板前端Vue根据JSON递归渲染表单项。ECharts做统计图时也可以直接基于JSON结果解析。这套方案的扩展性非常强新增一套随访问卷不需要改任何后端接口和前端页面纯配置就能上线。实际开发这套动态表单花了些功夫但做完之后随访表单扩展的效率提升了不止一个级别。3. 后端SpringBoot实现要点后端我用的是经典分层架构Controller → Service → Mapper接口全部走RESTful风格。这里说说几个关键环节的实现经验和思考过程。3.1 认证鉴权怎么设计最省事内部管理系统的鉴权JWT是首选方案但要用得克制。登录成功后签发token有效期设成12小时前端每次请求放在Authorization头里。拦截器里只校验token是否存在、是否过期、Redis里有没有被注销不做太繁琐的权限逐接口配置。权限控制按角色走粗粒度医生、护士、管理员三个角色在拦截器中判断请求路径前缀。比如/api/admin/**只允许管理员访问/api/patient/**医生和护士都能访问。细粒度到按钮级别用Vue的v-permission自定义指令控制后端只保证角色边界。这里有个经验值得分享不要把用户信息全塞进JWT的payload里。我见过有人把用户名、手机号、部门全放进去占了大量字节还容易过期不更新。正确做法是payload里只放userId和角色码其他用户信息每次请求从Redis缓存里取。这样用户改手机号后马上生效不需要重新登录。3.2 定时任务引擎实现随访计划自动生成自动生成随访计划核心是靠定时任务。我用Spring的Scheduled定时扫描配合一个配置文件控制开关Component public class FollowUpPlanGenerator { Scheduled(cron ${followup.plan.gen.cron:0 0 1 * * ?}) public void generatePlans() { // 1. 查询所有手术后患者状态为进行中且没有生成完计划的 // 2. 对每个患者根据诊断类型查询对应的随访模板 // 3. 按模板规则生成随访计划去重判断避免重复生成 } }定时任务有一个非常容易踩的坑服务器重启导致任务重复触发。如果项目部署在多实例环境下Scheduled会在每个实例上都执行一遍。我的处理方案是引入Redis分布式锁抢到锁的实例才执行任务boolean locked redisTemplate.opsForValue() .setIfAbsent(lock:plan_gen, 1, Duration.ofMinutes(10)); if (!locked) return; try { // 执行计划生成 } finally { redisTemplate.delete(lock:plan_gen); }这套方案简单可靠不需要额外引入XXL-Job这类重框架。3.3 随访提醒通知怎么发通知功能我接的是阿里云短信和微信公众号模板消息两条通道。短信用于手术日和随访日前一天的提醒文案固定需要过审核的签名和模板要提前申请。公众号模板消息则需要用户在院内扫码关注公众号并绑定就诊人。消息推送模块需要特别设计一个重试机制。真实场景中短信接口偶尔超时不能因为发送失败就丢了整条记录。我的做法是在消息记录表notification_log存消息内容、接收人、渠道、状态0待发送 1成功 2失败定时任务扫描待发送和失败超过5分钟的记录重推最多重试3次。这样消息可靠性和实时性都有了保障。3.4 接口返回格式的统一封装统一返回格式这类基础工作很多初级开发觉得无所谓到后期前端联调才会发现一团乱。每个接口都返回{ code: 0, message: success, data: {} }这个结构前端在Axios拦截器里统一处理code非0就弹错误提示。我用一个全局异常处理器兜底RestControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BusinessException.class) public ResultVoid handleBusiness(BusinessException e) { return Result.fail(e.getCode(), e.getMessage()); } ExceptionHandler(Exception.class) public ResultVoid handleUnknown(Exception e) { log.error(未知异常, e); return Result.fail(500, 系统繁忙请稍后重试); } }全局异常处理有个细节要在意业务异常要返回友好提示技术异常不能直接把堆栈信息抛给前端但一定要在日志里记录完整堆栈不然生产环境出问题排查起来非常被动。4. 前端Vue实现要点前端这块老规矩先搭Vue3 Vite Element Plus Pinia的架子。Vue Router用history模式注意部署时后端需要配合做路径重写不然直接刷新就404了。我第一次用history模式部署到Nginx刷新404这个坑折腾了半天后面统一在nginx配置里加了try_files配置。4.1 前端路由与权限控制这个系统的路由有两类公开路由login和需要登录的路由。登录后从后端拉取当前用户的角色权限前端根据权限动态生成可访问的路由表用router.addRoute动态注册。这样权限控制的逻辑在前端清晰可见同时后端的接口权限仍然保留作为安全底线。动态路由这里有个实用技巧路由meta里存放菜单标题和图标侧边栏菜单直接用路由表渲染。新增一个页面只需要在路由配置里加一行菜单就自动出来了不用写两套菜单维护逻辑。4.2 Axios封装与请求拦截所有请求必须走统一的Axios实例这是前端工程化的底线。我在项目里的封装要点const service axios.create({ baseURL: /api, timeout: 15000 }); service.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer ${token}; } return config; }); service.interceptors.response.use( response { const res response.data; if (res.code ! 0) { ElMessage.error(res.message); // 登录失效统一跳转 if (res.code 401) { router.push(/login); } return Promise.reject(new Error(res.message)); } return res.data; }, error { ElMessage.error(网络异常请检查后端服务是否启动); return Promise.reject(error); } );拦截器设计上401统一处理登录失效必须要加。不然token过期后每个请求都弹一次错误提示弹窗能弹到护士崩溃。另外后端文件导出Excel下载这种需求接口返回的是blob而不是JSON拦截器里要单独加判断逻辑用responseType区分。4.3 核心页面随访工作台与动态问卷随访工作台是护士每天打开的第一个页面。放三个核心模块今日待随访任务列表高亮显示已超期任务、近期失访患者列表、随访率快捷看板。每个待随访任务卡片上放“开始随访”按钮点击弹出抽屉抽屉里是动态渲染的问卷表单。动态问卷组件我封装成递归组件核心逻辑是根据JSON里的type字段映射到Element Plus的对应组件template el-form-item :labelitem.label :requireditem.required el-radio-group v-ifitem.type radio v-modelform[item.field] el-radio v-foropt in item.options :keyopt :labelopt {{ opt }} /el-radio /el-radio-group el-input v-else-ifitem.type text v-modelform[item.field] / el-date-picker v-else-ifitem.type date v-modelform[item.field] / /el-form-item /template落地过程中有个注意点el-form的model必须用响应式对象动态表单项字段名如果不提前声明在对象里Vue3的响应式系统会丢掉新增字段的响应性。先用reactive({})初始化再循环模板字段时用form[field] default显式赋值避免页面不更新的诡异bug。4.4 统计报表的可视化呈现报表页面用ECharts画图表。我做了三个核心图按月统计的随访率柱状图、失访原因饼图、各病种随访趋势折线图。图表数据从后端统计接口按参数聚合返回前端用computed把数据转换成ECharts需要的格式。这里推荐一个实践技巧ECharts图表的option不要全部写死在组件里。封装一个useECharts组合式函数接收图类型和原始数据返回option和ref组件只管挂载和销毁。这样多个图表页面复用逻辑代码也清爽。5. 部署、安全与性能调优开发环境跑通不算完真正影响系统口碑的是部署稳定性和数据安全性。这块的经验我觉得更值得拿出来分享。5.1 Nginx反向代理与前后端部署前端打包后是纯静态文件我用Nginx托管并配置反向代理把/api前缀的请求转发到后端服务。核心配置server { listen 80; server_name your.domain.com; location / { root /opt/followup/dist; 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }try_files那一行是history路由模式刷新不404的关键。另外需要注意proxy_pass http://127.0.0.1:8080/末尾那个斜杠带斜杠表示替换掉/api前缀这个细节写错就是404或接口不通的经典原因。后端jar包用Docker部署Dockerfile里设置好JVM参数和时区。SpringBoot默认时区是UTC数据库连接串一定要配上serverTimezoneAsia/Shanghai否则日期查出来差8小时在医疗系统里日期错了可是严肃事故。5.2 数据安全与权限边界医疗数据的敏感程度比普通商业数据高。除了身份证号加密之外我还在三个层面做了控制接口层患者接口必须要有数据权限校验——护士只能看到自己负责随访的患者医生只能看到自己名下的患者管理员能看到全部。操作日志关键操作修改患者档案、导出随访数据、删除记录写入独立的操作日志表记录操作人、时间、IP和请求参数。备份策略MySQL每天凌晨自动备份备份文件保留30天。这个用系统crontab配合mysqldump脚本就能实现不花一分钱。导数据这个功能点要注意Excel导出实现。我用EasyExcel做异步导出先导出到服务器临时目录生成下载链接放到消息通知里避免大文件导出时前端请求超时。导出的字段权限和页面显示权限也要保持一致防止通过导出功能绕过权限拿到全量数据。5.3 性能优化经验随访管理系统数据量不算大但数据库查询容易写得懒散。我性能调优就做了三件事效果立竿见影患者列表查询加索引medical_record_no建唯一索引diagnosis_type和surgery_date建联合索引status建普通索引。列表接口一律分页MyBatis-Plus分页插件配置好前端传pageNum和pageSize禁止全表查。随访统计报表用SQL聚合而不是在Java内存里过滤数据。报表接口要求传时间范围SQL里直接group by两万条数据压测下来响应时间在500ms以内。缓存方面我谨慎使用Redis缓存。患者档案热点数据做了缓存但随访任务列表、统计报表这类实时性要求高的数据宁愿每次查库也不缓存避免出现护士刚录完结果列表里还是旧数据的尴尬。6. 常见问题与排查技巧实录这个项目从开发到上线踩的坑不少。整理几个最典型的给后来者提个醒。6.1 前端请求跨域问题前后端分离项目开发环境跨域问题几乎必踩。后端我配置了CorsFilter允许跨域但生产环境通过Nginx反代后不需要跨域配置因为前端请求的是同域地址。两种环境的配置方式有差异我加了一个SpringProfile区分配置开发环境允许所有跨域生产环境关闭CORS。排查跨域问题有个经验法则看浏览器Console里的报错信息。如果报Access-Control-Allow-Origin缺失是后端没配置CORS如果报404且路径正确可能是代理配置有问题而不是跨域问题。这两个方向别绕圈子能省不少时间。6.2 定时任务不执行或重复执行定时任务不执行先检查SpringBootApplication类上有没有加EnableScheduling注解。这个注解经常被漏掉而且漏了不报错任务就是静默不执行。然后检查cron表达式比较常见的坑是六位和七位表达式的区别Spring的cron是六位不像Quartz支持秒以下单位。重复执行问题如果还没有引入Redis最简单的处理方案是加一个进程内锁标记数据库唯一约束兜底。生成计划前先查询当天是否已有计划记录用数据库的唯一索引防重。这个方案在单实例部署下没有问题多实例就必须上分布式锁了。6.3 动态表单数据提交偶尔丢失动态表单最折腾的bug是护士填完问卷点击提交后端偶尔收到空数据。排查下来发现是表单里部分动态字段没有绑定到v-model的响应式对象上。前面提过的解决方式——先在reactive对象里把所有字段初始化——是最重要的防线。此外提交前在方法里用Object.keys(form)遍历一遍判断是否存在空值字段再补一次默认值双保险。6.4 日期字段的时区错乱这个问题必须单独拎出来说。数据库中存的时间是2025-06-01 08:00:00前端页面上显示的却是2025-06-01 00:00:00。这不是前端bug是Jackson序列化时区转换导致的。解决方式SpringBoot配置文件中设置spring.jackson.date-formatyyyy-MM-dd HH:mm:ss spring.jackson.time-zoneGMT8同时数据库连接串加serverTimezoneAsia/Shanghai前后端保持统一才不会出现表里查出来是一天页面上显示另一天的错乱。6.5 排查技巧速查表症状排查方向常见根因接口500看后端控制台日志堆栈空指针、参数校验没接住前端页面白屏浏览器F12看Console报错路由配置错误、JS依赖加载失败数据库连接超时检查连接池配置和数据库最大连接数连接没有释放、连接池太小JWT登录失效看Redis中token是否存在token过期时间太短、Redis数据被清7. 项目扩展与个人心得系统上线不是终点医疗业务的需求变化从来不会停。从扩展性的角度有几个方向值得提前布局。7.1 扩展方向患者小程序端微信小程序或公众号内嵌H5让患者自助填写随访问卷、查看复查提醒。需要后端接口补充微信授权登录流程复用现有患者档案做openid绑定。AI辅助随访现在可以做简单规则的自然语言处理——根据患者随访记录的语义自动生成异常标记。比如“视力下降明显”“眼压偏高”等关键词命中后自动推送预警给医生。多院区支持在患者表和用户表增加院区字段报表维度支持按院区筛选和汇总。改动不大但能显著提升系统的适用范围。7.2 我的一些体会开发这类业务系统最重要的不是炫技而是把每个业务细节都落地对。比如随访计划的生成时机、护士工作台的交互流畅度、报表统计口径的一致性……这些细节撑起来的是医生护士每天实实在在的使用体验。他们不会因为你用了什么牛逼技术点赞但会因为随访成功率真正提升而认可这个系统。如果让我重新做一次这个项目我会更早让护士参与测试在数据库设计阶段就找她们过一遍随访流程。系统最终是给医疗从业者用的他们觉得顺手这个系统才算真正成功。我遇到的最有价值的一次反馈就是护士提出“失访患者应该能一键标记原因”这个需求让统计数据维度丰富了不少也给后续优化提供了方向。