C#与.NET实现PACS源码：DICOM通信、影像显示与存储检索全解析

简介：全套PACS源码是一套面向医疗信息化开发者的图像存档与通信系统完整项目，采用C#与.NET框架编写，结合SQL数据库管理患者信息、影像数据及元数据。代码覆盖图像采集设备接入、DICOM协议处理、数据库服务器和工作站显示等核心模块，并针对C#类型安全、.NET控件快速构建UI、SQL高效检索等关键技术提供了完整落地实现。资源附有部署说明与使用指南，能帮助开发者从零搭建PACS环境，理解医学影像从采集、传输到存储、阅片的完整流程。压缩包约399.87MB，以C#源码工程、SQL数据库脚本和说明文档为主，项目结构清晰，适合具备一定.NET基础、希望进入医疗影像领域的开发者系统学习。目前已有554人学习，是一份兼具工程参考价值与实际指导意义的完整案例，也可用于课程设计或毕业设计参考。

1. 一套能落地的 PACS 源码，C# 与 .NET 控件到底解决的是什么

医院影像科一个 64 排 CT 的早晨就能产出两三百个序列、上千张 12bit 灰度图像。做一套 PACS（医学影像归档与通信系统）源码，核心价值从来不是"能画出一张 CT 图"，而是能把这些 DICOM 数据完整接住、存得住、查得快、显示不翻车。标题里"C# 编写、使用 .NET 控件"意味着这套东西的界面层走的是 WinForms/WPF 路线：PictureBox 显示影像、DataGridView 做检查列表、TreeView 管理患者-检查-序列层级。适合的读者是医院信息科、医疗软件集成商和想做区域影像平台的独立开发者——你们手里缺的不是绘图代码，而是收图、存储、检索、渲染这条完整链路的可靠实现方案。前面几章先讲协议和架构，后面给可直接抄作业的实现和排错。

2. DICOM 通信层先立住：C-STORE、C-FIND、C-MOVE 怎么在 C# 源码里落地

判断一套 PACS 源码是"能跑 demo"还是"能上线"，第一个试金石是通信层。所谓全套源码，至少要包含 CT、MR、DR、超声这些设备的图像接入能力，而接入的底层动作就是 DICOM 协议里最常见的三类操作：C-STORE 收图、C-FIND 查询、C-MOVE 取图。C# 这边常见做法是直接引用 fo-dicom 这类开源托管库，再在它外面封装自己的存储、数据库和界面逻辑，而不是从裸 Socket 手写 DICOM 数据包。通信层一旦不扎实，后面所有的显示和报告功能都建立在沙滩上。

2.1 接入设备前必须先定死的三个参数：AE Title、端口、传输语法

设备接入从来不是开发问题，是网络协调问题。每台 CT、MR 在配置界面里都会让你填三个东西：目标 AE Title、目标 IP 和端口。AE Title 是 PACS 在 DICOM 世界里的设备名，最多 16 个字符，常用大写字母和数字组合，比如 HIS_PACS、RAD_ARCHIVE。设备端会拿这个字符串和你本机配置比对，你收下它的图像前也要在自己的白名单里登记它的 AE Title 和 IP，两边对着登记，关联才能建立。

端口方面，DICOM 标准默认 104 是特权端口，开发机不会天天开管理员权限跑服务，所以测试环境普遍用 11112 或 2762。生产环境我一般建议单独划一个内网 VLAN，把 104 或 11112 的 TCP 入站方向放通给设备网段，别跟办公网混在一起。防火墙配置和端口放通是联调第一天最容易卡住的地方，日志里反复出现 association rejected 时，九成是端口没通或者 AE Title 没对上。

传输语法决定像素数据的编码方式。新设备基本都支持 Explicit VR Little Endian 和 Implicit VR，老一点的核磁共振设备可能只给你 Implicit VR；压缩格式里 JPEG Lossless、JPEG-LS、JPEG2000 都能见到。在 Presentation Context 协商阶段，PACS 端应该只声明自己有把握处理的传输语法，让设备端做转码。常见的配置项见下表：

提示：联调前把这张表发给对方科室或设备工程师，让他在设备侧一次配齐，比你去猜设备配置界面省一周时间。这是做医疗项目的血泪经验。

2.2 用 C# 写一个能收片的 C-STORE SCP 服务

收图就是 C-STORE SCP：设备作为 SCU 把 DICOM 文件推过来，PACS 作为 SCP 接收并返回状态字。用 fo-dicom 封装，核心服务类大概是这个骨架：

public class CStoreScpService : DicomServiceProvider, IDicomCStoreProvider { public Task<DicomCStoreResponse> OnCStoreRequestAsync(DicomCStoreRequest request) { var ds = request.Dataset; // 1) 先写临时文件，避免把 DICOM 会话阻塞在慢速 IO 上 var tmpPath = StorageEngine.WriteTempFile(ds); // 2) 落盘成功后再异步提交元数据入库，入库失败不影响设备端响应 _ = Task.Run(() => StorageEngine.Commit(tmpPath, ds)); // 3) 立即返回 Success，设备才会发下一个实例 return Task.FromResult( new DicomCStoreResponse(request, DicomStatus.Success)); } } // 启动监听：绑定所有网卡，端口 11112 用于联调 var server = DicomServer.Create<CStoreScpService>(IPAddress.Any, 11112);

这段代码有三个关键设计。第一，先写临时文件再异步提交，是因为设备端在等 C-STORE Response，如果我们在入库或者校验上耗时太久导致响应超时，设备会重传同一张图，归档里就出现重复实例。第二，处理完立即返回 Success，把文件校验、数据库插入放到后台任务，保证吞吐。第三，WriteTempFile 和 Commit 是两层：临时文件只保证数据不丢，Commit 才负责校验、改名、插库，容易出错的环节全部异步化。

实际项目里 CStoreScpService 还要加一层 AE Title 白名单校验，收到关联请求时先比对来路 IP 和 AE Title，不在列表里直接拒绝。设备端过来的数据流大多是短连接、大量并发，TCP_NODELAY 通常要开着，否则小文件传输时 Nagle 算法会带来几十毫秒的延迟，整批序列传完就明显变慢。

2.3 查询与取回：C-FIND / C-MOVE 在调阅场景里怎么配合

图像收进来只解决一半问题，阅片和报告要从归档里把历史检查调出来，这时候用 C-FIND 查元数据、C-MOVE 取图像。C-FIND 只返回患者、检查、序列级别的属性条目，不搬图像数据，所以列表响应很快：

var query = DicomCFindRequest.CreateStudyQuery(); query.Dataset.AddOrUpdate(DicomTag.PatientName, "*张*"); query.Dataset.AddOrUpdate(DicomTag.StudyDate, "20240101-20240630"); var studyList = new List<DicomDataset>(); query.OnResponseReceived = (req, res) => { // 每个回调对应一条检查记录，只含元数据 studyList.Add(res.Dataset); }; var client = new DicomClient("archive_ip", 11112, false, "WORK_AE", "ARCHIVE_AE"); await client.SendAsync();

参数说明：PatientName 用通配符匹配，StudyDate 用起止日期范围；OnResponseReceived 会按行回调，每行是一条 Study 级别信息。注意 C-FIND 有层级限制，你想查某个 Study 下的 Series，就要改用 CreateSeriesQuery 并把 StudyInstanceUID 带上。C# 端把它封装成一个异步方法，界面层绑定到 DataGridView 上，就能做出一个最简单的检查列表。

真正把图像搬到阅片端的是 C-MOVE。C-MOVE 的特点是让归档服务器主动把图像推给另一个 AE Title，比如你的阅片工作站：

var move = DicomCMoveRequest.CreateStudyQuery(studyUid, "REPORT_WS"); var client = new DicomClient("archive_ip", 104, false, "QUERY_AE", "ARCHIVE_AE"); await client.SendAsync(move);

这里最容易忽略的是 REPORT_WS 这个目标 AE 必须已经在线并注册成 SCP 服务，否则归档端根本没地方推。传统架构里 C-MOVE 的目标就是阅片工作站本身，工作站一关机，老临床系统里就积压一堆取图失败记录。现在更稳妥的做法是推给一个常年在线的存储网关进程，由它落盘后再通知工作站本地读取，规避设备端依赖客户端在线的黑匣子问题。

3. 影像显示管线：16bit 灰度图在 .NET 控件上显示的关键一步

PACS 的界面层看着朴素，难点全在像素数据转换上。CT、MR 吐出来的是 12bit 或 16bit 灰度，屏幕上是 8bit 显示，中间那套窗宽窗位映射和像素格式转换，决定了医生看到的图像能不能用。这套管线的输入是 DICOM 数据集里的 (7FE0,0010) PixelData，输出是一块 8bit 灰度缓冲，再喂给 .NET 控件显示。

3.1 像素标签解析：Bits Stored、High Bit、Rescale 一个都不能漏

先把 DICOM 里那组决定图像长相的标签读全。下面这段是从数据集里提取关键标称值的典型代码：

var bitsAllocated = ds.GetValue<ushort>(DicomTag.BitsAllocated, 0); var bitsStored = ds.GetValue<ushort>(DicomTag.BitsStored, 0); var signed = ds.GetValue<ushort>(DicomTag.PixelRepresentation, 0) == 1; var photometric = ds.GetString(DicomTag.PhotometricInterpretation); var slope = ds.GetValue<double>(DicomTag.RescaleSlope, 1.0); var intercept = ds.GetValue<double>(DicomTag.RescaleIntercept, 0.0);

BitsStored 和 BitsAllocated 的区别是很多新手的第一个坑。CT 图像 BitsAllocated 是 16，BitsStored 是 12，也就是说每个像素占 2 字节，但有效数据只有低 12 位，高 4 位是填充，直接按 ushort 读没问题，可你要知道数据的真实动态范围是 0 到 4095。PixelRepresentation 表示是否带符号，绝大多数 CT 按无符号存储，少数设备会按有符号存，两种情况取值方式不同。RescaleSlope 和 RescaleIntercept 是把存储值换算成真实物理值的系数，CT 里通常就是 1 和 -1024，换算结果就是亨氏单位。这个 intercept 漏了，整幅图会整体偏亮，看肺窗时病灶对比度全错，属于典型的显示端翻车点。

字节序也要在处理最前面就定死。Explicit VR Little Endian 传输语法下 16bit 值是小端序，Big Endian 极少见但老型号设备里确实存在。我一般会在解析阶段先看 TransferSyntax UID，把大小端标志存成一个字段，后面所有像素读取都走同一个分支，避免每张图都去猜字节序。

3.2 窗宽窗位：把 12bit CT 值映射成屏幕 8bit

窗宽窗位是 PACS 显示的灵魂。窗位 WL 决定灰度映射的中心值，窗宽 WW 决定容纳的灰度范围。比如腹部 CT 常用窗宽 400、窗位 40，肺窗用窗宽 1500、窗位 -450。整套映射逻辑可以收敛成一个纯函数：

public static byte[] ApplyWindow( ReadOnlySpan<byte> raw, int pixelCount, bool littleEndian, bool signed, double slope, double intercept, double wl, double ww, bool invert) { var output = new byte[pixelCount]; double low = wl - ww / 2.0; double high = wl + ww / 2.0; for (int i = 0; i < pixelCount; i++) { int value = littleEndian ? raw[i * 2] | (raw[i * 2 + 1] << 8) : (raw[i * 2] << 8) | raw[i * 2 + 1]; if (signed) value = (short)value; // 按补码还原符号 double hu = value * slope + intercept; // 先换算成物理值 double gray = (hu - low) * 255.0 / (high - low); gray = Math.Clamp(gray, 0, 255); output[i] = invert ? (byte)(255 - (byte)gray) : (byte)gray; } return output; }

参数要点在于换算顺序：先按有无符号还原存储值，再乘 slope 加 intercept 得到物理值，最后才做窗宽窗位映射。如果先把存储值截到字节再做映射，12bit CT 的细节会丢得很厉害。invert 参数对应 PhotometricInterpretation 为 MONOCHROME1 的情况，也就是低像素值反而亮，DR 骨片常见，不反转的话骨头全是黑的。实际接入鼠标操作时，我一般把左键上下拖动映射到窗位、右键左右拖动映射到窗宽，每次 MouseMove 事件里重新调用 ApplyWindow，把 8bit 结果 LockBits 写回 PictureBox。为了不闪屏，PictureBox 的 DoubleBuffered 属性和控件的双缓冲机制都要开，否则拖动时画面闪烁会让医生直接放弃这套界面。

3.3 PictureBox 不够用的地方：局部放大、圆角 Panel 与自绘控件

阅片场景里除了整图缩放，医生最常用的是 picturebox 控件的局部放大功能——鼠标移到哪，哪就弹一个放大镜。用 WinForms 实现一个很薄的放大镜层就行：

private void ImageBox_MouseMove(object sender, MouseEventArgs e) { const int radius = 25; // 取源图的 50x50 区域 const int zoom = 4; // 放大 4 倍 var srcRect = new Rectangle( Math.Clamp(e.X - radius, 0, imageBox.Image.Width - radius * 2), Math.Clamp(e.Y - radius, 0, imageBox.Image.Height - radius * 2), radius * 2, radius * 2); var zoomed = new Bitmap(radius * 2 * zoom, radius * 2 * zoom); using (var g = Graphics.FromImage(zoomed)) g.DrawImage(imageBox.Image, new Rectangle(0, 0, zoomed.Width, zoomed.Height), srcRect, GraphicsUnit.Pixel); zoomPictureBox.Image?.Dispose(); zoomPictureBox.Image = zoomed; }

这段代码最关键的两点：放大镜每次鼠标移动都会新建 Bitmap，旧的必须 Dispose，不然阅片一小时内存就被吃干净；其次放大镜源的 imageBox.Image 必须是你已经转好的 24bpp 或 8bpp 缓冲，直接拿原生 16bit 灰度 Bitmap 做 DrawImage 会翻车。另外 WinForms 里设置 PictureBox 的 SizeMode 为 StretchImage 时，DrawImage 的源矩形坐标要按图像的物理分辨率算，别用 PicureBox 的控件坐标，高分屏和缩放布局下这两套坐标经常不一致。

界面风格上，医疗软件不需要花哨，但需要圆角卡片式布局和干净的边框。WinForms 控件的属性面板里没有"圆角半径"这个属性，翻遍 winform 控件属性大全也找不到，正确做法是自绘一个 RoundPanel：

public class RoundPanel : Panel { public int CornerRadius { get; set; } = 8; protected override void OnPaint(PaintEventArgs e) { var path = new GraphicsPath(); var r = CornerRadius; path.AddArc(0, 0, r * 2, r * 2, 180, 90); path.AddArc(Width - r * 2, 0, r * 2, r * 2, 270, 90); path.AddArc(Width - r * 2, Height - r * 2, r * 2, r * 2, 0, 90); path.AddArc(0, Height - r * 2, r * 2, r * 2, 90, 90); path.CloseFigure(); Region = new Region(path); base.OnPaint(e); } }

这里要提醒的是 Region 会裁掉控件边缘的消息命中区域，圆角部分太小或者控件停靠复杂时，用 OnPaint 画圆角背景加透明的 BorderStyle 反而更省事。整套界面如果只是放图、缩放、标注，WinForms 足够；如果未来要做多序列并排、MPR 重建预览这种需要高频重绘的功能，再考虑 WPF 或者 DirectX 方案，C# 源码选型的边界就在这个位置。

4. 存储与检索设计：数据库和目录规则决定整套系统的上限

通信层和显示层解决的是"图能不能进、能不能看"，存储层决定这套系统能不能长期跑。PACS 的数据量增长非常快，一台 DR 单张图就是 20MB 到 40MB，一个三甲医院影像科一年几百 TB 很常见。如果第一版就把 DICOM 文件全塞进数据库里，三个月后你就会发现备份要一整晚、查询越来越慢、数据库文件比磁盘分区还大。正确的架构是文件系统存 DICOM 文件，数据库只存元数据和索引。

4.1 文件落盘、元数据进库：为什么不能把 DICOM 塞进数据库

把 PixelData 当 BLOB 存进 SQL Server 是新手最常见的设计错误。BLOB 方案在数据量到 10 万级检查时就开始吃力，数据库膨胀、备份窗口失控、检索计划变差。文件系统存的成本低、迁移方便，也能让后续做分级存储时直接把冷数据搬到对象存储。数据库这边只需要管到 Study、Series、Instance 三级元数据。

CREATE TABLE t_study ( pk BIGINT IDENTITY PRIMARY KEY, study_uid VARCHAR(64) NOT NULL, patient_id NVARCHAR(64) NULL, patient_name NVARCHAR(128) NULL, access_no NVARCHAR(32) NULL, study_date DATETIME2 NOT NULL, modality VARCHAR(16) NOT NULL, body_part VARCHAR(32) NULL, series_count INT DEFAULT 0, instance_count INT DEFAULT 0, disk_path NVARCHAR(260) NULL, status TINYINT DEFAULT 0 ); CREATE UNIQUE INDEX ux_study_uid ON t_study(study_uid); CREATE INDEX ix_study_date ON t_study(study_date); CREATE INDEX ix_patient ON t_study(patient_id, study_date DESC);

Series 和 Instance 表照葫芦画瓢，Instance 表里存 SOPInstanceUID、实例序号、文件相对路径和文件大小。status 字段用来标记接收状态：0 接收中、1 已完成、2 校验失败，这个是后面做重传和后台清理的基础。某次接手项目时发现有人用 Access 存这些元数据——单独跑 demo 或者 10 万条以内数据学习用没问题，生产环境并发一上来锁表锁到崩溃，别拿 Access 当并发库用。

文件目录规则上，我推荐按"年份月份 + 检查实例 UID + 序列 UID + 实例 UID"组织，避免单个目录文件数过多：

static string BuildStoragePath(string root, string studyUid, string seriesUid, string instanceUid) { // UID 是点分字符串，Windows 下点号合法但和备份脚本容易冲突 string s = studyUid.Replace('.', '_'); string se = seriesUid.Replace('.', '_'); string i = instanceUid.Replace('.', '_'); return Path.Combine(root, DateTime.Today.ToString("yyyyMM"), s, se, i + ".dcm"); }

文件名用 SOPInstanceUID 而不是设备给的原始文件名，原因很简单：设备可能重名，SOPInstanceUID 全局唯一。UID 里的点号在 Linux 和备份工具眼里没问题，但某些老旧备份脚本对带点的目录名处理有坑，统一替换成下划线省得后期头疼。

4.2 调阅速度：三秒响应背后的索引与缓存设计

临床调阅的硬指标是"检查列表秒开、图像 3 秒内显示"。检查列表慢通常是查询写的，不是数据库慢。分页查询加上合适的索引就够了：

SELECT * FROM t_study WHERE study_date BETWEEN @start AND @end AND patient_name LIKE @kw ORDER BY study_date DESC OFFSET @skip ROWS FETCH NEXT @take ROWS ONLY;

调阅端真正的瓶颈在图像加载：一个 4096x4096 的 DR 原图 16bit 解出来是 32MB，几十张图全解码进内存，再强的机器也扛不住。常见做法是建缩略图缓存，Series 入库时异步生成一张 256x256 的 JPEG 放在独立缩略图目录，列表页只加载缩略图，点开大图时才按需解码。翻页浏览 CT 序列时只解当前层和前后各一层，后台线程预取下一组，这是阅片流畅度的关键。如果界面层用 PictureBox 还觉得卡，先检查是不是每次翻页都在主线程里做了完整解码，而不是先找控件的问题。

4.3 断传与校验：接收过程中的文件一致性

设备传图传一半断网、服务重启、磁盘写满，这些事在影像科每天都在发生。接收逻辑必须保证任何时刻磁盘上不会出现半截文件。我的做法是分两步：先写到 tmp 文件，完整收完并校验通过后再原子改名到位。

string tmpPath = path + ".tmp"; File.WriteAllBytes(tmpPath, pixelBuffer); if (IsValidDicomFile(tmpPath)) { File.Move(tmpPath, path, true); // 覆盖式移动，完成即生效 db.UpdateInstanceStatus(studyUid, "OK"); } else { File.Delete(tmpPath); db.UpdateInstanceStatus(studyUid, "CORRUPT"); }

IsValidDicomFile 至少要检查两样东西：文件前 128 字节导言后紧跟 "DICM" 四个字符，以及 SOP Class UID 确实在允许列表里。有人说现在设备都带导言，不用查——真遇到过某台老 DR 导言区全是零，靠"只要文件能打开就认为合法"的判断，结果 200 张图里混进来 3 张只有半个图像的坏文件。另外设备端重传是常态，Instance 表的 SOPInstanceUID 字段建唯一索引，收到重复实例时按配置决定跳过或覆盖，别让重复数据把目录撑爆。

5. C# 实现 PACS 的六个高频坑：现象、原因、解法

这套技术栈做久了就会知道，PACS 项目的坑不在业务逻辑，全在细节里。下面六条是我反复踩过、也帮别人排查过的典型问题，按现象、原因、解法写清楚。

5.1 渲染翻车三连：黑图、花屏、负片

现象一：CT 图像在 PictureBox 里显示出来是全黑或者全灰。原因在于 GDI+ 对 Format16bppGrayScale 位图的支持非常有限，直接把从 DICOM 解析出来的 16bit 灰度数据塞进 Bitmap 再赋给 PictureBox.Image，渲染层经常把它当成无效像素数据，结果就是一整块黑色。解法：显示链路里永远只放 8bit 或 24bpp 的 Bitmap，16bit 原始数据只保存在内存缓冲里做窗宽窗位计算，算完转 8bit 再 LockBits 写进显示位图。这条是最常见的翻车现场，代码层就是在 ApplyWindow 之后多一步 SetPixel 或者 LockBits 拷贝。

现象二：从设备收到的 JPEG Lossless 压缩序列，用 Image.FromFile 或者新手常用的库解码后花屏，甚至直接报参数错误。原因是 DICOM 封装的 JPEG 流并不是标准 JFIF 文件，每个压缩帧外面还包着 FFFE,E000 标记的 item 头和 8 字节长度，而 .NET 自带的图像解码器完全不认这套封装，更不支持 JPEG-LS 和 JPEG2000 无损模式。解法有两个方向：第一，在传输语法协商阶段只声明 Explicit VR Little Endian，强制设备端转码成未压缩格式再传，这是最省事的；第二，对已经入库的压缩文件，按 SOP Class 判断传输语法，走带 DICOM 扩展的第三方编解码库处理，不要指望 GDI+。业务上线前最好把设备端能输出的所有压缩语法测一遍，免得某台 MR 突然给你推 JPLL 序列时全科室卡死。

现象三：DR 骨片显示出来骨头是黑的，软组织是白的，临床直接拒收。原因是 PhotometricInterpretation 标签为 MONOCHROME1，像素值和亮度是反比关系，你的渲染管线没有做反转。解法是在窗宽窗位映射函数的出口处加一个 invert 判断，MONOCHROME1 时执行 255 - gray，一句话的事，但必须在显示链路里显式处理，不能指望所有设备都按 MONOCHROME2 输出。

5.2 连接、存储与 UI 的坑

现象四：患者检查序列永远缺层，调阅时发现一个 Study 下 Series 不完整，设备端日志还显示部分传输失败。原因是 C-STORE 会话超时或者服务器端单线程处理请求阻塞，设备那边等不到响应就开始重传、超时、跳过。解法是确保 SCP 响应尽快返回，把文件写入和数据库操作全部异步化，同时给每台设备建一个独立的接收队列，监控队列积压量。这个问题的排查顺序是：先看 SCP 端有没有及时回 Success，再看文件落盘是否阻塞在主线程，最后看设备侧并发连接数和超时设置，别一上来就怀疑设备坏了。

现象五：双击打开一张 4096x4096 的 DR 图，界面假死十几秒，连续翻页直接内存溢出。原因是主线程里做了解码、Bitmap 创建和绘制，而 16bit 原图转 8bit 又是 CPU 密集操作。解法是解码和窗宽窗位计算放后台线程，界面只拿到 8bit 结果后异步更新；关闭图像窗口时主动 Dispose 位图，别等 GC。再有就是前面说的预取策略，一层层解、解完就显示，别一次性把整个序列全解到内存里。加个简单的 LRU 缓存控制同时驻留的位图张数，内存峰值就能压下来。

现象六：老方案里影像显示依赖 ActiveX 控件，新装的终端在 Win11 上要么 activex控件安装 失败，要么白屏。原因是 ActiveX 控件大多是 32 位编译，Windows 11 默认 64 位 IE 兼容模式跑不了，注册表项和 DLL 依赖也经常对不上。解法是新的 C# PACS 源码不要再引任何 ActiveX 依赖，显示、打印、标注全部走托管代码或者自绘控件；如果历史系统必须兼容，通过本机小服务或者文件交换去对接，不要让新界面嵌浏览器插件。这条属于架构债，早还比晚还舒服。

6. 验证这套源码值不值得接：以测代验的三步走

源码拿到手，别急着改界面，先花一个下午做三轮验证。第一轮验证通信链路，用一个最小的 C-ECHO 探活，通不了全盘皆输：

using var client = new DicomClient( "127.0.0.1", 11112, false, "TEST_SCU", "TEST_SCP"); await client.SendAsync(new DicomCEchoRequest());

C-ECHO 通过说明端口、AE Title、防火墙全部就位。如果你在测试另一台机器的 SCP，把 127.0.0.1 换成那台内网 IP，联调环境里第一次跑通 C-ECHO 的那一瞬间，基本就确认了网络侧没有玄学问题。

第二轮验证像素一致性。准备一组已知内容的测试图，比如用公开的 DICOM 测试图集，先发给被测系统的 SCP，再用 C-FIND、C-MOVE 取回来，对取回文件和原始文件做哈希比对。百分之百一致才算合格。这一步同时验证了灰度数据、传输语法、存储路径三块逻辑。如果比对不一致，优先怀疑接收端有没有做转码、传输语法协商是不是偷换了编码。

第三轮验证并发和性能。模拟 8 到 20 台设备同时推图，推一个 300 张左右的完整 Study，记录从第一张开始到全部入库完成的耗时，再看调阅检索接口的分页响应时间。参考通过标准如下：

我每接手一套 PACS 源码，第一件事不是看代码而是看有没有这组验证报告；有，就放心一半，没有，就自己补一份。医疗软件最贵的从来不是源码采购，而是集成测试和上线后擦屁股的时间。把这三轮验证固化成脚本，后续每次改完协议层都跑一遍，比改代码时小心翼翼管用得多。希望帮到你。

本文还有配套的精品资源，点击获取