简介这是一份面向医学影像软件开发者的 PostDICOM Cloud PACS API 参考包用 Cloud DICOM 服务实现在线医学影像的存档、检索与 DICOM Viewer 展示适合需要在现有系统中嵌入影像工作流的团队参考。压缩包共 5 个文件以 HTML 参考实现、Markdown 文档、LICENSE 及 2 张 API 界面截图组成整体约 248KB结构紧凑便于快速查阅。其中 HTML 文件展示了浏览器端的查看器演示截图呈现主页与影像查看页面MD 文档则对上传、搜索、查看、删除等 API 调用做了说明。目前已有 353 人学习下载。对于一个需要快速验证 DICOM 查看器或开发远程影像系统的团队这份资料把 API 文档、界面样例打包在一起能减少从零调研的时间。1. 一句话讲透 PostDICOM 和 cloud-pacs-api把阅片从放射科机房搬进浏览器PACS 上云这件事听起来就是把 DICOM 文件从医院的阅片工作站搬到服务器上但真正落地时你会发现光是让一张 CT 的几百帧在浏览器里稳定渲染出来就够折腾好几周。PostDICOM 这类带在线 DICOM Viewer 的 Cloud PACS解决的是整条链路影像设备产生的 DICOM 文件被云端服务接收、解析、建索引医生登录网页后按检查记录检索直接在浏览器里翻页、调窗、测量不需要安装任何客户端。cloud-pacs-api 就是这顶上的 API 层负责把 DICOM 世界的协议翻译成 Web 世界能消费的接口。下面不写产品宣传只讲从 DICOM 解析到浏览器渲染的落地方案怎么选接入层、索引存什么、接口怎么设计、Viewer 哪些坑必踩。2. Cloud PACS 的链路解剖DICOM 设备、云端存储与 Web 观影之间的三道闸先从整体看这条链路。一个典型的 Cloud PACS 从下往上分四层影像接入层负责接收 CT、MR、CR 等设备通过 DICOM C-STORE 推送过来的文件或者接收 Web 端上传元数据索引层从 DICOM 头里抽出患者、检查、序列、实例的信息写进业务库供医生按姓名、检查号、日期去检索对象存储层负责把体积巨大的像素数据持久化按检查维度组织文件最上面是 DICOMWeb 接口和浏览器 Viewer。很多人以为难点在渲染实际调下来发现文件怎么组织、接口怎么给帧才是决定 Viewer 顺不顺畅的根基。2.1 DICOM 文件拆开看header 里藏着查询索引pixel data 才是真正的大块头DICOM 不是一个“图片格式”而是一个容器协议。每个文件由无数个数据元素组成每个元素由一个 tag组号,元素号标识比如患者姓名是 (0010,0010)检查日期是 (0008,0020)像素数据是 (7FE0,0010)。tag 后面跟着 VR值表示类型告诉解析器这段数据是字符串、整数还是二进制。文件结构上分两部分前面的 metadata 是结构化的键值对后面的大块 pixel data 才是图像数据。业务检索引擎真正需要的都在 metadata 里。一个检查Study包含多个序列Series一个序列包含多个实例Instance三层的 UID 是 DICOM 世界里关联数据的主键。CT 一个检查通常有几百个实例每个实例几十到几百帧体积从几十 MB 到 1GB 不等MR 稍小但帧数多、压缩格式杂。解析时最需要注意的坑是不要一次性把 pixel data 全解压到内存。我用 pydicom 做离线分析时习惯先跳过像素只读头import pydicom # stop_before_pixelsTrue 只解析头信息不读 (7FE0,0010) 像素数据 ds pydicom.dcmread(ct_slice.dcm, stop_before_pixelsTrue) print(ds.PatientName, ds.StudyInstanceUID, ds.SeriesInstanceUID, ds.SOPInstanceUID) print(ds.Rows, ds.Columns, ds.StudyDate, ds.Modality) # 注意此时如果访问 ds.pixel_array会触发整帧解码几百 MB 的文件瞬间吃满内存stop_before_pixelsTrue的作用是让 dcmread 跳过像素数据只解析头部对几百 MB 的多帧文件尤其关键。后面打印的StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID三个字段就是对象存储路径和数据库索引的主键Modality是 CT/MR/CR 这类检查类型。有一个隐蔽的误用要提醒带上stop_before_pixelsTrue之后再访问ds.pixel_array等于重新触发解码内存照样被拉满所以这个参数只适合索引阶段不适合批量取像素做后处理。再一个影响 Web 渲染的因素是传输语法也就是像素数据在文件里的压缩编码方式。常见做法是靠下面这张表先分类再决定前端解码器怎么配传输语法压缩方式浏览器端处理1.2.840.10008.1.2无压缩直接按矩阵渲染最容易1.2.840.10008.1.2.4.50JPEG Baseline现代浏览器原生可解1.2.840.10008.1.2.4.90/91JPEG 2000浏览器不支持需 OpenJPEG wasm1.2.840.10008.1.2.5RLE需 JS 解码器1.2.840.10008.1.2.4.70JPEG-LS少见需专用解码这个表不是让你背下来而是排查时用前端出现“能解析但图黑或白屏”十有八九是传输语法和解码器没对上。我一般在做索引时就把每个 instance 的 TransferSyntaxUID 一并记下来后期前端加载器按这个值动态选解码器而不是写死支持某一种。2.2 接入协议选型DICOM SCP 接收传统设备STOW-RS 面向纯 Web 客户端影像设备推送 DICOM 的老协议是 C-STORE设备作为 SCU客户端找到 PACS 的 SCP服务端把文件按 DICOM 协议一包一包传过来。SCP 要监听一个固定的 TCP 端口并且配置 AE Title应用实体名设备和 PACS 两侧的 AE Title 必须对得上才能建立 association。这套东西很稳定但端口、AE Title、传输超时这些概念运维同事第一次接触会觉得处处是玄学。另一条路是 DICOMWeb 的 STOW-RS本质是 HTTP POST 上传浏览器和 Web 客户端都能直接推文件。常见做法是两种都开院内设备走 C-STORE移动端和远程协作系统走 STOW-RS。我一般不会自己从头写 SCP主流的四个候选是方案语言适用场景dcm4cheJava企业级组件重配置多fo-dicom.NETWindows 生态顺手OrthancC轻量自带 REST API 和 DICOMWebpydicomPython只做解析不是服务真正搭服务时我用 Orthanc。它一个进程同时具备 DICOM SCP、REST API、DICOMWeb 三种入口还支持把底层存储切到 PostgreSQL 和对象存储对一个标签叫 cloud-pacs-api 的项目来说省掉了自研接入层的大部分成本。选型理由要结合你的部署环境如果团队全是 Javadcm4che 维护成本可能更低如果只是做原型验证Orthanc 起个容器两分钟就能看到数据。2.3 对象存储上的文件布局study/series/instance 三层的路径规划设备推送和服务端接收只是开始DICOM 文件最终要落盘。直接全部扔进一个 S3 bucket 会后悔检索不到、删除一个检查要扫全桶、没法按科室做权限隔离。常见做法是按三层 UID 组织路径pacs-data/{StudyInstanceUID}/{SeriesInstanceUID}/{SOPInstanceUID}.dcm这样设计有三个直接好处按 Study 前缀就能删掉整个检查符合影像科的删除习惯同一个 Series 的文件物理上相邻预加载序列时 S3 的 ListObjects 一次能扫完未来做科室隔离只要在 bucket 策略里按前缀授权即可。SOPInstanceUID 天然全局唯一直接当文件名不会重名。对象存储和本地文件系统有个本质差别小文件随机读性能很差。DICOM 一个 instance 平均几十 KB 到几 MB大量并发的 WADO-RS 请求如果全部穿透到对象存储延迟会明显偏高。我一般会在 API 和存储之间加一层本地缓存或者 Redis只让冷数据落到对象存储热数据72 小时内的检查留在 Orthanc 原本的数据目录里。这里还要特别注意对象存储的冷热分层老检查转低频存储或归档能省不少钱但归档层读取有等待时间要和业务确认能不能接受。3. 用 cloud-pacs-api 接收 DICOM从 C-STORE 监听到对象存储落盘这章把接入层彻底打通。先从起一个 SCP 服务开始然后做索引最后落对象存储。你不需要自己写 DICOM 协议栈跟着这个顺序下来CT 设备推的数据就能进 S3。3.1 启动一个 DICOM SCP 服务用 Orthanc 容器接收影像设备推送最常见的做法是直接用 Orthanc 的官方 Docker 镜像来起。它会同时监听两个端口4242 是 DICOM 协议入口8042 是 REST API 入口。# 4242: DICOM SCP 入口8042: Orthanc REST API docker run -d --name pacs \ -p 4242:4242 -p 8042:8042 \ -e ORTHANC__DICOM__AETPOSTDICOM \ -e ORTHANC__DICOM__PORT4242 \ orthanc-server:latest注意AETPOSTDICOM要和设备端配置保持一致。DICOM 协议里 AE Title 大小写敏感设备端填postdicom和服务端的POSTDICOM匹配不上会一直报 association rejected。8042 是 Orthanc 自带的 REST API方便后面查数据、挂存储和调 DICOMWeb。启动后验证 SCP 是否真的在监听用 Orthanc REST API 查当前 instance 列表curl http://localhost:8042/instances返回一个 JSON 数组如果刚启动数组是空的。这时候让设备端用 DICOM 发送工具很多科室用的是免费版往这个 AE Title 推一个序列再次 curl 就能看到 instance 的 ID 列表。看到记录只说明接入层通了并不代表云端存储已经生效下一步才是索引和落盘。3.2 解析 DICOM 头并写索引库Patient、Study、Series 的关键字段Orthanc 自己会解析 DICOM 头但业务系统检索通常不愿意直接查它的内部表。常见做法是把需要的字段复制到业务库用 PostgreSQL 做 study/series/instance 的查询。Orthanc 的 REST API 暴露了每个 instance 的完整 metadata把这里的结果同步进业务表是最省事的路。import requests import psycopg2 api http://localhost:8042 def sync_instance(instance_id: str): meta requests.get(f{api}/instances/{instance_id}/metadata).json() tags meta[MainDicomTags] sql INSERT INTO instance (sop_uid, study_uid, series_uid, patient_id, patient_name, study_date, modality, rows, cols) VALUES (%s,%s,%s,%s,%s,%s,%s,%s,%s) ON CONFLICT (sop_uid) DO NOTHING conn psycopg2.connect(hostlocalhost dbnamepacs userpacs passwordxxx) cur conn.cursor() cur.execute(sql, ( tags.get(SOPInstanceUID), tags.get(StudyInstanceUID), tags.get(SeriesInstanceUID), tags.get(PatientID), tags.get(PatientName), tags.get(StudyDate), tags.get(Modality), tags.get(Rows), tags.get(Columns) )) conn.commit()这段脚本里MainDicomTags是 Orthanc 返回的 DICOM 标签字典字段名直接用 DICOM 关键字。ON CONFLICT (sop_uid) DO NOTHING防止设备重复推送时索引重复插入。Rows和Columns不参与检索但前端按帧显示前常常需要先知道矩阵尺寸存下来省一次接口调用。业务查询真正关心的字段就这几类业务字段DICOM Tag典型值说明PatientID(0010,0020)P000123检索主键PatientName(0010,0010)张小明中文编码要注意StudyDate(0008,0020)20250110每天的新检查都靠它过滤Modality(0008,0060)CT检查类型StudyInstanceUID(0020,000D)1.2.840.xxx关联对象存储路径索引同步是个增量任务不是一次性脚本。常见做法是轮询 Orthanc 的/changes接口拿增量变更或者由接入层在每次 SCP 接收完成后调一个 webhook。直接把全量扫描写成定时任务也可以但文件多了以后扫描耗时长不建议。3.3 把 pixel data 写对象存储命名规则与分段读写的取舍索引建好之后原始 DICOM 文件要考虑从 Orthanc 本地数据目录迁到对象存储。常见做法是等设备推送完成、索引入库后再用一个搬运任务做上传而不是修改 Orthanc 的默认存储路径。用 boto3 或者对应云的 SDK 上传单个文件import boto3 s3 boto3.client( s3, endpoint_urlhttps://minio.example.com, # S3 兼容存储地址 aws_access_key_idMINIO_KEY, aws_secret_access_keyMINIO_SECRET ) # 路径规则study/series/instanceSOPInstanceUID 做文件名 key f{study_uid}/{series_uid}/{sop_uid}.dcm s3.upload_file(local_path, pacs-data, key)key的三层路径和索引库里的 UID 对应删整个检查时一条delete_objects带上前缀就能清掉。endpoint_url指向 S3 兼容的 MinIO 或云厂商的对象存储地址可以用环境变量去配不要写死在代码里因为开发环境和生产环境的 bucket 和 region 通常不一样。还有一类取舍要提前想清楚到底存整个 DICOM 文件还是拆成元数据加帧数据。存储成本上帧数据更省但拆开存会让一致性和检索变得复杂前端取一帧要拼回元数据出了错极难排查。我一般选择 DICOM 整包入对象存储渲染时由 DICOMWeb 层按帧提取因为对象存储买的是容量和带宽而不是像本地盘那样随机 IO 不受限。4. DICOMWeb 接口设计在线 Viewer 的数据通道怎么搭设备侧的文件到了云端接下来要让浏览器能查、能取。DICOMWeb 是一组 RESTful 风格的标准接口核心就三个动词QIDO-RS 负责查询WADO-RS 负责取数据STOW-RS 负责上传。Viewer 的前端代码要对接的主要是前两者。用现成的 Orthanc 就不用自己写协议层但接口怎么组合、参数怎么传、鉴权怎么兜底这些还是要自己设计。4.1 QIDO-RS 查询study list 接口的过滤参数与分页医生打开 Viewer 第一个操作是查检查记录。QIDO-RS 的查询入口通常是GET /dicom-web/studiesq 参数直接跟在 query string 上Orthanc 已经实现了这套接口直接对外暴露即可# 中文姓名模糊查询 日期开区间 分页 curl -G http://localhost:8042/dicom-web/studies \ --data-urlencode PatientName张 \ --data-urlencode StudyDate20250101- \ --data-urlencode limit20 \ --data-urlencode fuzzymatchtrueStudyDate20250101-表示 20250101 及之后的日期减号在后是开区间这是 DICOMWeb 标准里日期范围查询的写法反过来写-20250101是查这个日期之前。fuzzymatchtrue对姓名做模糊匹配中文姓名场景下必须开否则患者姓名里的字符匹配会严苛到查不到。limit控制返回条数Viewer 端一般一次加载 20 到 50 条配合滚动加载而不是一次性拉全量。返回体是一个 JSON 数组每个元素是一个 study 的元数据。响应字段默认带得很多如果只要列表页用的 PatientID、PatientName、StudyDate、StudyDescription、ModalitiesInStudy可以在查询里加includefield指定字段减少网络传输。分页注意别只靠 limit要用 offset 做游标否则用户快速滚动时后面几页会重复或跳变。4.2 WADO-RS 取帧按 instance 拉单帧影像的 URL 设计选好一个 study 后Viewer 要先拿到序列列表再按当前序列拿帧。序列和实例的信息可以用 QIDO 按层级查但实际渲染时重点在 WADO-RS 的帧接口。取某个 instance 的第一帧URL 长这样# 取 instance 的第 1 帧返回 JPEG 或原始帧内容 GET /dicom-web/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/frames/1frames/1 表示取这个 instance 的第 1 帧。对于单帧的 CR、DR 类图像只有一个 frameCT 一个 instance 可能包含几十到几百帧。这里的关键是千万不能图省事去请求整个 instance 再让前端解码几百 MB 的响应会直接把浏览器打挂。正确姿势是前端一次只请求当前视口需要的帧翻页时再预取前后几帧。如果需要该实例的完整 DICOM 头来做窗宽窗位、像素间距这些计算走 metadata 接口GET /dicom-web/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/metadata返回的 JSON 里包含全部 DICOM tag前端解析后用Rows、Columns、PixelSpacing、WindowCenter、WindowWidth去初始化显示参数。注意 metadata 接口返回的是头信息不是像素别拿它当取图来用。WADO-RS 的响应内容类型取决于原始传输语法。如果源文件是无压缩或 JPEG BaselineOrthanc 可以直接转成 JPEG 给前端如果是 JPEG 2000 这类浏览器不认的压缩格式服务端要么转码要么前端挂一个支持 JPEG 2000 的 wasm 解码器。转码会消耗服务端 CPU并且是逐帧的所以高并发场景更推荐前端解码。4.3 token 鉴权与 URL 时效影像接口不该裸奔DICOMWeb 是 DICOM 标准的一部分标准里根本没定义鉴权。把 QIDO/WADO 端口直接暴露到公网等于把患者影像裸奔给全网。常见做法是前面挂一层 Nginx所有/dicom-web/请求先过 token 校验再转发给 Orthanc# 所有 DICOMWeb 请求先过 /auth 鉴权通过后再转发给 Orthanc location /dicom-web/ { auth_request /auth; auth_request_set $auth_status $upstream_status; proxy_pass http://127.0.0.1:8042; } # internal 保证外部无法直接访问鉴权接口 location /auth { internal; proxy_pass http://auth-service:8000/validate; proxy_pass_request_body off; proxy_set_header Content-Length ; proxy_set_header X-Original-URI $request_uri; }auth_request会让 Nginx 先把请求转发到内部鉴权服务校验通过后再执行proxy_pass。internal是关键外面的请求不能直接访问/auth否则等于绕过校验。鉴权服务拿到X-Original-URI后解析 token判断用户对这台 PACS 有没有读权限返回 2xx 就放行返回 401/403 就拦截。前端取图有个容易忽略的细节img src...标签发请求时不能带自定义 header而 fetch 可以。所以取单帧不能直接塞 img src要先用 fetch 带上Authorization头拿到 blob再URL.createObjectURL()生成临时地址给 img 显示。这个临时地址要注意 revoke否则也会堆积内存。如果坚持用 query 参数带签名记得在 Nginx access log 里对 query 做脱敏签名有效期压到 15 分钟内过期让前端重新换新的。5. 在线 DICOM Viewer 常见问题排查从 dcmjs 解析到 cornerstone 渲染的四个大坑Viewer 本身不是单个“插件”它是整个链路最后一公里。前端生态里常见组合是 dcmjs 做 DICOM 解析、cornerstone 做渲染和工具。但接上去之后有四个坑几乎必踩中文乱码、大文件白屏、跨域、内存泄漏。每条我都按现象、原因、解决来写。5.1 中文姓名乱码与 JPEG 2000 解码失败现象都是黑字或黑图现象检查列表里患者姓名出现一串乱码打开某些检查时图是全黑或者白屏但普通 CR 图正常。原因分两种。姓名乱码多半是 DICOM 头里的 SpecificCharacterSet (0008,0005) 声明了 GB18030 或 GBK前端解析时没有按这个字符集解码直接用 UTF-8 去读 (0010,0010)读出来自然乱码。黑图则基本是传输语法不在前端解码能力里JPEG 2000 压缩的帧浏览器原生 Image 压根不支持。解决解析 metadata 时先看SpecificCharacterSet根据值转换编码解码器按 instance 的 TransferSyntaxUID 动态注册。cornerstone 的 WADO 加载器支持挂外部解码器我用的时候会先注入依赖再初始化 worker// 注入 cornerstone 和 dicomParser加载器才能完成解析与渲染 cornerstoneWadoImageLoader.external.cornerstone cornerstone cornerstoneWadoImageLoader.external.dicomParser dicomParser cornerstoneWadoImageLoader.webWorkerManager.initialize({ maxWebWorkers: navigator.hardwareConcurrency || 4 })这两个 external 注入缺一不可。maxWebWorkers建议用navigator.hardwareConcurrency的一半以下4 是个稳妥值你全核开 worker低配机器上解码队列会把主线程和 worker 一起卡死。JPEG 2000 的话需要额外引入 OpenJPEG 的 wasm 解码器并注册到 loader不然传到这个传输语法的 instance 依旧是黑图。5.2 大文件加载白屏不是前端问题是后端把整个 instance 返回了现象点开一个 CT 检查页面白屏十几秒浏览器标签页无响应CPU 飙满。原因WADO 取图时没有按帧拉。我见过有团队为了省事写了一个接口返回整个 instance 的多帧数据前端拿到一个几百 MB 的 ArrayBuffer 直接塞给解码器内存瞬间被打满。这是最典型的一条后端把前端坑了的翻车现场。解决前端只请求当前帧和前后预取帧后端严格按 WADO-RS 的 frames/{n} 提供单帧响应同时给 cornerstone 的 imageCache 设一个合理上限// 上限单位是字节200 MB 对多数 CT 检查够用 cornerstone.imageCache.maximumSizeInBytes 200 * 1024 * 1024 // 关闭检查时清空缓存释放解码后的帧缓冲 cornerstone.imageCache.purgeCache()maximumSizeInBytes设 200 MB 对大多数 CT 检查够用它会按 LRU 自动淘汰旧帧。移动端或者低配机器建议降到 64 到 128 MB不然淘汰策略挡不住内存峰值。还有一个隐蔽点如果服务端返回的是未压缩原始帧一帧就可能接近 1 MB转成 JPEG 能省一个量级Orthanc 的 WADO 支持在请求里加 transferSyntax 参数让服务端转码别在前端硬解。提示maximumSizeInBytes的单位是字节不是 MB直接写 200 等于让缓存上限变成 200 字节任何一帧都存不下。5.3 CORS 跨域Viewer 和 API 分离部署时被浏览器拦死现象控制台报Access-Control-Allow-Origin所有影像请求都失败前端代码什么都没写错。原因Viewer 静态页面和 DICOMWeb 服务不在同一个域。浏览器安全模型要求跨域请求必须先通过 CORS 预检。DICOMWeb 服务端默认不开 CORS响应里没有允许跨域的头部浏览器直接拦截响应。解决在网关 Nginx 层统一加 CORS 头# 允许跨域且 4xx/5xx 响应也带上 CORS 头 add_header Access-Control-Allow-Origin $http_origin always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS always; add_header Access-Control-Allow-Headers Authorization, Content-Type always; # 预检请求直接返回 204不再转发到后端 if ($request_method OPTIONS) { return 204; }注意$http_origin是取请求里的 Origin 头安全性上应该和一组合法的前端域名做白名单校验否则等于允许任意跨域。always参数要带上否则 Nginx 在 4xx/5xx 响应里不带 CORS 头前端反而拿不到真正的错误信息排查时会更懵。如果用了auth_request预检 OPTIONS 要放行不然鉴权流程会把 CORS 预检也拦掉。5.4 内存泄漏反复开关十个检查后浏览器变卡现象连续打开关闭十来个检查后标签页越来越卡滚动掉了帧最后直接崩溃。原因cornerstone 的 imageCache 里面积累了大量解码后的帧WebGL 纹理没有释放事件监听器在每次打开时重复绑定。三者叠加内存和 GPU 显存一起增长。解决统一在关闭检查的入口做资源清理function closeViewer(element) { cornerstone.imageCache.purgeCache() cornerstoneTools.globalImageIdSpecificToolStateManager.restoreToolState() cornerstone.disable(element) }purgeCache清理的是解码后的图像缓冲restoreToolState重置测量标注和工具状态disable释放 WebGL 上下文相关的资源。这个函数要在每次切换检查时调用而不是只在退出页面时。排查时用 Chrome 的 Memory 面板拍堆快照对比开关前后的快照如果看到大量几十 MB 的 ArrayBuffer 只增不减就是解码缓冲没释放回头看是不是有哪个分支漏掉了清理逻辑。6. 交付前验证用一组真实 CT 检查跑通全链路的清单链路打通、代码上线不等于能交付给科室用。我每次给影像科演示前会跑一遍下面的验收清单全部过了再把会议室投影打开验证点操作通过标准接入层用 DICOM 发送工具推一组 CT 序列SCP 收到instance 列表出现记录索引按患者姓名和检查日期查业务库StudyList 返回条数正确存储检查 S3 bucket 目录三层 key 结构一致文件大小对得上接口curl QIDO 和 WADO 单帧HTTP 200帧能以 JPEG 返回Viewer浏览器登录、检索、开图、翻页首帧 2 秒内翻页无明显白屏内存连开 10 个检查再关掉内存曲线回落不持续增长验收时有个顺序技巧先用小体量的 MR 或 CR 把链路跑通再上真实 CT 大文件做压力测试。第一次联调就拿 1GB 的 CT 去排错你会分不清问题是出在 SCP 配置、索引缺字段还是前端解码排查效率极低。等小文件通了再拿大检查压一把只验证性能和内存。线上冒烟我习惯用一条 curl 先确认后端没问题再定位前端。同一个 2D DICOM 请求直接手动执行 WADO-RS 看返回体如果这里帧已经能拿到前端白屏就锁定到解码器或渲染层来回沟通成本能省不少。这套方案做到能用的门槛不高但真正稳定到敢给临床用靠的还是上面这些按层验证的习惯。我第一次演示时图能出、窗宽窗位就是不对最后发现是 metadata 里的 VOI LUT 字段没读当时所有调整都是盲调屏幕上亮暗比例完全不对。后来所有诊断流程都先打印完整 metadata 再动前端。希望帮到你。本文还有配套的精品资源点击获取