从PHP到小程序：旅居养老健康档案系统开发实战-北京尧图网络

去年年中我们团队接手了一个旅居养老项目里的健康档案系统开发技术栈瞄准 PHP 后端小程序端。项目基地在一个以长寿闻名的山区县老人从全国各地过来有人夏天去北方避暑冬天再回到这边住一两周、几个月甚至半年。运营方最初的需求描述很简短“做一个老年人健康档案系统小程序上能申请建档、能填健康信息、每天能记录体温血压就行。”等我把真实业务场景拆开看才发现这句话背后全是细节。这篇文章就完整复盘一下从需求梳理、数据库设计、接口实现到上线后踩过的坑和思路转变给准备在旅居养老领域做小程序的人一份可参考的实战记录。1. 先把业务盘清楚旅居养老的健康档案到底特殊在哪1.1 档案不是“建出来”的是“跟着人走”的很多做养老系统的人第一反应是参考养老院的健康档案系统老人入住时填一张表建立院内档案护士每天记录数据在机构内部闭环。这套逻辑对“固定居住”的养老院没问题但放到旅居养老场景里第一个冲突就出现了——老人不是固定在一个院区的。我们项目里的老人一年里可能住过三个基地某康养县住三个月海南一个合作基地住两个月夏天又回到北方某避暑基地。如果他第一次在 A 基地建档第二次去 B 基地的时候B 基地的护士对这位老人的过敏史、既往病史、用药情况一无所知。老人自己说不清楚家属也不一定在跟前这时候唯一可靠的来源就是 A 基地建的那份档案。于是核心需求浮出水面档案的主语是老人不是机构。所有基地共享同一份老人档案但不同基地只维护各自产生的健康记录。老人流动档案跟着走新的记录也要能回到主档案里。围绕这个核心业务流程就清晰了老人或家属通过小程序提交入住申请同时填写健康档案。基地前台审核申请确认入住后激活档案。护理员在小程序里每日记录体温、血压、心率等体征。系统对异常指标自动标记提示护理员关注。老人离店或转场到其他基地时档案状态切换下个基地可直接调阅。运营后台按基地、按时间段汇总健康数据。后来我把这套流程写成原型给运营方看对方才意识到他们要的不是“又一个表单系统”而是一套能跟随老人流转的档案机制。1.2 参与角色与权限边界每一类人看到的东西完全不同旅居养老的健康档案使用角色比普通养老院更杂。除了老人本人还有代为操作的家属、现场接待的前台、每天测体征的护理员、负责健康管理的护士或健康管理员、以及统筹各基地的运营负责人。每类角色关注的东西完全不同这一点直接影响权限设计。我整理过一张角色关注点对照表角色最关心的内容使用频率老人/家属建过的档案下次不用重复填、子女能远程看到父母健康状态低频前台接待入住申请是否通过、档案是否完整中频护理员今天哪些老人需要测体征、有没有异常指标、有没有忌口高频健康管理员指标变化趋势、是否建议转诊、用药提醒中频基地负责人本基地健康档案覆盖率、异常上报率低频平台管理员全基地数据维护角色权限、配置字典低频当时运营方特意强调标题里提到的“申请老年人健康档案系统”指的并不是老人跑到某个机构“申请补贴”那种申请而是**“申请建立个人健康档案”**这个动作。这点必须提前确认因为如果是政府补贴导向流程里通常要接实名认证、审批单、材料上传如果是入住导向流程就是“填表—审核—入住—持续记录”完全是两套设计。提示需求方说“做一个申请健康档案的功能”时一定要追问一句谁申请为了什么申请我们来来回回改了两版就是因为一开始默认是老人主动申请后来发现大部分实际操作都由家属或前台代办。2. 技术选型小程序项目里坚持用 PHP理由是什么2.1 不追新框架先看现有体系老实说2024 年、2025 年再开一个新项目很多人默认会用 Java、Go或者 Node.js。但我们的情况不一样运营方已经有一个跑了两年的 PHP 管理后台基于 ThinkPHP 6 开发财务、人事、床位管理都在里面。如果小程序后端另起炉灶会出现两个系统、两套用户体系、两个健康数据库维护成本直接翻倍。最终决定继续用 PHP 做 API 层理由很现实共用现有权限模型后台已经有管理员角色和菜单权限扩一套 API 鉴权成本低。团队维护成本低当时的维护开发更熟悉 PHP招人也容易。长连接业务不重健康档案系统是典型的 CRUD 状态流转没有高并发实时通信PHP 完全撑得住。PHP 在这套系统里只做接口服务不做服务端渲染页面。小程序端选择的是 uni-app因为运营方后续还想出 H5 版和钉钉工作台入口一套代码多端复用省不少事。2.2 前后端分离下的数据流与接口约定整体架构是经典的前后端分离小程序端uni-app→ HTTPS → Nginx → PHP-FPM → ThinkPHP 6 路由 → Service 层 → MySQL / Redis接口统一走 RESTful 风格返回 JSON。我定的响应结构是三段式{ code: 0, message: ok, data: {} }code 为 0 表示成功非 0 表示业务错误。这样小程序端可以封装一个统一的请求拦截器遇到 code 401 自动跳登录遇到其他错误统一弹 toast不需要每个页面单独处理错误状态。PHP 端对应有一个基础控制器方法?php protected function success($data [], string $message ok): \think\Response { return json([ code 0, message $message, data $data, ]); } protected function error(string $message, int $code 1): \think\Response { return json([ code $code, message $message, data null, ]); }小程序端我用 uni.request 封装了一个request.js统一处理 baseURL、token、错误码。这里有一个容易忽略的细节开发阶段 baseURL 可以直接填http://localhost或局域网 IP 测试但打包预览到真机时必须改成线上 HTTPS 域名否则会被拦。后面我在部署坑那节里会专门讲。3. 数据库设计三个核心表的背后逻辑3.1 老人基础档案表全局唯一合并去重健康档案系统最重要的表是“老人基础档案表”。它描述的是老人本身而不是某一次入住。我在项目里用的表名是elder_health_profile核心字段如下字段名类型说明profile_idbigint 主键全局唯一档案 IDopenidvarchar(64)关联的小程序账号允许为空因为老人可能没有微信real_namevarchar(50)姓名id_card_hashchar(64)身份证号哈希值用于防重复建档gendertinyint性别birth_datedate出生日期phonevarchar(20)联系电话入库前端做脱敏emergency_contactvarchar(50)紧急联系人emergency_phonevarchar(20)紧急联系人电话medical_historytext既往病史JSON 数组字符串allergyvarchar(255)过敏史必须明确填“无”或具体过敏源current_medicationtext当前用药情况blood_typevarchar(10)血型statustinyint状态1 草稿2 待审核3 已建档4 已驳回created_at / updated_atdatetime时间戳身份证号为什么不直接存因为健康档案是敏感数据按个人信息保护合规要求能不做明文留存就不做明文留存。我的做法是用 SHA-256 对身份证号做哈希索引这个哈希来判断“这个人是否已经建过档”降低重复建档概率。实际业务中还要配合姓名、手机号做二次核对因为哈希理论上存在碰撞虽然概率极低但不能只靠它判断。手机号则在展示层做脱敏比如只显示138****1234。3.2 健康记录表用通用字段接住日常体征老人每天的体温、血压、心率、血糖、体重都属于体征记录。我一开始想过把体温、血压、心率、血糖、体重各建一列后来发现老人的记录经常有“今天只测了血压”“昨天做了个额外血糖”这种不均匀情况于是采用了一个相对固定的宽表但把非核心项作为可空字段CREATE TABLE health_records ( record_id bigint unsigned NOT NULL AUTO_INCREMENT, profile_id bigint unsigned NOT NULL COMMENT 老人档案ID, base_id bigint unsigned NOT NULL COMMENT 基地ID, record_date date NOT NULL COMMENT 记录日期, record_type tinyint NOT NULL DEFAULT 1 COMMENT 1 常规体征 2 补充记录 3 异常记录, temperature decimal(4,1) DEFAULT NULL COMMENT 体温, heart_rate int DEFAULT NULL COMMENT 心率, blood_pressure_high int DEFAULT NULL COMMENT 收缩压, blood_pressure_low int DEFAULT NULL COMMENT 舒张压, blood_sugar decimal(4,1) DEFAULT NULL COMMENT 血糖, weight decimal(5,1) DEFAULT NULL COMMENT 体重, notes varchar(500) DEFAULT NULL COMMENT 备注, operator_id bigint unsigned DEFAULT NULL COMMENT 操作人用户ID, created_at datetime DEFAULT NULL, PRIMARY KEY (record_id), UNIQUE KEY uk_record_daily (profile_id, base_id, record_date, record_type), KEY idx_base_date (base_id, record_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT老人健康体征记录表;这里设置联合唯一键uk_record_daily是后面幂等设计的基础。同一老人同一基地同一天同一类型的记录只能存在一条重复提交会被数据库挡住。后面接口层再做一层业务判断双保险。为什么要冗余一个base_id因为各基地要独立统计报表而且护理员只能看本基地的记录频繁按老人档案维度关联查询会很慢。冗余基地 ID 是典型的空间换时间还能顺带做数据隔离过滤。3.3 基地流转记录表游客住店式关联第三张核心表是老人与基地的流转关系表我命名为resident_stays。它的作用类似酒店的入住记录字段名类型说明stay_idbigint 主键一条入住流水profile_idbigint档案 IDbase_idbigint基地 IDcheck_in_datedate入住日期check_out_datedate离店日期可空room_novarchar(20)房号source_typetinyint来源1 小程序申请 2 线下办理 3 其他基地转场statustinyint状态1 在住 2 已离店 3 已转场有了这张表之前说的“档案跟着人走”就落地了调阅老人档案时主表负责老人的静态信息health_records按profile_id查全部健康记录resident_stays负责展示他住过哪些基地、入住时间、居住地点。业务要什么都能从这三张表组合出来。后来第二个合作基地上线时我们做“迁移档案”只写了一个导出导入脚本没动任何表结构。因为当初设计就是“以老人为中心”基地只是外层维度。4. 小程序端与 PHP 接口的实现细节4.1 登录态微信用户与老人档案的安全绑定小程序不能像网页那么简单地用账号密码登录标准流程是小程序端调用wx.login()拿到临时code。把code传给后端接口。后端拿code调用微信接口换openid和session_key。后端在用户表里查找该openid不存在就创建一条用户记录。后端生成自己的token返回给小程序端小程序端存起来后续请求通过请求头携带。这里有一个铁律小程序的appid和secret绝不能放在前端代码里换 openid 的接口必须由后端调用。我把code2session这个逻辑放在了 PHP 的 Service 层代码如下?php public function code2session(string $code): array { $appId $this-config[mini_app_id]; $secret $this-config[mini_app_secret]; $url sprintf( https://api.weixin.qq.com/sns/jscode2session?appid%ssecret%sjs_code%sgrant_typeauthorization_code, $appId, $secret, $code ); $response $this-client-get($url); $data json_decode($response-getBody(), true); if (isset($data[errcode])) { throw new \Exception(微信登录失败 . $data[errmsg]); } return $data; // openid, session_key, unionid(可选) }登录完成后需要把微信用户和老人档案绑定。这里要支持“一个人绑定多个老人”最常见的场景是子女同时绑定父母两个人。所以用了单独的用户档案关联表而不是在档案表里直接存一个 openid 字段。绑定有两种方式家属在申请建档时扫老人的身份证或手填身份证号自动匹配或者管理员在后台手动关联。4.2 健康档案申请接口状态机与字段校验小程序端第一个核心动作就是“申请建档”对应后端接口POST /api/v1/profile/apply接口前端传参{ real_name: 张三, phone: 138****1234, id_card: 410***********001X, birth_date: 1948-06-15, gender: 1, medical_history: [高血压, 糖尿病], allergy: 无, current_medication: 阿司匹林每天一次, emergency_contact: 张小明, emergency_phone: 139****5678 }后端要做的事情不止是塞进数据库。里面有四个业务规则我建议直接写成接口逻辑别指望前端自觉同一身份证重复申请按id_card_hash查库如果已存在且状态为“已建档”直接返回现有档案提示“已有档案可补充信息”如果状态是“待审核”则提示“申请正在审核中”。过敏史必填过敏史为空时前端会直接不填导致后续护士不知道该不该避讳某些食物或药物。我规定该字段必须显式填“无”。紧急联系人必填老人独自来旅居时一旦发生突发健康事件现场工作人员必须能快速联系上家属。身份证校验码后端做了简单的身份证格式和校验位判断不合法直接拒绝避免脏数据进入系统。档案状态机用整型字段控制1 草稿 → 2 待审核 → 3 已建档 ↘ 4 已驳回 → 修改后重新提交 → 2审核动作通常由基地前台或健康管理员在小程序端操作。审核通过后系统自动创建一个resident_stays记录状态为“在住”同时给老人家属推送一条微信订阅消息告知建档成功。这一步非常讨喜运营方后来反馈家属对“建档成功通知”的满意度很高因为这意味着后续健康记录也会推给他们。4.3 日常体征记录接口重复点击靠唯一键挡护理员每天要给多位老人测体征操作场景是点开今日待测列表一个一个录入。这里的痛点其实是“重复提交”和“手误提交”。护理员手机卡一下重复点两次提交按钮如果没有幂等处理一天就多了两条重复记录。处理方式有两层第一层是业务层。提交时带上record_date和record_type后端先查库如果今天已存在同类型记录返回一个明确的提示“今天该老人已有体征记录是否修改”并把原记录 ID 返回小程序端弹窗让护理员决定是覆盖还是取消。第二层是数据库层。就是我前面在health_records表里加的联合唯一键。即使业务层漏了数据库也会拒绝重复插入不会产生脏数据。接口实现简写?php public function saveRecord(array $params) { $exist HealthRecord::where(profile_id, $params[profile_id]) -where(base_id, $params[base_id]) -where(record_date, $params[record_date]) -where(record_type, $params[record_type]) -find(); if ($exist) { $this-error(今日该类型记录已存在请选择覆盖修改或取消); } try { $record new HealthRecord(); $record-save($params); // 异常指标自动生成提醒 $this-checkAbnormal($record); return $this-success($record); } catch (\Throwable $e) { if ($e instanceof \think\exception\PDOException (int)$e-getCode() 23000) { $this-error(重复提交请刷新后重试); } throw $e; } }异常指标提醒这块值得多说一句。刚开始我们只是记录数据不做判断后来健康管理员抱怨每天翻数据太累。加了一个简单的规则体温 ≥ 37.3℃、收缩压 ≥ 160 或 ≤ 90、心率 ≥ 100 或 ≤ 50写入health_records时自动生成一条record_type 3的记录同时在“今日待处理”列表里置顶提醒护理员。这个规则简单但确实把系统的“记录工具”属性变成了“健康提醒工具”。5. 健康数据的权限与隐私容易被低估的部分5.1 最小化权限护理员不该看到全部病史旅居养老场景下护理员流动性很大。一个基地旺季会招临时护理员如果每个护理员登录后都能看到老人的完整病史、用药记录、紧急联系人会带来很大的隐私风险。我的做法是按角色限制字段可见范围和操作范围护理员只能看到“今日待测列表”“健康记录录入”“当前用药摘要”“过敏史”不能查看完整身份证信息、紧急联系人电话默认不展示。健康管理员可以查看全部健康记录、编辑异常记录、发起转诊建议。基地负责人可以看到本基地数据统计但不能查看具体老人的完整病史。平台管理员全部权限但操作会记日志。权限控制的实现是在 PHP 接口里加了一个中间件先做登录态鉴权再做角色判断最后做资源归属判断。资源归属这层很容易漏一个护理员登录后查询接口如果只校验“是否登录”而不校验“是不是这个基地的护理员”那她离职后账号如果没及时停用理论上还能通过接口拿到数据。我的建议是凡是涉及数据列表的接口必须带着当前用户的 base_id 上下文条件不要把“查全部”这种后门写进通用查询里。5.2 敏感字段脱敏与操作日志手机号、身份证号这类信息在前端列表里一律脱敏展示。后端接口返回时我在 Model 层加了一个字段映射把明文手机号通过substr_replace自动打码。规则是手机号保留前三位和后四位中间四位用****。身份证号保留前三位和后四位其他用*代替。这个功能不用每个接口单独写统一在模型读取器里处理非常省事。演示给运营方看的时候对方也确认“护士不需要看到完整身份证号”。健康档案的修改操作必须做日志。我建了一张operation_logs表记录谁、什么时候、改了什么对象、改了什么内容。日志不是给普通用户看的主要给平台管理员排查问题。比如家属投诉“为什么我爸的过敏史变成了无”管理员可以拉出日志看到是某个护理员把字段改掉了问题溯源有据可查。数据备份也提上日程。MySQL 每天凌晨 2 点自动备份保留最近 30 天。因为健康档案涉及老人生命安全相关信息丢失的代价比普通业务数据大得多。当时我们没有上云数据库用的自建 MySQL备份脚本是 crontab mysqldump简单直接但一定要测试恢复流程。只备份不恢复演练等于没备份这个坑我就不展开说了。6. 部署上线前后容易踩的坑6.1 域名、HTTPS 与小程序的强制要求小程序开发不是写完代码就能发布的第一个坑在域名。微信小程序所有request域名必须是 HTTPS而且需要已备案。我们一开始图省事想用 IP 地址在开发阶段测试发现真机预览时直接被拦截提示“不在以下 request 合法域名列表中”。真正的生产环境链路是购买域名并完成 ICP 备案备案期间小程序只能开发版调试。申请免费的 HTTPS 证书或购买证书在 Nginx 里配置ssl_certificate。在微信公众平台的“开发设置”里配置合法 request 域名。开发版调试时可以在小程序右上角打开“不校验合法域名”开关但正式发布前必须关闭。我在这里栽过跟头开发阶段一直开着“不校验合法域名”测试正常结果上传体验版后同事手机打开一片白屏因为那个开关只对当前手机当前小程序生效体验版不会继承。6.2 PHP 运行环境的版本与上传限制第二坑是环境不一致。本地我用的是 PHP 7.4服务器用的却是运维默认安装的 PHP 7.0导致一段用了新版数组解构语法的代码直接 500。排查了半天才发现是版本问题。后来养成了习惯每次提交上线前先用php -l检查语法并在服务商提供的多版本 PHP 里切换测试一遍。另一个坑是上传健康报告图片和体检报告 PDF 时Nginx 默认的client_max_body_size只有 1M护理员手机拍的照片动不动 5M、10M直接返回 413。调大配置即可server { client_max_body_size 50m; }PHP 侧还要同步调整upload_max_filesize和post_max_size这俩参数一个限制了单文件大小一个限制了整个请求体大小。只改一个不生效我第一次就只改了upload_max_filesize上传 PDF 依然失败折腾半个小时才想起post_max_size。6.3 小程序审核健康类目的选择与隐私声明小程序提审遇到最典型的两个问题一是类目。健康档案系统如果往“医疗”类目靠通常要求提供医疗机构执业许可证如果只是运营方内部使用的健康管理工具选择“生活服务健康管理”类目会更顺利。我们在提审时特别附上了功能说明“仅用于旅居养老基地内部健康信息采集与展示不提供在线问诊、诊断、开药服务不涉及医疗器械功能”审核就通过了。二是隐私政策。小程序端收集手机号、身份证号、健康体征数据必须在“小程序用户隐私保护指引”里写明收集的信息范围、用途、保存期限。有一个容易被忽略的细节微信在基础库新版里增加了用户隐私API 的调用提示即使你只是wx.login也可能触发隐私确认弹窗。配置要在微信公众平台后台操作不是只在前端放弹窗就完事。注意健康数据在整个系统里一律按敏感个人信息处理除非必要不要让前端拿到身份证全文不要明文存在日志里不要随意导出。7. 复盘老人不“会用”的系统等于白做7.1 表单设计的适老化与代办模式系统上线头两周运营方反馈最强烈的不是功能缺失而是“老人根本填不了表”。虽然我们做了大字体、大按钮、减少输入项但让 75 岁老人自己填过敏史、用药记录根本不现实多数情况是子女代办或前台工作人员帮着填。于是我们加了一个“代办人模式”。老人家属认证后可以为老人代办建档、代看健康报告。这个模式在“申请建档”那个环节救了很大忙因为旅居养老的决策者和信息填写者往往是子女不是老人本人。后来统计下来约 70% 的建档操作由家属或前台代办完成老人自己操作的不到 30%。这个比例如果当初没有预案上线体验会非常差。具体适老化细节包括全站默认字号不低于 16px关键按钮高度不小于 44px。所有表单尽量用选择器代替键盘输入最大程度减少文字输入。健康记录列表只突出“异常”和“正常”两个视觉状态避免过多图表信息。护理员的页面固定“今日待测”快捷入口打开即见当班名单不用层层点菜单。7.2 数据的“活”比“全”更关键项目上线三个月后我发现一个比功能更重要的指标档案建档率很高但健康记录断更率也高。护理员一开始新鲜感强每天都录后来忙起来经常漏。和运营方讨论后定了三条规则入住后第 1 天、第 3 天、第 7 天必须各测一次基础体征后台能看到是否完成。老人如果有“高血压”病史系统每天自动生成一条必须测量的任务提醒。连续 3 天未记录的台账会在基地管理后台标红提醒负责人跟进。这条规则加完健康记录的续传率提升了一截。因为它把“护士有空就记”变成了“系统有明确任务要求”有人负责跟踪完成度才叫真正的运营闭环。后来第二个旅居基地上线老人档案迁移只用了导出导入脚本数据一张表都没改。我们复盘时一致认为这个系统的核心价值不是“存放档案”而是让老人的健康数据在时间和空间中“流动”起来。如果当初没有把档案主数据从机构维度抽离出来现在的多基地协同完全是另一个工作量。最后分享一个实用的心得如果让我重新做一遍这个项目我会在写第一行代码之前先画一张“老人流转场景图”。把老人从 A 基地到 B 基地的全过程每个角色在每个时间点要看到什么、要做什么都画在白板上再倒推数据库和接口设计。健康档案这类系统的复杂性不在技术而在业务理解越早把场景想清楚后面的开发越省力。

从PHP到小程序：旅居养老健康档案系统开发实战

相关推荐

AI编程的本质是工程判断力训练

长期投资回报预测模型：股息率、盈利增长率与市盈率变化率的综合拆解

WSL2 GPU直通部署AI开发环境：Windows上原生Linux CUDA实战

更多资讯

USB分析仪实战：HID设备偶发丢包的定位思路与排查方法

GeoScene异步GP服务调用实战：从超时到高并发稳定运行

企业级AI Agent如何安全接入遗留系统与数据孤岛

ArtCraft：可复现的创作方法论与参数化过程实践

Portal认证实战：组网模式、认证流程与配置避坑指南

程序化艺术工作流artcraft：从随机生成到可控创作

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？