为什么这个项目复杂#

医疗问诊系统的复杂点，不是“页面多”。真正麻烦的是同一张处方会穿过不同端、不同角色和不同状态：患者发起问诊，医生接诊开方，药师审方，商家确认，后台配置规则，移动端接收推送，视频通话随时插入，任何一个状态错了，用户看到的就是业务中断。

所以这类项目不能按“一个页面一个接口”去理解，必须按链路看：

• PC 管理后台：负责医生、药师、商家、处方、审方、商品、规则、权限等管理能力；
• 移动端 APP：承接用户入口、推送触达、IM 聊天、TRTC 视频和跨端跳转；
• 问诊内核 H5：承载问诊表单、医生接诊、药师审方、合理用药审查、订单/套餐等移动业务。

1. PC 后台：不是 CRUD，而是规则和运营中枢#

后台的价值不只是配置数据，而是把医疗问诊的运营规则沉淀下来。

我接触到的核心模块包括：远程审方、药师工作台、处方记录、问诊数据、GSP 商品资料、限制用药规则、慢病/长处方规则、视频审方、权限菜单和租户请求头。

这里最容易出问题的是“看起来是前端状态问题，实际是规则配置问题”。例如长处方场景里，用户选择了“慢病病情需要”，并不等于药品已经进入后台慢病目录。前者是问诊表单状态，后者是合理用药规则匹配数据。两层混在一起看，就会误判成前端没传值。

我的处理方式是：先看真实请求 payload，再看后端返回，再看后台规则目录，最后才改页面。别一上来就加兜底。兜底只会把医疗规则错误藏起来。

2. 移动端 APP：推送、IM、TRTC 和页面跳转要统一#

移动端的难点是入口太多。用户可能从首页进入，也可能从 IM 消息进入，可能从阿里云移动推送点击进入，也可能处在视频等待页、聊天页或 H5 WebView 里。

这要求移动端对事件做统一收口：

• 推送通知要能解析业务动作；
• 处方待审、视频来电、订单状态要能落到正确页面；
• TRTC 房间号要根据问诊单或处方单选择；
• Android、iOS、H5、小程序、鸿蒙配置不能互相污染；
• 摄像头、麦克风、相册、通知权限要按场景申请，而不是进入应用就乱弹。

这种项目里，代码质量的核心不是“写得花”，而是每个入口最后都能回到同一套业务状态判断。否则推送点进来和页面内跳转会出现两套行为。

3. 问诊内核 H5：把第三方问诊和合理用药做成流转#

问诊内核 H5 负责的不是简单表单，而是问诊流转。

典型流程是：读取问诊详情，归一化患者、诊断、药品、处方类型、慢病标识等字段，先做合理用药审查；如果命中规则，弹窗拦截；用户确认后继续流转，或者要求调整信息。

这个链路的关键，是不要把“审查前数据整理”和“审查后业务跳转”散落在页面点击事件里。更好的方式是把它们收口成明确阶段：

1. 拉详情；
2. 标准化字段；
3. 构建合理用药入参；
4. 审查并处理拦截；
5. 继续问诊或回写第三方状态。

这样排查问题时，能明确知道错在数据源、字段归一化、审查规则、弹窗处理，还是后续跳转。

4. 我从这类项目里沉淀的方法#

医疗问诊项目给我最大的训练，是让我更重视“链路证据”而不是“页面猜测”。

我的默认排障顺序是：

1. 看用户入口：推送、H5、APP、后台、WebView；
2. 看路由参数：inquiryPref、prescriptionPref、角色、来源；
3. 看请求 payload：前端到底传了什么；
4. 看后端返回：是接口错误、业务拦截，还是配置不匹配；
5. 看规则后台：药品目录、慢病目录、审方类型、套餐权益；
6. 最后才判断是不是前端交互或状态管理问题。

这套方法比“看到弹窗就改弹窗”靠谱得多。医疗系统里的很多问题，本质不是 UI 问题，而是多端状态、规则配置和业务流转没有被放在同一条链路里看。

总结#

这三个公司项目让我真正接触到医疗问诊 SaaS 的复杂性：PC 后台负责规则和运营，移动端负责触达和设备能力，H5 内核负责问诊和审方流转。技术栈可以是 Vue、uni-app、Vant、Element Plus、IM、TRTC、移动推送，但真正的能力是把这些东西收束成稳定链路。

我更愿意把这种经验写在简历里，因为它比“会写 Vue 页面”更有含金量：它证明我能处理多角色、多端、多状态、强规则、强合规的真实业务系统。