1. 需求拆解与整体方案设计思路1.1 需求本质谁也逃不过的截图归档在医院电子病历EMR系统里截图归档不是锦上添花而是刚需。医生在录入病历时需要把检验报告、影像片子、心电图波形、伤口愈合照片等图像资料直接粘贴进病历正文然后这些截图必须跟着病历一起存档后续要能被质控科抽查、被病案室调阅、在医保核查时作为证据链的一环。你可以想象一下如果每个医生都靠先保存截图到本地、再手动上传附件的流程工作一天接诊上百个患者根本撑不住。这就是标题里那个“自动归档”四个字的含金量——不是帮你省一步操作而是在医生点击保存病历的那一刻所有粘贴进编辑器的图片都已经静静躺在服务器上了。我接触过不少医院信息科的同事和.NET外包团队的开发者他们做电子病历系统的思路五花八门有的直接用编辑器自带的上传插件有的把图片转成Base64塞进数据库还有的让医生“先粘贴再手动点上传按钮”。但真正体检过这些方案之后你会发现CKEDITOR的默认行为在医疗场景下很尴尬它默认会把剪贴板里的图片直接转成Base64编码嵌进HTML前端看是没问题保存到后台数据库一查一条病历经文本动辄几MB十几MB数据库表膨胀得飞快备份恢复都跟着遭罪。更麻烦的是如果你想把这些图片再导出成独立的病历文件给患者Base64图片还得重新解码提取工作量直接翻倍。所以我需要做的事情本质上只有一件介入CKEDITOR的粘贴流程把剪贴板里的图片数据拦截下来转成标准文件流上传到服务器然后在编辑器正文里替换成图片URL。1.2 为什么选了CKEDITOR而不是换新编辑器很多人一听到“医院”两个字就开始畅想用什么React、Vue的新一代富文本编辑器但在真实的医疗信息化项目里技术选型的决定权往往不在“最新”而在“最稳”。医院的HIS医院信息系统和电子病历系统动辄运行了八年十年浏览器环境要考虑老旧的内核版本医生护士的操作习惯早就固化在现有的编辑交互里了这时候一个功能稳定的CKEDITOR 4.x反而是最省心的选择。CKEDITOR 4的生命周期虽然已经落幕官方停止新功能维护但安全更新持续到了2023年中但它的API形态非常稳定插件体系开放尤其是paste事件处理机制非常成熟。我在实际项目里对比过几家主流的编辑器总结下来CKEDITOR有四个不可替代的优势第一它支持在不重写编辑器的前提下通过contentDom和paste事件深度拦截剪贴板行为不像某些轻量级编辑器要改源码才能干预粘贴第二它默认的图片处理引擎widgetuploadwidget本身支持Base64转上传这个底子可以让我们做扩展而不是从零造轮子第三CKEDITOR的HTML输出跟病历文书要求的规范格式兼容性好保存出来的HTML可以被老旧的打印系统、电子病历共享平台正常解析第四医院前端通常还有大量定制的工具栏按钮、自定义插件这些历史资产要迁移到新编辑器成本极高。所以我这个方案的核心路线是“旧瓶装新酒”继续用CKEDITOR做编辑交互但在它内部植入一套基于C#.NET的自动上传链路。1.3 整体方案流程一条贯穿前端的链路把整个流程画出来其实不复杂医生在编辑器正文区域按下CtrlVCKEDITOR的paste事件被触发此时剪贴板里的图片对象会作为items或data传递出来前端脚本读取图片的base64数据并转成Blob二进制对象通过AJAX/Fetch把Blob上传到C#.NET Web API接口后端接口接收文件流校验格式和大小生成唯一的文件命名按日期分目录保存到磁盘保存完成后后端返回一个标准的URL字符串前端拿到URL后回填到编辑器正文的img标签的src属性中医生继续编辑最终保存病历时HTML里已经是标准的外链图片了。这里还有一个非常关键的细节很多人第一次做都会踩坑CKEDITOR粘贴图片后的默认行为是立即把Base64写进HTML的如果我们只做拦截而不阻止默认行为就会变成“既上传了文件又留了Base64”白忙一场。所以必须设置evt.data.disableFor或cancel()来阻止默认插入然后走我们自己的流程。我在早期版本里是等粘贴事件完全结束后再扫描HTML里的img标签凡是有data:开头的src就触发上传再把src替换成返回的URL。这个方案虽然也能跑但有一个体验问题医生会看到图片先插入、闪烁一下、再变成一个真实的服务器地址视觉上会有卡顿感。而且如果上传过程中浏览器恰好闪退Base64图片就永远留在正文里了下次加载照样是巨大一串编码。所以我后来改成“粘贴时先拦截、上传完毕后再插入”体验和稳定性都好了很多。2. 前端关键代码与CKEDITOR集成细节2.1 从剪贴板里提取图片数据的正确姿势前端这块的操作核心是拿到剪贴板里的图片数据。CKEDITOR 4在粘贴过程中会提供一个事件对象你可以通过evt.data.dataTransfer来访问剪贴板的内容。现代浏览器包括IE11以上的Edge兼容模式都支持DataTransferItem接口我们可以从item.type判断是否为图片再用getAsFile()方法拿到File对象。下面是关键代码这段我在多个项目里实测过兼容性良好function extractImageFromPaste(evt) { var dataTransfer evt.data.dataTransfer; if (!dataTransfer) { return null; } var items dataTransfer.items; if (!items) { return null; } for (var i 0; i items.length; i) { var item items[i]; if (item.type item.type.indexOf(image) 0) { var file item.getAsFile(); if (file file.size 0) { return { file: file, name: file.name || paste_ new Date().getTime() .png }; } } } return null; }这段代码的逻辑很直白遍历剪贴板条目找到第一个类型为image开头的条目转成File对象返回。这里要注意getAsFile()在部分旧的Chrome版本上可能返回null所以要做空值校验。另外有些医院医生是直接用扫描仪或者高拍仪把图片复制进剪贴板这种情况下图片尺寸会非常大动辄十几MB所以在后端一定要做文件大小校验和降采样处理后面会讲。另外要说一个容易被忽略的点如果医生在Word或者WPS里复制了一段带图片的内容再粘贴到CKEDITOR剪贴板里可能既有text/html的富文本内容又有Files里的图片文件。如果你只拦截图片富文本里的内容还是会正常插入这没问题但如果医生粘贴的是整个网页截图剪贴板里通常只有一个图片对象这时候直接走上传流程即可。2.2 绑定粘贴事件时绝不能踩的坑CKEDITOR的paste事件不能像普通DOM事件那样直接在editor.on(paste)里监听因为在4.x里paste事件在编辑器实例的生命周期里有不同的触发阶段。我这里推荐在instanceReady之后通过contentDom来绑定这样能保证每次编辑器重新渲染内容DOM时监听都作用于当前活动的DOM文档。代码实现如下editor.on(instanceReady, function() { editor.on(paste, function(evt) { onPasteHandler(editor, evt); }); });这个写法本身没问题但有一个真实的坑如果你在初始化CKEDITOR时用了on配置项比如config.on.paste function(){}那和在instanceReady里绑定的editor.on(paste)可能会有事件处理顺序上的冲突。实际项目里我见过有同事在config.removePlugins里配置了pastefromword、pastetext等插件结果paste事件不触发排查了大半天才发现是插件移除导致的事件链路断裂。所以我的建议是保留CKEDITOR所有自带的粘贴相关插件特别是pastetext和pastefromword不要为了精简体积把它们删掉。在paste事件处理函数里如果你拦截到了图片且决定走上传流程必须调用evt.cancel()来阻止默认行为。但注意evt.cancel()会同时阻止文字内容的插入——如果剪贴板里既有文字又有图片你就不能简单粗暴地整件事务cancel掉。处理这个矛盾的办法是先判断目标粘贴内容是不是纯图片。如果是evt.cancel()然后只走图片上传如果不是纯图片比如图文混排那就放行让CKEDITOR默认逻辑先处理然后用setTimeout延迟50毫秒扫描编辑器正文里的img标签把Base64图片逐个提取并上传。下面的代码就是我用来区分两种场景的策略function onPasteHandler(editor, evt) { var pasteImg extractImageFromPaste(evt); if (pasteImg) { // 纯图片场景取消默认行为走上传流程 evt.cancel(); uploadSingleImage(editor, pasteImg.file, pasteImg.name); } else { // 图文混排或多内容场景延迟扫描Base64图片 setTimeout(function() { scanAndUploadBase64Images(editor); }, 50); } }2.3 防止一个图被上传两次的重复标记策略图文混排场景里如果图片已经被scanAndUploadBase64Images处理过了下次医生再粘贴别的内容时扫描函数会把已有的图片再次读出来如果你不加判断就会造成同一张图重复上传服务器上多一份冗余文件。我用的策略很简单扫描到带data:前缀的图片后先给这个img元素打上一个自定义属性>[HttpPost] [Route(api/emr/uploadimage)] public async TaskHttpResponseMessage UploadImage() { if (!Request.Content.IsMimeMultipartContent()) { return Request.CreateErrorResponse(HttpStatusCode.UnsupportedMediaType, 请求格式错误必须使用multipart/form-data); } var uploadPath ConfigurationManager.AppSettings[EmrImageUploadPath]; if (string.IsNullOrWhiteSpace(uploadPath)) { uploadPath HostingEnvironment.MapPath(~/Uploads/EmrImages); } if (!Directory.Exists(uploadPath)) { Directory.CreateDirectory(uploadPath); } var provider new CustomMultipartFormDataStreamProvider(uploadPath); try { var result await Request.Content.ReadAsMultipartAsync(provider); foreach (var fileData in provider.FileData) { var localFileName fileData.LocalFileName; var originalFileName fileData.Headers.ContentDisposition.FileName?.Trim(); // 校验扩展名白名单 var ext Path.GetExtension(originalFileName ?? ).ToLowerInvariant(); string[] allowedExts { .jpg, .jpeg, .png, .gif, .bmp, .webp, .tif, .tiff }; if (!allowedExts.Contains(ext)) { try { File.Delete(localFileName); } catch { } return Request.CreateErrorResponse(HttpStatusCode.BadRequest, 不支持的图片格式); } // 校验文件大小限制单张10MB var fileInfo new FileInfo(localFileName); long maxSize 10 * 1024 * 1024; // 10MB if (fileInfo.Length maxSize) { try { File.Delete(localFileName); } catch { } return Request.CreateErrorResponse(HttpStatusCode.BadRequest, 图片大小超过限制请压缩后再粘贴); } // 这里是“降采样保存”的关键环节 var savedPath ProcessAndSaveImage(localFileName, originalFileName, uploadPath); // 返回相对路径或完整URL var urlRelative /Uploads/EmrImages/ savedPath; return Request.CreateResponse(HttpStatusCode.OK, new { url urlRelative }); } return Request.CreateErrorResponse(HttpStatusCode.InternalServerError, 未接收到有效文件); } catch (Exception ex) { return Request.CreateErrorResponse(HttpStatusCode.InternalServerError, 上传失败: ex.Message); } }这里我用了自定义的CustomMultipartFormDataStreamProvider其实你可以直接用系统提供的MultipartFormDataStreamProvider但自定义版能帮你把文件临时存储到指定目录。如果不做自定义默认临时文件会存到系统的Temp目录Windows的Temp目录权限各种诡异有时候跑着跑着就会因为权限不足报错排查起来非常费劲。3.2 图片降采样压缩让电子病历不至于变成“图片垃圾场”刚才提到了“降采样保存”这一步是真正的经验所在。医院里粘贴进病历的截图千奇百怪有的是全屏截图1920×1080有的是高拍仪拍的3000×4000的大图还有的是超声报告里导出的超长纵图高度超过5000像素。如果原样保存一张图就要8~15MB病历保存、传输、打印全部变慢。我在项目里做了一个双重处理先判断图片的分辨率是否超过阈值默认设置宽度超过1600像素就等比缩放然后在保存时用系统自带的System.Drawing库重新编码为JPEG格式质量参数设为85能把文件体积压缩到原来的20%~30%同时肉眼几乎看不出差别。处理函数的简化代码如下private string ProcessAndSaveImage(string sourceFile, string originalFileName, string uploadPath) { var now DateTime.Now; var relativeDir now.ToString(yyyyMM); var fullDir Path.Combine(uploadPath, relativeDir); if (!Directory.Exists(fullDir)) { Directory.CreateDirectory(fullDir); } var ext Path.GetExtension(originalFileName ?? .jpg).ToLowerInvariant(); var newFileName Guid.NewGuid().ToString(N) ext; var fullPath Path.Combine(fullDir, newFileName); using (var srcImage Image.FromFile(sourceFile)) { int maxWidth 1600; if (srcImage.Width maxWidth) { int newHeight (int)(srcImage.Height * (1.0d * maxWidth / srcImage.Width)); var resizeImage new Bitmap(maxWidth, newHeight); using (var g Graphics.FromImage(resizeImage)) { g.InterpolationMode InterpolationMode.HighQualityBicubic; g.SmoothingMode SmoothingMode.HighQuality; g.DrawImage(srcImage, 0, 0, maxWidth, newHeight); } var jpgEncoder GetEncoder(ImageFormat.Jpeg); var qualityParams new EncoderParameters(1); qualityParams.Param[0] new EncoderParameter(System.Drawing.Imaging.Encoder.Quality, 85L); resizeImage.Save(fullPath, jpgEncoder, qualityParams); resizeImage.Dispose(); } else { // 原尺寸保存但如果是PNG/BMP也统一转成JPG以减小体积 if (ext .png || ext .bmp || ext .tif || ext .tiff) { var jpgEncoder GetEncoder(ImageFormat.Jpeg); var qualityParams new EncoderParameters(1); qualityParams.Param[0] new EncoderParameter(System.Drawing.Imaging.Encoder.Quality, 85L); srcImage.Save(Path.ChangeExtension(fullPath, .jpg), jpgEncoder, qualityParams); // 删除原本的.png文件名 File.Delete(fullPath); fullPath Path.ChangeExtension(fullPath, .jpg); newFileName Path.GetFileName(fullPath); } else { srcImage.Save(fullPath); } } } try { File.Delete(sourceFile); } catch { } return relativeDir / newFileName; }这里需要特别说明几个容易踩坑的细节System.Drawing在非交互式进程IIS应用池下使用要小心。Image.FromFile加载大图时如果服务器内存不足会抛OutOfMemoryException这不是说真的内存不够而是GDI的底层限制。最好在web.config里的system.webServer节点下设置securityrequestFilteringrequestLimits maxAllowedContentLength20971520 /并同步调大应用池回收内存限制。resizeImage.Save保存为JPG时如果源文件本身就是半透明的PNG比如截图里的透明背景保存成JPG会把透明部分变成黑色底很难看。我的处理方式是对PNG先检查PixelFormat如果包含Alpha通道就走PNG格式原样保存不强制转JPG。这个判断逻辑加上之后医生粘贴心电图通常底色是白色或网格就不会出现黑色背景的大翻车。文件名用GUID不是UUID原因是GUID的32位小写字符串没有连字符适合作为单文件文件名。如果你用原始文件名会造成两个隐患一是中文文件名在部分老系统里的编码问题二是不同医生粘贴的截图可能都叫“图片1.png”会互相覆盖。3.3 数据库归档表设计图片不能只躺在硬盘里光把图片保存到磁盘还不够电子病历归档需要把图片路径和病历记录绑定起来否则以后病案室想按患者调阅所有图片光靠扫描HTML里的img标签是极不靠谱的医生可能删掉图片、移动图片位置、在多个草稿版本里编辑。我在数据库里额外维护了一张EmrAttachment表结构比较简单CREATE TABLE dbo.EmrAttachment ( Id BIGINT IDENTITY(1,1) PRIMARY KEY, EmrId BIGINT NOT NULL, -- 关联病历主表 PatientId VARCHAR(32) NOT NULL, -- 患者编号冗余存储方便按患者归档 FileName VARCHAR(200) NOT NULL, -- 存储的物理文件名 FilePath VARCHAR(500) NOT NULL, -- URL相对路径 FileSizeBytes BIGINT NOT NULL, -- 字节大小 FileType VARCHAR(20) NOT NULL, -- jpg/png/webp OperatorId VARCHAR(32) NOT NULL, -- 操作医生 DepartmentCode VARCHAR(50) NULL, -- 科室编码 CreateTime DATETIME NOT NULL DEFAULT GETDATE(), SourceType TINYINT NOT NULL DEFAULT 1 -- 1编辑器粘贴上传, 2外部接口上传 );为什么要在接口上传时同步返回并写入这张表因为前端拿到的只是URL如果前端JavaScript出问题没写库图片就成孤儿文件了。为了达到“自动归档”的目标我建议在后端调用一个公共的数据库写入方法。比如在ProcessAndSaveImage之后调用InsertAttachmentRecord()方法。这里最关键的是EmrId怎么传过来。我在前端上传时会在FormData里附带两个额外字段emrId和operatorId。emrId从页面的全局变量里拿一般是病历编辑页面加载时从后端塞进来的model字段。后端接口在解析multipart/form-data时除了拿到文件还要读取provider.FormData[emrId]。如果没有这个ID整个流程就会断掉即使图片上传成功了也无法归档。这个做法还有一个额外的好处以后做病历的版本管理或签名核验时可以直接用EmrAttachment表里的记录做图片级追溯比在HTML里海捞图片路径可靠得多。3.4 配置文件与IIS部署注意点后端搞定了如果部署配置不对一样会在上线第二天被医院信息科的电话打爆。我整理几个必查项web.config里的最大请求体积。IIS默认的maxAllowedContentLength是30MB但maxRequestLengthASP.NET端的限制默认只有4MB。如果你只改了一个传大图照样报404.13或者413。两个都要改。我习惯这样配system.web httpRuntime targetFramework4.7.2 maxRequestLength204800 executionTimeout120 / /system.web system.webServer security requestFiltering requestLimits maxAllowedContentLength209715200 / /requestFiltering /security /system.webServer这里maxRequestLength单位是KB204800就是200MB。看起来很大但这是为了应付医生一次性粘贴多张截图单张10MB、粘贴20张就是200MB。如果你抠门只留50MB医生粘贴完半天等不到上传结束体验极差。上传目录的写权限。如果部署在IIS上应用池身份是ApplicationPoolIdentity你得给上传目录分配IIS_IUSRS用户的修改权限。这一步你不亲自做一遍靠运维去猜很容易漏。我见过太多项目因为这一步没配上线第一天所有图片上传全部返回Access denied。网络超时。如果走反向代理或者负载均衡医院内网一般没有但部分云部署的有Nginx默认的client_max_body_size通常只有1MB你在前端怎么调都没用图片一到代理就被挡了。如果你发现C#接口本地Swagger测试正常、放到服务器上就报413第一个检查项就是反向代理的请求体大小限制。4. 常见问题与排查技巧4.1 粘贴后图片没有自动上传也没插入这个现象在项目上线初期会集中爆发。排查顺序很重要我按经验从高到低排列浏览器F12打开控制台先看有没有JavaScript报错。最常见的是Cannot read property dataTransfer of undefined这说明evt.data不是预期结构一般发生在CKEDITOR版本跟浏览器内核不兼容时。解决方案是升级到4.17.2最后一个维护版本至少把evt.data.dataTransfer判断兜住。检查paste事件有没有被其他插件拦截。比如config.removePlugins里如果删除了clipboard插件事件链会断。恢复clipboard插件即可。确认是不是浏览器的剪贴板权限限制。某些医院内网浏览器是基于旧Chrome内核封装的从Chrome 66开始获取剪贴板图片需要页面在https环境下。如果医院内网是httpnavigator.clipboard不可用但我们的方案走的是CKEDITOR的dataTransfer接口一般情况下不受这个限制。但在某些奇葩内网浏览器里DataTransferItem.getAsFile()会返回null这个只能靠降级策略如果提取不到文件就扫描Base64图片再上传。4.2 上传成功了但页面上图片不显示后端返回了URL前端也把它写进img的src了但图片显示的是一个裂开的图标。这个问题的常见原因是URL路径和实际文件存储位置对不上。我遇到过的情况有两种。第一种是相对路径写错了层级比如页面在/emr/edit/路由下你返回的前缀是/Uploads/EmrImages/...这个没问题但如果返回的是不带前导斜杠的Uploads/EmrImages/...浏览器会相对于当前路由去拼接导致404。第二种是IIS虚拟目录映射问题有的医院部署时把Uploads目录单独映射到了另外一块磁盘但IIS站点没有做虚拟目录映射结果文件存在D盘但URL请求的是C盘站点目录下的路径自然找不到。我的建议是后端接口返回时统一拼上完整的前缀要么返回/Uploads/...绝对路径要么返回http://服务器IP/Uploads/...并且把它写到一块公用的配置项里。前端拿到URL后不要做二次拼接直接赋值给src属性。4.3 粘贴多张图片时很卡甚至浏览器无响应医生的操作习惯是一张一张地截屏然后全部选中一起粘贴。CKEDITOR对多图粘贴的处理是一个事件里包含多个文件对象我的extractImageFromPaste函数只提取了第一个文件导致后面的图片直接被丢掉了。我把代码改成遍历所有items里的图片逐个push到一个数组里然后用Promise.all或串行队列逐张上传。注意不要同时并发上传太多因为C#后端如果没做并发控制大并发会造成临时文件堆积和GDI句柄泄漏。我在项目里用了一个简单的串行Promises链来控制同时只有一个上传请求在途对用户体验的影响几乎感受不到单张图片上传本地服务器只要50~200ms串行10张也就2秒左右。下面是我处理多图粘贴的上传队列核心写法function uploadMultipleImages(editor, fileList) { var uploadQueue Promise.resolve(); fileList.forEach(function(fileObj) { uploadQueue uploadQueue.then(function() { return uploadSingleImage(editor, fileObj.file, fileObj.name); }); }); return uploadQueue; }4.4 上传接口偶发500错误这个是最难排查的一类因为它不是必现往往发生在并发较高的时候。常见原因有两个。第一个是System.Drawing的GDI句柄泄漏。如果你在ProcessAndSaveImage里创建了Bitmap和Graphics对象但没有及时DisposeIIS进程的GDI句柄会被耗尽默认上限是10000个然后所有图片处理都抛异常。我建议所有图像操作只用using块并且尽量把Bitmap的创建集中到一个辅助类里方便统一管理。同时IIS应用池的“回收”设置里把“特定时间回收”和“虚拟/专用内存限制回收”都配置上给进程一个自动恢复的机会。第二个是临时目录清理机制缺失。MultipartFormDataStreamProvider会把文件先存到临时目录如果上传处理失败、进程崩溃这些临时文件就成了垃圾日积月累把C盘塞满。我在服务器的计划任务里写了每周清理一次App_Data/UploadTemp目录的脚本防止磁盘写满导致的500。4.5 调试经验不要只盯着后端日志如果你遇到“图片上传接口偶发报错”的问题建议前端和后端同时打日志。前端的fetch或XMLHttpRequest里务必把status、statusText、responseText都输出到控制台后端则用Trace或日志组件记录每个请求的文件大小、文件名、耗时。两边的日志对齐到毫秒级问题定位会快很多。还有一个技巧在帝王开发阶段哈哈开玩笑其实是“内网测试阶段”我习惯在后端接口的入口加一行代码记录请求头如果发现某些请求没有携带Content-Type: multipart/form-data; boundary...那问题大概率出在前端FormData对象构造时字段顺序不对或者代理层丢掉了boundary信息。最后再分享一个小技巧这个方案跑通之后我给项目加了一个“粘贴归档后自动绑定病历号”的扩展前端在上传时把当前正在编辑的emrId作为隐藏字段传给后端后端在保存完图片的同时往EmrAttachment表里插入一条关联记录。这样在病案室做归档核对时能直接按PatientId查出这个患者所有历史截图不用再去翻HTML源码。这个设计在一次系统的年度质控检查中发挥了很大作用——检查老师要求按患者维度调阅所有的检验单截图我直接按PatientId查询导出完全不用动用全文检索当场给检查老师留下了不错印象。我个人的体会是电子病历的截图自动归档技术难点其实并不在“上传”这一步而是在“与现有系统的融合”。你要考虑老浏览器的兼容、医生操作习惯的保留、图片体积对服务器的影响、数据库的关联设计还有运维配置的可靠性。希望这篇文章能帮你少走几条弯路至少那些我在深夜被值班电话叫起来排查的坑你最好一个也不要踩到。