患者上下文模式

患者上下文是 CIS 类系统中最常见的业务上下文。DirectSurface UI 不内置患者模型，但提供上下文树，让业务可以在应用、页面、弹窗和浮动窗口之间传递当前业务对象。

为什么不要全局当前患者

全局当前患者在简单系统里很方便，但在复杂工作台里会出问题：

• 同时打开两个患者的页面会互相覆盖。
• 弹窗不知道自己属于哪个页面。
• 浮动窗口脱离原 tab 后可能丢失依赖。
• 页面关闭后对象仍被引用，容易形成内存泄露。

因此，“当前患者”通常应该是页面级上下文，而不是全局单例。

推荐层级

应用上下文
  登录用户、租户、权限服务、字典服务

患者工作区上下文
  当前患者、当前就诊、患者级缓存

业务页面上下文
  当前文档、当前医嘱、当前检查申请

弹窗上下文
  弹窗参数、临时编辑草稿

业务可以根据系统复杂度裁剪层级，但不要让页面直接依赖一个可变的全局当前患者。

页面打开

打开患者相关页面时，建议把患者标识、就诊标识和页面参数一起传入页面上下文。页面内部再根据这些标识加载业务数据。

上下文保存的是“当前范围内需要共享的对象”。大体量数据可以放服务缓存里，上下文只保存引用或标识，避免上下文变成大对象仓库。

弹窗继承

由页面打开的弹窗应该继承页面上下文，并额外注入弹窗自己的参数。这样弹窗可以读取当前患者、权限服务和字典服务，也能在关闭时释放自己的临时状态。

如果弹窗是全局工具，比如系统设置、消息中心，它就不应该依赖患者上下文。

浮动窗口

浮动 tab 或独立窗口要明确上下文来源。常见做法是：浮动时保留原页面上下文作为窗口根上下文，窗口关闭时统一释放。

这样即使 UI 层级从 tab 变为顶级窗口，业务上下文仍然稳定，不依赖 DOM 或原父节点位置。