手术麻醉信息系统 · 新旧版本对比（产品 + 研发）

01 / 结论先行

结论先行

老系统赢在业务厚度和现场经验，新系统赢在技术代际、架构可持续性和交付效率。结论不是“谁全面更好”，而是“长期往哪走、短期还差什么”。

OLD · oldAnes

功能最全，包袱最重

25 个业务包、98 个手麻 Controller、261 个手麻页面，业务覆盖最厚。
115 个接口层 Controller、12+ 家 HIS/ICU 厂商适配，现场补丁积累多。
但 JDK8 / Spring Boot 2.3 / Vue2 整体 EOL，依赖臃肿、升级靠人工。

NEW · newAnes

代际更新，验证待补

JDK21 / Spring Boot 3 / PostgreSQL 18 / Vue3 + TS strict，全栈在支持周期内。
分层架构、统一 CRUD、静态检查、169 条 JUnit + 168 步 Apifox，工程与测试体系成形。
但业务等价性、300 并发性能、MySQL→PG 迁移和采集切流仍未闭环。

JUDGEMENT · 判断

长期更优，短期不能无条件替代

新系统适合作为长期主线，老系统短期继续维护。
切换前必须跨过四道门槛：P0 鉴权（已过）、功能等价、压测、迁移演练。
当前最该补的不是“再写功能”，而是“把已有能力证明到可生产”。

绿灯：已形成代际优势

技术栈支持周期、分层架构、静态检查、安装升级体系、测试资产。

黄灯：需要证据补齐

业务等价性、300 并发性能、真实数据迁移、老现场升级、Win7 本地服务、白名单残留条目审查。

绿灯：P0 鉴权已修复

白名单 /** 全放行已收口为“全部需登录”（2026-11-09），未认证访问返回 401 + 1006，匿名读写回归 169 用例 0 失败。

02 / 技术栈代际

技术栈代际

不是“版本号好看”，而是从 EOL 技术栈迁移到仍能持续获得安全补丁和生态支持的底座。

技术栈代际对照
维度	老系统 oldAnes	新系统 newAnes
运行时	JDK 8 EOL	JDK 21 受支持
后端框架	Spring Boot 2.3.5 EOL	Spring Boot 3.1.12 受支持
安全 / 持久层	Shiro 1.7 + JWT / MyBatis-Plus 3.4	Spring Security + VEF / MyBatis-Plus 3.5.8
数据库	MySQL 5.7	PostgreSQL 18
构建	Maven 多模块	Gradle 8.9
前端	Vue 2.6 + Element-UI / Avue / d2-admin	Vue 3.4 + TypeScript strict + Naive UI + Vite
前端构建	webpack4 / Node 14-16	Vite 5 / Pinia / Tailwind CSS
依赖规模	99 运行时 + 30 开发 = 129	70 运行时 + 44 开发 = 114
技术债	6 套编辑器、2 套图表、部分 UI 库只声明未使用	依赖总数未大降；编辑器等重型依赖仍多，但 UI 体系收敛
采集 / 终端	device-collect 多模块 + ES 直连；aardio 重客户端	独立 device-collector + 统一 WS；轻量 Java helper

口径：两侧均按仓库内 pom.xml / package.json / build 配置静态核对，未做运行时探测；医院侧将统一安装 PostgreSQL 18，新系统数据库按 18 对齐。

03 / 架构工程

架构与工程能力

老系统也是模块化单体，真正的变化是“平台与业务分家 + 规范进构建 + 测试成资产”。

3.1

分层架构：平台能力从业务里分出来

同进程部署的交付简单性保留下来，变化的是依赖方向：业务 → 平台 → 框架。

OLD / oldAnes

模块化单体，平台与业务耦合

anes 业务、system / big-screen / interface / formloading 同进程，共用 platform-base 公共底座。特点：部署简单、功能齐全；但平台能力与业务代码同仓同进程，升级和替换边界不清，ES 是业务依赖。

NEW / newAnes

分层模块化单体，平台能力复用

anes 业务（围术期 / 申请 / 排程 / 收费 / 库存 / 采集）→ platform 平台（用户 / 权限 / 字典 / 文书 / 流程 / 文件 / CA）→ vef 框架（CRUD / 查询 / 工具 / 安全 / 虚拟线程）。特点：单进程部署保留交付简单性；平台能力沉淀复用，业务模块按域拆分，新增模块起点更高。

01
统一 CRUD 范式
81 个 anes Controller 中 63 个继承统一基类，查询、分页、审计字段和响应结构收敛。
02
静态检查进构建
后端 Checkstyle + PMD，前端 ESLint + vue-tsc；规范不靠自觉，靠构建卡口。
03
类型安全前端
Vue3 + TypeScript strict，统一 Naive UI 体系和目录规范，降低字段漂移和隐性错误。
04
测试成为资产
169 条 JUnit 覆盖 22 个域；13 个 Apifox 场景 168 步实跑并留报告，可回归、可对账。

前端规模

Vue 文件总数

新系统页面数量更少，部分原因是业务覆盖尚未追平；不能单独当作“更优”的证据。

前端依赖

运行时 + 开发依赖总数

依赖总数并未大幅下降（129 → 114）；真正的改善是 UI 体系收敛、TypeScript strict 和统一目录规范。

04 / 九大功能优化

九大功能优化

从“能跑”到“跑得稳、查得快、改得动”：每一项都对应老系统的一个真实痛点。

4.1

表结构与流程重构

机制已落地 · 收益待验证

A
老系统痛点
长期加列导致宽表膨胀、字段/行宽受限，文书表横向纵向膨胀；表间关系混乱、命名不规范；统计依赖实时多表关联，流程与表结构耦合，链路日志不完整。
B
新系统设计
业务逻辑流程重设计（多租户、权限、用药、库存）；以手术申请为聚合根重构主数据模型，梳理表间关系、规范表命名；主宽表固定列 + 动态宽表 JSON 纵向扩展；PG TEXT/JSONB；高频日志/采集表分区轮转；完善链路日志，问题可追溯、定位更快。
C
价值
流程重构字段不再超长链路日志可追溯表命名规范

4.2

主宽表 + 动态宽表

已落地

A
老系统痛点
报表实时聚合多表，统计难、耗时长、口径不一；每加一个统计项都可能改表、改 SQL；高峰统计压力直击业务库。
B
新系统设计
主宽表一手术一行（92 列）；动态宽表一手术×配置，dynamic_fields JSON；映射 + 拦截器同事务同步；全量重建 Job 兜底；统计直读宽表，口径统一。支持读写分离，高并发高负载场景可按需开启，降低业务库压力。
C
价值
报表直读宽表口径统一加项只配映射读写分离可开启

4.3

围术期查询重构

结构优化 · 性能待压测

A
老系统痛点
围术期查询接口响应慢、容易拥堵超时，数据不完整时还会出现“查不出数据”。
B
新系统设计
优化围术期查询方式：CQRS 读模型，查询走宽表/预计算；统一分页与索引；质控 SQL 优先查宽表，减少实时多表关联。
C
价值
缩短查询链路降低超时减少空结果

4.4

文书设计器与渲染 + AI 联动

组件与 AI 已落地

A
老系统痛点
围术期文书加载缓慢、分页卡顿；控件渲染方式僵化、替换难；联动事件编写慢、易错，实施成本高。
B
新系统设计
优化文书控件渲染方式，支持控件配置转换（如单选变多选），更灵活更快捷；提供后端 API 接口暴露联动事件调用；联动事件支持使用 AI 编写，减轻实施人员编写慢、错等问题，提升交付效率；样式与数据分离；doc-view 工作台组件化拆分；按需挂载卸载；OFD 渲染。
C
价值
控件配置转换后端联动 APIAI 编写联动事件加载卡顿待实测

4.5

前后端接口模式重构

已落地

A
老系统痛点
前端 dataModel 强控制，字段和接口容易漂移，异常报错、数据不对的概率高。
B
新系统设计
业务接口由后端 Controller/Service 统一控制；统一 JsonResult、CRUD 范式和前端 TS 类型；平台保留通用模型引擎用于低代码场景。
C
价值
契约收敛类型一致降低异常率

4.6

采集与推送分离

架构已落地 · 切流未完成

A
老系统痛点
采集与推送耦合、ES 直连，长期运行内存/CPU 占用高；入手术室易出现采集不上图等推送问题，中间环节故障面大、排障难。
B
新系统设计
采集优化：IP 设备数据限流、队列专用线程处理单个设备，缓解内存/CPU 压力；采集与业务推送逻辑分离，降低采集不上图等推送问题概率、提高容错性；统一 WS 数据推送逻辑；采集数据不存 ES、直接入库，便于查看与查询，提升数据统计与排障效率；PG 两层表 + 分区 + 异步执行器 + 攒批，无订阅不组装不推送。
C
价值
采集推送解耦限流+专用线程数据直入库推送容错

4.7

轻量本地服务

helper 已落地 · 现场待验证

A
老系统痛点
aardio 重客户端，异常、兼容和升级维护成本高，全院工作站分发压力大。
B
新系统设计
浏览器 + 轻量 Java helper（转发 / 配置页 / 单实例 / 自启动 / 本地 HTTP）；Electron 降级为可选；Win7 走便携浏览器 + helper。
C
价值
不依赖重客户端维护更快Win7 待实测

4.8

一键部署与升级

已落地 · 有演练

A
老系统痛点
初始化、升级依赖手工 SQL 和替换 jar，现场易出错，回滚困难。
B
新系统设计
离线一键部署（单机/多机）；后端/前端/采集/完整四类升级包；DB 迁移脚本；失败回滚；旧现场完整包过渡。
C
价值
一键部署四类升级包失败回滚

4.9

外挂报表 / 大屏，完全可自定义

代码已落地

A
老系统痛点
报表和大屏内置在平台单体中，替换、扩容、外接医院自有报表平台都不方便。
B
新系统设计
报表服务 reportServerUrl、大屏服务 bigScreenServerUrl 可配置；支持内置或独立部署；iframe-view 挂载任意外链；dynamic-html 动态页面；平台统一鉴权、菜单和路由。
C
价值
可外挂可独立部署菜单可配置不绑定单一引擎

05 / 报表与大屏

外挂报表 / 大屏能力矩阵

新系统的差异点不是“有没有报表”，而是“能不能外挂、能不能独立部署、菜单能不能配置”。

平台提供的是“外挂集成能力”

报表/大屏能自定义到什么程度，取决于外接产品（JimuReport、DataRoom 等）的版本和授权。交付清单里应写清产品名称、版本、授权方式和可配置范围。

老系统同样有积木报表和大屏模块，所以这条的差异点是可外挂、可独立部署、菜单可配置，不是“从无到有”。

外挂报表与大屏能力矩阵
能力	老系统	新系统	说明
内置报表	✓ 支持	✓ 支持	积木报表（JimuReport）
外挂报表服务	✗ 需改造	✓ 地址可配置	支持平台内置或独立部署两种模式
内置大屏	✓ 支持	✓ 支持	DataRoom 大屏设计器
外挂大屏服务	✗ 需改造	✓ 地址可配置	独立部署、独立扩容
任意外链菜单	△ 有限	✓ iframe-view	菜单直接挂载外部页面
动态 HTML 页面	△ 有限	✓ dynamic-html	配置化页面与打开方式
报表 / 大屏独立部署	△ 困难	✓ 支持	不绑定主系统发版节奏

06 / 质量与交付

质量与交付

新系统最被低估的资产不是页面，而是“可回归、可对账、可回滚”的工程体系。

169JUnit 执行 / 0 失败 / 1 跳过

13Apifox 场景 / 168 步实跑

4升级包类型：后端 / 前端 / 采集 / 完整

22集成测试覆盖业务域

测试资产结构

JUnit 169 条 · Apifox 168 步

JUnit 169 = 168 通过 + 1 跳过 + 0 失败（全绿）；Apifox 168 = 155 通过 + 8 失败 + 5 预期跳过。两组数字口径不同，整体还不能称“全绿”。

业务覆盖规模

手麻 Controller 与手麻页面数量

页面少不等于优：新系统 81 个 Controller / 96 个手麻页面，老系统 98 / 261；差距反映业务覆盖尚未追平，需用“功能等价矩阵”确认未实现、合并还是裁剪。

01
可观测性
trace-log（请求 + SQL）、Druid 监控、JVM/Redis/Tomcat 监控、采集异步执行器监控、WS 心跳。
02
部署交付
离线安装器、单机/多机部署、升级手册与 PDF 随包分发，失败自动回滚。
03
仍需补的验证
300 并发压测、真实医院数据迁移、老现场升级、采集切流、Win7 本地服务兼容。

07 / 性能容量

性能与容量

有明确的性能设计，也有明确的目标；但目前没有实测结果，不能提前写成“已达标”。

压测完成度

Phase 3 压测后置，当前未执行

0% 表示压测尚未执行，不代表系统容量为 0。目标值：50 手术间 × 6 人 = 300 并发，P95 < 300ms，业务码失败率 < 0.1%。

300并发目标

<300msP95 目标

<0.1%业务失败率目标

性能设计已存在：PG 分区表、CQRS 宽表、去 ES 大 JSON、异步执行器、攒批写入、WS 订阅态。但 WS 订阅是单实例内存态，多实例需要 Redis 转发且尚未实现；压测种子与基线新鲜度也未闭环。

结论

目前只能写“有性能架构潜力”，不能写“性能已优化”。切换前必须补齐 300 并发压测报告，并把结果纳入验收门槛。

08 / 风险与待补齐

风险与待补齐

新项目最大的短板不是架构。鉴权收口已闭环（2026-11-09），剩下三件尚未闭环：功能等价、性能实测、迁移切流。

P0 已修复

鉴权白名单全放行（已修复 2026-11-09）：permitted-uris 的 /** 全放行已移除，改为 authenticated-uris 兜底“全部需登录”，未认证访问现返回 401 + code 1006；恢复并新增的匿名读写回归 169 用例全绿（0 失败 / 1 跳过）。剩余待办：① 其余白名单条目 /oss/**、/open-api/**、/real-time-search/** 等逐条确认是否仍需匿名；② 生产配置 application-prod.yml 生效后冒烟一次。

业务等价性未证明：老系统 98 个手麻 Controller / 261 个手麻页面 / 115 个接口层 Controller / 12+ 家厂商适配；新系统 81 / 96。部分域需确认“未实现、合并还是裁剪”。

性能未实测：300 并发、P95 < 300ms、失败率 < 0.1% 仍是目标值；k6 无结果产物，压测种子与基线新鲜度未闭环。

迁移与切流未闭环：仓内没有 MySQL→PG 业务数据迁移工具；采集改造阶段 3-7 基本未完成；老现场升级演练对象不是 oldAnes 的 MySQL 现场。

数据一致性规范：del_flag 123 处声明仅 1 处带自动填充；事件分页过滤未绑定；单位不一致抛 500+1001。需要统治理，不是单点修。

本地服务现场边界：helper 已落地，但 Win7 浏览器渲染、杀软拦截、自升级仍需现场验证；“完全不依赖客户端”应改为“不依赖重型客户端”。

构建链与文档漂移：anes 依赖 mavenLocal 的 platform jar，改 platform 后需 publishToMavenLocal；部分文档与实现有漂移（如 SSE→WS），交接以源码为准。

09 / 迁移与决策建议

迁移与决策建议

不要把“功能做完”当成“可以切换”。按门槛推进，老系统短期继续维护，新系统逐步接管。

1. 修 P0 鉴权白名单已完成

/** 已移至 authenticated-uris，未认证访问返回 401+1006；回归 169/0/1 全绿。剩余：白名单其余条目审查 + 生产配置冒烟。

2. 输出功能等价矩阵GATE

按 P0/P1/P2 标出未实现、合并、裁剪；业务确认后才能谈替代。

3. 300 并发压测GATE

补齐压测种子、基线新鲜度和 k6 报告，用实测数据替代目标值。

4. 真实医院数据迁移演练GATE

选一家 oldAnes MySQL 现场，验证数据、接口、打印、CA 和归档全链路。

5. 采集双跑 / 灰度 + 试点

不要一次性切流；先双跑比对，再选可控医院试点，保留回滚路径。

6. 全面切换

四道门槛全部通过后，再按医院分批切换；老系统保留只读/回退窗口。

建议定位

有门槛的渐进替代

新系统作为长期主线，持续补齐业务等价、性能与迁移能力；老系统短期继续维护，承担存量现场和回退兜底。两者不是“立即二选一”，而是“有门槛的渐进替代”。

最该先做的三件事

决定“能不能谈切换”

1）审查白名单其余条目并做生产配置冒烟；2）出功能等价矩阵；3）跑 300 并发压测。其余优化都可以并行，但这三件决定“能不能谈切换”。

一句话总结

短板不在架构

新系统赢在“技术栈、工程规范、测试与交付体系”，老系统赢在“业务厚度、现场经验、生产稳定性”；新项目当前最大的短板不是架构，而是功能等价、性能实测、迁移切流这三件尚未闭环的事（鉴权收口已于 2026-11-09 完成）。