做互联网开发这几年医疗健康类的项目我接触过不少但真正从零完整做完一套“SpringBoot 微信小程序”的健康管理系统还是有很多值得沉淀的内容。这个系统功能上并不算复杂用户在小程序端录入自己的体征数据比如体重、血压、血糖、睡眠时长后端负责存储和计算再按规则给出健康建议管理员后台还能维护一些健康科普内容。可把这条链路完整跑通背后涉及的东西远比想象中多微信登录的 session 管理、体征数据的表结构设计、安全拦截器的配置、小程序端各种机型适配、包括最后部署时的 HTTPS 和域名校验每一环都能踩出坑来。这篇文章我按实际项目的脉络来复盘从需求拆解讲到数据库设计从后端核心接口写到小程序端实现最后再说上线阶段遇到的典型问题和排查思路。如果你正准备做一个类似的快速原型项目、毕业设计或者公司内部的健康管理小工具这篇文章可以直接当参考模板用。1. 项目概述与需求拆解1.1 健康管理系统到底在解决什么问题很多人一听“健康管理系统”第一反应是做一套很重的医院系统。实际上市面上真正跑得动的健康管理小程序做的都是“轻量记录 异常提醒 趋势分析”这件事。这次项目的目标用户是社区健康管理场景下的普通用户核心需求列出来其实很清晰用户注册登录不需要复杂账号体系直接微信授权登录降低使用门槛。体征记录记录体重、BMI、血压、血糖、心率、睡眠时长这些常见指标。记录查询支持按时间范围查看记录列表并展示趋势变化。健康建议根据最新体征数据自动生成提示比如“体重偏高、建议增加运动”这类文本。健康科普内容管理员在后台上传文章小程序端分类展示。我的健康档案展示个人基础信息、历史统计摘要。这个需求范围如果直接开做后端至少二十张表打底。但实际项目我做了收敛把核心表控制在 8 张以内先把主链路跑通再考虑扩展。1.2 技术选型为什么是 SpringBoot 微信小程序先说结论这个组合非常适合“中小型健康应用”的快速落地。SpringBoot 的优势不用多讲自动配置、内置容器、生态成熟。我用的是 2.7.x 版本搭配 JDK 1.8这个组合在云服务器上跑起来内存占用低、稳定性好。有朋友问我为什么不用 SpringBoot 3.x因为项目上线环境是老 CentOSJDK 8 可能没法直接升级而且很多第三方 starter 还停留在 2.x 版本没必要冒兼容性风险。微信小程序端我选了原生开发没有上 uniapp。原因是这个项目只需要服务微信生态原生框架调试方便分包、真机预览都很直接和小程序的 API 对接没有中间层减少一层抽象就少一层出问题的概率。数据库使用 MySQL 8.0缓存用了 Redis主要用于存储微信 session 状态和 token 黑名单。整体架构就是经典的前后端分离小程序端通过 HTTPS 请求访问后端 RESTful 接口后端统一返回 JSON 数据认证机制采用 JWT Redis 双重校验。2. 系统整体架构与数据库设计2.1 分层架构与项目目录规划后端项目结构我不是按“controller/service/dao”这种三层一刀切而是采用功能模块划分每个模块内再分层。这样在功能演进时能快速定位比如新增一个“运动记录”功能只需要在module/exercise目录下新增文件不会牵动全局。com.healthmanage ├── common // 通用工具、常量、异常处理 │ ├── config // 拦截器、Redis配置、跨域配置 │ ├── util // JWT工具、AES加密工具、BeanCopy工具 │ └── constant // 业务常量、错误码 ├── module │ ├── auth // 登录鉴权模块 │ │ ├── controller │ │ ├── service │ │ ├── mapper │ │ └── domain │ ├── user // 用户与健康档案模块 │ ├── record // 体征记录模块 │ ├── advice // 健康建议模块 │ └── article // 健康科普模块 ├── quartz // 定时任务 └── HealthApplication.java这种模块化结构特别适合中期维护例如给健康建议模块增加“按季节生成建议”的逻辑时完全不会碰其他模块的代码。2.2 数据库表设计与核心字段说明数据库设计是这类系统最容易返工的地方。健康数据有几个特点同一用户的数据是时间序列数据、不同指标单位不同、不同指标的记录频率也不同血压可能一天测两次体重一周测一次。所以我的方案是“一张主表 三张扩展字段表”而不是把每个指标单独建一张表。核心表结构如下用户表 t_userCREATE TABLE t_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 主键, openid VARCHAR(64) NOT NULL COMMENT 微信openid, nickname VARCHAR(64) DEFAULT COMMENT 昵称, avatar_url VARCHAR(255) DEFAULT COMMENT 头像地址, gender TINYINT DEFAULT 0 COMMENT 性别 0未知 1男 2女, birthday DATE DEFAULT NULL COMMENT 出生日期, height DECIMAL(5,2) DEFAULT NULL COMMENT 身高cm用于计算BMI, phone VARCHAR(20) DEFAULT NULL COMMENT 手机号, status TINYINT DEFAULT 1 COMMENT 状态 1正常 0禁用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;openid 是用户在微信生态里的唯一标识必须建唯一索引。注意一定不要把鞋带一样的 openid 直接暴露给前端登录后要换成自己系统生成的 userId 和 token后续接口都用 userId 操作这样即使 openid 泄露也影响有限。体征记录表 t_health_recordCREATE TABLE t_health_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT 用户ID, record_date DATE NOT NULL COMMENT 记录日期, record_type VARCHAR(20) NOT NULL COMMENT 指标类型weight/blood_pressure/blood_sugar/heart_rate/sleep, record_value DECIMAL(10,2) NOT NULL COMMENT 指标数值, systolic_pressure INT DEFAULT NULL COMMENT 收缩压血压专用, diastolic_pressure INT DEFAULT NULL COMMENT 舒张压血压专用, record_unit VARCHAR(10) DEFAULT COMMENT 单位, remark VARCHAR(255) DEFAULT COMMENT 备注如早晨空腹、运动后, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user_date (user_id, record_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT体征记录表;这里是关键设计决策用 record_type record_value 存储不同类型的指标数据。如果每个指标建一张表血压还需要收缩压和舒张压两个字段后期新增“血氧”指标又得建一张表。用这种通用表结构新增指标只需要在代码里加一个枚举值不用改表结构。但要注意通用表在查询时会有一定的性能牺牲因为只能按 record_type 过滤后查。我的做法是给(user_id, record_date, record_type)建联合索引查询时把时间范围缩小到一个月甚至一周实测一张表 50 万数据量下接口响应仍在 200ms 以内完全够用。健康建议表 t_health_adviceCREATE TABLE t_health_advice ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, advice_date DATE NOT NULL COMMENT 建议日期, advice_type VARCHAR(20) NOT NULL COMMENT 建议类型bmi_weight/blood_pressure/blood_sugar/sleep, advice_title VARCHAR(100) NOT NULL COMMENT 建议标题, advice_content TEXT NOT NULL COMMENT 建议内容, is_read TINYINT DEFAULT 0 COMMENT 是否已读, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_read (user_id, is_read) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT健康建议表;健康建议不是实时的而是每天根据用户当天最新一条体征记录生成一次存储后供小程序端展示。这样设计的好处是用户看到的建议是稳定的不会因为病情数据变化反复横跳也方便后续做推荐效果的统计。其余还有t_article健康科普、t_article_category、t_share_log分享记录等表这里不再一一贴出。总的思路就是业务表保持简单能通过字段扩展解决的不要建新表能通过联合索引解决的不要搞冗余表。3. SpringBoot 后端核心实现3.1 微信登录与 token 鉴权链路健康管理系统的核心起点是登录。这里有一个非常重要的概念小程序登录和传统网页登录不同小程序端wx.login()拿到的 code 只能在后端通过微信接口二次换 session_key 和 openid这个流程是微信安全体系的核心。后端的登录接口实现如下RestController RequestMapping(/api/auth) public class AuthController { Autowired private AuthService authService; PostMapping(/login) public ResultLoginVO login(RequestBody Validated LoginRequest request) { // request 中携带小程序端传来的 code String code request.getCode(); return Result.ok(authService.login(code)); } }Override public LoginVO login(String code) { // 1. 调用微信接口换取会话信息 WxSessionResponse session wxApi.code2Session(code); // 2. 根据 openid 查询本地用户不存在则自动注册 User user userMapper.selectByOpenid(session.getOpenid()); if (user null) { user User.builder() .openid(session.getOpenid()) .nickname(微信用户) .status(1) .build(); userMapper.insert(user); } // 3. session_key 存入 Redis有效期 7 天用于未来解密手机号 redisTemplate.opsForValue().set( wx:session: user.getId(), session.getSessionKey(), 7, TimeUnit.DAYS ); // 4. 生成自己的 JWT token 返回给小程序端 String token jwtUtil.generateToken(user.getId(), user); return new LoginVO(token, user.getId()); }这个流程里我特别要强调 session_key 的存储问题。很多人拿到 session_key 之后不知道怎么处理其实 session_key 不是每个接口都要用的只有在解密微信手机号、运动数据等敏感信息时才需要。把它存到 Redis 里并设置 7 天过期配合用户刷新登录的时机清理不会有安全漏洞。3.2 JWT 拦截器设计与权限控制登录之后如果没有一套完整的鉴权体系用户 A 很容易就能通过改请求参数查用户 B 的数据。健康数据是高度隐私的权限控制必须做到接口层面。我的做法是基于 SpringBoot 拦截器 自定义注解来做Component public class LoginInterceptor implements HandlerInterceptor { Autowired private StringRedisTemplate redisTemplate; Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (StringUtils.isBlank(token)) { throw new BizException(401, 未登录); } // 1. 解析 JWT token Long userId jwtUtil.parseUserId(token); // 2. 校验 Redis 中是否存在支持主动登出 String redisToken redisTemplate.opsForValue().get(login:token: userId); if (!token.equals(redisToken)) { throw new BizException(401, 登录已过期); } UserContext.set(userId); return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { UserContext.clear(); } }这里有个细节容易被忽略JWT 是无状态的一旦签发就无法在服务端主动让它失效。为了支持“用户退出登录”“管理员封禁账号后立即失效”这两个场景我把 token 同时存了一份到 Redis每次请求时不仅验证 JWT 签名还要校验 Redis 里的值是否一致。这样当用户点退出或者后台封禁账号时删掉 Redis 里的记录token 就自然失效了。多了一次 Redis 查询换来了服务端主动控制能力在健康系统里这个取舍非常值。资源的权限校验我通过自定义注解实现比如查询用户详情、体检建议等接口只允许本人访问Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireOwner { }public class OwnerInterceptor extends HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { Long loginUserId UserContext.getUserId(); Long targetUserId Long.parseLong(request.getHeader(X-User-Id)); if (!loginUserId.equals(targetUserId)) { throw new BizException(403, 无权访问他人健康数据); } return true; } }在 controller 方法上加上RequireOwner注解即可完成校验。注意拦截器只负责解析 token资源权限校验放在另一个拦截器里注意拦截器注册顺序否则会出现UserContext还没设置就走到资源校验的情况。3.3 体征记录接口与统计报表实现体征记录接口的设计比较直接核心是“保存记录”和“查询趋势”两个能力。保存记录时需要注意指标值的校验比如血压数值不可能只有 20。这个校验我放在 Service 层通过一个指标校验策略类来实现。每种指标都有对应的校验规则和阈值范围Component public class BloodPressureValidator implements IndicatorValidator { Override public String type() { return blood_pressure; } Override public void validate(HealthRecord record) { if (record.getSystolicPressure() null || record.getDiastolicPressure() null) { throw new BizException(血压记录必须包含收缩压和舒张压); } if (record.getSystolicPressure() 250 || record.getDiastolicPressure() 150) { throw new BizException(血压数值超出正常范围请检查后重试); } // 收缩压必须高于舒张压 if (record.getSystolicPressure() record.getDiastolicPressure()) { throw new BizException(收缩压必须高于舒张压); } } }这样后续新增指标时只需要实现 IndicatorValidator 接口并注册到 Map 中Service 层代码零改动。趋势查询接口返回两类数据按天分的记录列表和按周/月聚合的统计值。统计部分我用 MyBatis 直接写 SQL举个例子查询最近 30 天内用户每天的平均体重select idselectWeightTrend resultTypecom.healthmanage.module.record.domain.vo.WeightTrendVO SELECT record_date AS recordDate, AVG(record_value) AS avgValue, MIN(record_value) AS minValue, MAX(record_value) AS maxValue FROM t_health_record WHERE user_id #{userId} AND record_type weight AND record_date BETWEEN DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND CURDATE() GROUP BY record_date ORDER BY record_date ASC /select注意这里用了AVG聚合函数但同一用户同一天可能记录了多组体重数据。业务上我允许这种情况比如早晨和晚上各测一次但统计时会取平均值。这样对用户来说直观不会因为峰值数据导致误判。3.4 健康建议规则引擎的设计与实现生成健康建议是“管理系统”变成“智能系统”的关键。这部分我设计的不是复杂算法而是一个可配置的规则决策器。以 BMI 建议为例BMI 18.5偏瘦建议增加营养摄入补充蛋白质。BMI 18.5 ~ 23.9正常鼓励保持现有生活方式。BMI 24 ~ 27.9超重建议控制饮食、增加有氧运动。BMI 28肥胖建议去医院营养科获取专业方案。代码实现上我没有用 if-else 满天飞而是用了一个规则表结构 决策引擎。规则表字段包括指标类型、区间下限、区间上限、建议标题、建议内容模板、优先级。这样运营人员可以直接在后台配置规则不用每次修改代码重新发布。public class BmiAdviceRule implements AdviceRule { Override public String type() { return bmi_weight; } Override public AdviceResult evaluate(User user, HealthRecord latestRecord) { if (user.getHeight() null || latestRecord.getRecordValue() null) { return null; // 数据不足不生成建议 } double heightInMeter user.getHeight() / 100.0; double bmi latestRecord.getRecordValue() / (heightInMeter * heightInMeter); // 区间判断 if (bmi 18.5) { return new AdviceResult(bmi_weight, 体重偏瘦, 你的BMI为 String.format(%.1f, bmi) 属于偏瘦范围。建议适当增加优质蛋白摄入规律三餐。); } // ... 其他区间 return null; } }定时任务每天早上 8 点扫描前一天有体征记录的用户生成健康建议并写入t_health_advice小程序端可以模拟“每日健康日报”的感觉。这个功能上线后用户粘性比单纯录数据高了不少——因为每天都有新的东西可以看。4. 微信小程序端实现要点4.1 登录流程与 token 管理小程序端页面再多登录永远是第一关。原生小程序里我用的是wx.login()获取 code然后请求后端/api/auth/login获得 token把 token 存在wx.setStorageSync中。这里有一个关键细节不要每次冷启动都重新调 wx.login 换 token正确的做法是启动时先看本地有没有 token有就直接用接口请求时如果返回 401再重新走一遍登录流程。会话保持方面的代码我封装了一个request公用方法const request (url, method, data) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL url, method: method, data: data, header: { Authorization: token, Content-Type: application/json }, success: (res) { if (res.data.code 401) { // token 失效重新静默登录 handleTokenExpired().then(() { request(url, method, data).then(resolve).catch(reject) }) return } if (res.data.code ! 200) { wx.showToast({ title: res.data.msg, icon: none }) reject(res.data) return } resolve(res.data.data) }, fail: (err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }注意 header 里的Authorization值不要加额外的前缀保持和后端拦截器解析逻辑一致。这个方案虽小但在多页面跳转时能保证所有请求都走统一鉴权不用每个页面单独处理。4.2 表单录入与图表展示的细节优化健康管理离不开数据录入。小程序端我用了微信原生的picker来做血压记录里的下拉选择但体重和血糖这类需要精确数值的输入我用的是 input 加数字键盘。一个细节是小程序input typedigit在不同机型上的表现不一样iOS 上可以调出带小数点的数字键盘安卓上有些版本没有。所以我干脆用typenumber配合placeholder提示用户“如果录入整数小数位请补零”保证数据格式一致性。图表展示这块我刚开始用的是echarts-for-weixin社区维护的 echarts 小程序版本图表渲染效果好但有个痛点是包体积太大光 echarts 小程序代码就有几百 KB。后来项目上线时我把图表组件改成了 canvas 手绘折线图核心代码不到 200 行图标渲染性能反而更流畅。如果只是展示简单的趋势折线我建议别再用 echarts 了canvas 手绘完全够用还省下载体积。手绘折线图的关键代码如下主要就是根据数据最大值最小值换算坐标drawLineChart(canvasId, dates, values) { const ctx wx.createCanvasContext(canvasId, this) const width 340 const height 200 const padding 20 const minVal Math.min(...values) - 10 const maxVal Math.max(...values) 10 ctx.clearRect(0, 0, width, height) // 绘制背景参考线 ctx.setStrokeStyle(#e8e8e8) ctx.setLineWidth(1) for (let i 0; i 4; i) { const y padding (height - padding * 2) * i / 4 ctx.beginPath() ctx.moveTo(padding, y) ctx.lineTo(width - padding, y) ctx.stroke() } // 绘制折线 ctx.setStrokeStyle(#4a90d9) ctx.setLineWidth(2) ctx.beginPath() values.forEach((val, index) { const x padding (width - padding * 2) * index / (values.length - 1) const y padding (height - padding * 2) * (maxVal - val) / (maxVal - minVal) if (index 0) { ctx.moveTo(x, y) } else { ctx.lineTo(x, y) } }) ctx.stroke() ctx.draw() }注意 canvas 在真机上的渲染可能存在视网膜屏模糊问题需要在小程序配置canvas-id对应的canvas组件上开启type2d新接口。老接口wx.createCanvasContext在部分新机上已开始预警废弃迁移到canvas.getContext(2d)是大趋势建议新项目直接上 2D 接口。4.3 顶部导航栏高度适配与页面布局小程序页面在 iPhone 刘海屏、安卓全面屏、以及新增的灵动岛机型上顶部导航栏的高度都不一样。如果直接写死一个height: 64px在安卓手机上会显得特别挤在 iPhone 上又会顶到状态栏。我封装了一个工具函数获取胶囊按钮的位置信息动态计算导航栏高度const getNavBarInfo () { const systemInfo wx.getWindowInfo() const menuRect wx.getMenuButtonBoundingClientRect() const statusBarHeight systemInfo.statusBarHeight const navBarHeight (menuRect.top - statusBarHeight) * 2 menuRect.height return { statusBarHeight: statusBarHeight, navBarHeight: navBarHeight, menuRect: menuRect } }页面布局时自定义导航栏的高度直接取这两个数据拼接内容区再根据导航栏高度设置padding-top。这个方案不仅能解决布局错乱问题还能让自定义导航栏在视觉上和微信原生风格一致。另外页面的page.json中要设置navigationStyle: custom否则自定义导航栏会和系统默认导航栏叠加两层这是新手最容易踩的坑。健康报告页面的卡片式布局配合scroll-view的滚动加载在低端安卓机上我用的是wx.createIntersectionObserver监听滚动到底部来触发加载更多而不是简单绑定scrolltoupper事件这样性能上更可控。5. 项目联调、部署与性能优化5.1 本地联调环境配置小程序和后台本地联调是很多新手搞不定的环节。小程序的wx.request默认要求合法域名开发调试阶段可以在微信开发者工具里勾选“不校验合法域名”同时开启“本地设置 - 不使用缓存”这样才能连本地后端。但真机预览时这个选项不生效必须用手机和电脑在同一局域网后端监听0.0.0.0:8080并且小程序请求地址要写电脑的局域网 IP。我在后端调试时经常遇到跨域问题。小程序端的请求并不是浏览器环境所以传统 CORS 的 preflight 请求不会出现但后端还是要在配置里放开所有源避免某些 Web 端调试工具比如页面版管理后台联调时受阻Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedHeader(*); config.addAllowedMethod(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这里提醒一下生产环境不要用addAllowedOriginPattern(*)彻底放开建议把域名白名单配置到配置文件里用config.setAllowedOrigins(Arrays.asList(allowOrigins))来加载。5.2 服务器部署与 HTTPS 配置微信小程序正式版要求所有请求域名必须是 HTTPS 且经过 ICP 备案。这个流程绕不开但实际操作时要注意域名防护墙、证书更新、Nginx 反代配置三个步骤顺序不能乱。我的部署方案是在云服务器安装 Nginx 和 Docker。后端应用打成 jar 包用 Dockerfile 构建镜像运行在 8080 端口。Nginx 监听 443 端口配置 SSL 证书将/api/路径下的请求反向代理到本机的 8080。配置 HTTP 强制跳转 HTTPS。Nginx 关键配置片段如下server { listen 443 ssl; server_name api.health.example.com; ssl_certificate /etc/nginx/cert/api.health.example.com.pem; ssl_certificate_key /etc/nginx/cert/api.health.example.com.key; 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; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 60s; } }这里最容易出错的是proxy_pass的路径拼接问题。location /api/且proxy_pass http://127.0.0.1:8080;时请求/api/user/list会被代理为http://127.0.0.1:8080/api/user/list后端接口路径保持原样。但如果proxy_pass写成http://127.0.0.1:8080/;路径里的/api/会被吃掉后端就会出现 404。我的习惯是后端接口统一加/api前缀Nginx 反向代理时保持路径不变匹配规则简单明了。5.3 性能优化与安全加固健康管理系统的数据隐私级别很高上线前我把安全性能做的比较重接口加密小程序端提交敏感数据如血糖、血压时用 AES 加密 JSON body后端用密钥解密。这个方案防的是抓包工具直接获取明文但要注意前端加密一定会被逆向所以密码只作为一层基本防护核心还是 HTTPS 权限控制。敏感数据脱敏查询列表接口不返回手机号等敏感字段只在用户授权后单独接口获取。限流控制登录接口和验证码接口加简单的 Guava RateLimiter 限流防止被恶意刷。性能层面我重点优化了健康趋势接口。之前直接用select *查出所有记录再在 Java 代码里做日期分组和统计数据量小时没问题用户记录 1000 条时响应时间到了 2 秒。改用 SQL 按日期分组聚合后接口响应降到 200ms 以内。这里我体会到能用 SQL 聚合解决的就不要拉到 Java 内存里算数据库的聚合功能在健康记录这类数据上效率非常明显。6. 常见问题与排坑实录6.1 微信登录 session_key 失效问题之前线上出现过用户登录后晚上再打开小程序无法获取最新体征数据的情况。排查发现是因为我把 session_key 的过期时间设成了 2 小时而 Redis 里的 token 设置了 7 天。用户第二次请求时 token 还没过期但 session_key 已经没了解密手机号等接口就失败。解决思路session_key 的有效期不需要特别短因为它的作用是配合解密接口真正的访问控制由 token 完成。我把 session_key 过期时间重新调整为和 token 一致的 7 天并在用户重新调用wx.login时刷新 Redis 里的值。同时增加一个修复逻辑后端发现 session_key 缺失时返回特定错误码小程序端收到后重新执行wx.login。6.2 小程序真机与模拟器的行为差异这个项目让我最头疼的是wx.getWindowInfo()在模拟器和真机返回的statusBarHeight不一致。在开发者工具里显示正常的高度到 iPhone 14 Pro 上就出现刘海屏遮挡。后来统一改为用wx.getMenuButtonBoundingClientRect()拿胶囊按钮位置动态计算不再依赖模拟器的固定值。这个适配方案在真机上验证了 20 多款机型基本没有出现明显偏移。另一个差异是本地存储。模拟器里wx.setStorageSync写入的数据在代码更新后还在容易让人误以为数据清空逻辑没问题真机上用户注册并退出后旧数据没有清除会导致下一个用户登录后看到上一个用户的记录。这是因为我在用户切换时只清理了 token没有清理本地缓存的 userId 和健康数据。修复很简单登录成功时写 userId退出时wx.removeStorageSync把所有本地缓存都清掉还要在后端强校验每个请求的 userId 都是来自 token而不是请求参数避免越权风险。6.3 请求超时与连接池配置问题项目刚上线那阵有个用户反馈在弱网环境下健康数据提交经常失败。排查后发现不是后端的问题而是小程序默认请求超时时间是 60 秒但我后端连接池和数据库连接池超时设置太短Redis 读取 session_key 超时只有 200ms在服务器负载高的时候容易触发超时异常。我调整后的配置spring: datasource: hikari: connection-timeout: 30000 maximum-pool-size: 20 minimum-idle: 5 redis: timeout: 5s同时在小程序端优化了弱网体验提交按钮做了防重复点击请求前先检查wx.getNetworkType()网络类型为 none 时直接提示用户检查网络而不是让用户白等 60 秒。6.4 部署上线后的小程序审核注意事项健康管理系统归类上容易涉及“医疗器械”边界如果小程序名字里包含“医疗”“诊断”这类词微信审核会要求提供相关资质。我这次把小程序命名为“XX健康助手”主要功能定位为“健康数据记录与建议”避开了医疗诊断类目。另外涉及用户隐私的《微信小程序用户隐私保护指引》配置务必在后台填写完整收集的用户信息手机号、健康数据必须声明用途否则审核大概率被驳回。个人开发者的账号限制也要注意首次发布小程序需要个人身份认证部分健康类目可能要求企业主体这个在项目启动前就要确认否则开发完上线时发现类目不对就很被动了。在这个项目的收尾阶段我个人最大的感受是健康管理系统的技术栈虽然不是最前沿的但做好它需要认真对待三件事——数据安全、权限边界、以及移动端适配的细节。SpringBoot 和微信小程序的组合已经非常成熟项目的成败更多取决于对业务场景的理解和对细节的把控。比如 session 的持久化管理、按指标类型设计的通用表、动态导航栏高度适配这些单拎出来都是很基础的东西串起来才构成了一个稳定可用的系统。如果你也准备做类似的小程序项目我建议先把“用户登录 一项核心体征记录 列表展示”这条最小闭环跑通再逐步叠加健康建议和科普内容。最后再分享一个小技巧把健康建议的规则配置界面做出来之后你会发现运营人员自己调整规则文案和阈值比你每次改代码发版要省下大量时间这才是管理系统里“管理”二字真正的价值所在。