电子病历跨浏览器截图方案：百度UM与canvas技术实践

去年做过一个医疗机构的信息化改造，最让我头疼的不是业务逻辑，而是“把电子病历页面变成一张图片”这个小功能。医生要存手术知情同意书的签字件、要留证一份客观病历的原始样子、还要把检查结论原样发给患者，这些场景都要求前端把那块病历内容完整截下来。听起来简单，但医院里什么浏览器都有，老旧的Chrome、360兼容模式、偶尔冒出来的IE11、还有医生自己装的国产浏览器，同一个组件在A浏览器好好的，到B浏览器直接黑屏或者截一半。折腾到最后，方案落在了百度UM（百度UMeditor）这条既有的编辑链路里面，算是一次从业务逻辑倒推技术方案的实践，这篇就把整个设计思路和踩坑过程写清楚。

1. 先搞明白医疗端的“截图”到底在截什么

1.1 电子病历里的截图不是给前端工程师看的

很多刚接触医疗项目的开发会觉得截图无非就是把页面画成图片，这个理解在普通网站够用，在电子病历系统里完全不行。病历截图要应对的是三类非常具体的场景：

• 第一类是原始凭证留档。电子病历有法律效力，但页面上的数据可以被再次编辑，哪怕你做了操作日志，外人仍会怀疑文字被改动。把渲染出来的病历保存为图片，相当于拍了一张“最终呈现状态”的快照，一旦发生医疗纠纷，这张图片是重要的还原依据。
• 第二类是跨机构共享。现在患者转院、远程会诊很频繁，接收方医院不一定有同一套电子病历系统，你给他结构化数据他打不开，给一张PDF又可能在对方的阅读器里字体乱掉。图片则是一种最不会出错的交接格式。
• 第三类是医患沟通与线上服务。部分医院公众号或患者端需要展示检查结论、出院小结，出于防复制和统一格式的考虑，后端直接下发图片给移动端展示最省事。

从这些需求能看出，业务方对截图的要求不仅是“看见”，更要求图片完整、不可抵赖、可长期存档。所以你在设计技术方案之前，必须先和业务确认一句话：截图出来是为了给人看，还是为了当证据。两者对清晰度、水印、原始性、裁剪规则的要求是不同的。

1.2 “网页截图”还是“内容截图”是个路线问题

大多数网页截图工具的思路是把当前视口内容抓成一张位图，这在展示型页面上没什么问题。但电子病历页面通常有侧边栏、患者基本信息栏、操作按钮、弹窗引导、页脚页眉，如果直接对整个浏览器视口抓图，医生看到的图片里会包含大量与“本次病历正文”无关的内容，患者姓名甚至可能因为页面切换而错乱。

所以在医疗系统里，我强烈建议把截图对象锁定为“病历内容容器”。百度UM在这一点上帮了忙，因为病历录入本身就是在UM编辑器里完成的，病历正文是编辑器内部的一块结构化HTML。截图前只需要从编辑器实例取正文内容，再把它放到一个干净的、宽度固定的容器中重新渲染，就能保证截图里只有病历本身，不会混入系统菜单和浮动层。这种“先取内容，再独立渲染，后转图片”的模式，是整个跨浏览器截图方案的根基。

1.3 为什么不直接用浏览器打印转PDF

会被问为什么不用Ctrl+P打印成PDF。原则上PDF也可以存档，但PDF方案在医疗现场有几个现实障碍。一是打印预览在不同浏览器里的分页规则不一致，同一个病历在Chrome里分3页，在IE里分5页，页眉页脚还会带上浏览器自己的内容。二是很多医院内网打印机是共享映射的虚拟打印机，打印组件一旦被安全软件拦截，前端代码拿到的不是文件而是错误。三是医嘱、检验报告这类内容带有强制分页和特殊样式，打印CSS写起来不轻松。图片方案反而稳定，前端生成图片后上传到文档服务或直接转存PDF，一步到位，且不受客户端打印机状态影响。

2. 百度UM在整套方案里不是截图的执行者，而是内容的稳定来源

2.1 百度UM是谁，为什么老医疗项目里绕不开

先说清楚概念：这里的百度UM，指的是百度团队开源的前端富文本编辑器UMeditor，是老牌编辑器UEditor的一个轻量分支，很多医疗HIS、电子病历厂商从WebForms时代就把它嵌入到病历录入页面里，开发人员之间习惯简称为“百度UM”。

它和截图功能有什么关系？关系不在编辑器本身提供的按钮上，而在于它沉淀了一份“跨浏览器下都能稳定编辑和输出的病历内容模型”。医疗项目里病历不是普通文本框，它有固定的字号、固定的页边距、特殊的段落语义。UM将正文放在iframe隔离的编辑区里，同时保留getContent()这样的标准接口，前端可以把编辑器里的HTML原样取出。这就等于说，你想截的病历早已是一个结构良好的文档片段，不需要自己去DOM里拼凑目标节点。

2.2 UM的iframe隔离特性让截图脱离了页面环境的污染

这是UM在截图场景中特别有价值的一点。UM编辑器内部使用iframe作为编辑区，正文和医院门户的CSS、JS是隔离的。医生虽然在一个大系统里操作病历，但病历正文的样式规则相对独立。截图时我们把UM的正文内容提取到一个独立的截图容器，这个容器不受页面外层滚动条、弹窗、主题皮肤的影响，无论是医生电脑分辨率是1366还是1920，截图都以固定宽度输出，版式绝对一致。

2.3 从UM取内容到转发给截图引擎的最小改动路径

如果系统里的病历编辑已经在用UM，新增截图功能的最小改动不是再引一套新编辑器，而是增加一层“内容导出适配”。我对接过的几个具体动作是这样的：

1. 拿到编辑器实例 editor，调用 editor.getContent()，得到病历正文HTML；
2. 对HTML做过滤，去掉textarea的换行转义、脚本片段、临时样式；
3. 把清洗后的HTML注入到页面外的一个固定宽度div中；
4. 等图片资源加载完成后，交给canvas截图链路处理。

如果你用的是比较老的UM版本，getContent() 返回的内容里可能带 \r\n 或编辑器私有属性，建议在注入到截图容器之前做一次 whitelist 过滤，只保留 p、div、table、tr、td、span、img、br、strong、em 这类病历常用标签。实际上，这也是为了保证截图内容符合医疗版式的要求，而不是为了迁就截图工具。

3. 基于UM病历内容实现跨浏览器截图的核心链路

3.1 技术上为什么选“DOM转canvas”而不是“截取屏幕”

浏览器本身不能直接对网页敏感区域截图。Windows下的ActiveX控件可以截屏，但只能截整个屏幕，而且Chrome、Edge下无法使用。现在跨浏览器普遍接受的方案是：用JavaScript遍历目标区域内的DOM节点，把每个节点的位置、大小、样式一层层绘制到canvas画布上，最后输出一个可下载的图片文件。通俗地讲，这不是拍照，而是按网页源码重新“画”了一遍。这也是html2canvas这类库的原理。

为什么这种方案适合医疗系统？因为它不依赖操作系统，不依赖浏览器插件的截图权限，只要浏览器能正常渲染DOM，理论上就能画出完整图片。UM编辑器输出的HTML结构大量是table和div，这种传统布局恰好是DOM转canvas类库最擅长处理的对象。

3.2 核心代码实现：从UM实例到一张完整图片

下面的函数是我在项目里使用的核心逻辑，它接收一个已经初始化好的UM编辑器实例，输出一个canvas对象。这里只说主流程，边界情况后面一步步补。

javascript复制async function captureMedicalRecord(editor) {
  const rawHtml = editor.getContent();
  const cleanHtml = sanitizeEmrHtml(rawHtml);

  const holder = document.createElement('div');
  holder.style.position = 'fixed';
  holder.style.left = '-99999px';
  holder.style.top = '0';
  holder.style.width = '794px'; // 对应A4正文宽度
  holder.style.background = '#ffffff';
  holder.innerHTML = cleanHtml;

  document.body.appendChild(holder);

  await waitForFontsAndImages(holder);

  const canvas = await html2canvas(holder, {
    scale: 2,
    useCORS: true,
    backgroundColor: '#ffffff',
    logging: false,
    windowWidth: 1600,
    onclone: (clonedDoc) => {
      // 去掉可能与医疗内容无关的悬浮元素
    }
  });

  document.body.removeChild(holder);
  return canvas;
}

waitForFontsAndImages 是一个自定义Promise，作用是等待容器内的img元素全部decode，等待document.fonts.ready。如果这里不等，经常出现病历图片已经显示出来了，但canvas里还是一片空白或者缺字。

3.3 长病历必须分段截图再拼接

一份入院记录通常不会超过一屏，但是一份包含既往史、体格检查、辅助检查的长病历可能超过3000像素。如果把整个病历容器直接交给html2canvas，在部分浏览器中会出现画布高度过大后内存暴涨，或者canvas导出图片时直接空白的问题。经验上超过2000像素高度就要考虑分段。

做法不是按固定高度硬切，那样会切断表格行内的文字。我采用的方法是：遍历病历容器里的直接子节点，计算每个子节点的累计高度，按照尽量不超过1500像素为一组进行分块，保证不把一个table或者一个段落切断，然后单独对每一块调用html2canvas，最后在canvas上按顺序拼接。

javascript复制function buildBlockGroups(holder, maxHeight = 1500) {
  const blocks = [];
  let current = { nodes: [], height: 0 };
  Array.from(holder.children).forEach(child => {
    const h = child.getBoundingClientRect().height;
    if (current.height + h > maxHeight && current.nodes.length > 0) {
      blocks.push(current);
      current = { nodes: [], height: 0 };
    }
    current.nodes.push(child);
    current.height += h;
  });
  if (current.nodes.length) blocks.push(current);
  return blocks;
}

分段截图的主要坑在于背景颜色和表格边框衔接。拼接时如果不做任何处理，可能出现一条很淡的灰线。解决方法是每个分块里的容器都保留同样的背景色和左右边距，拼完后把canvas相邻区域做一次1px重叠覆盖，肉眼基本看不出接缝。

3.4 截图里图片全白的真正原因：跨域和字体

病历正文包含CT报告、病理切片缩略图时，会出现一个很经典的问题：页面上图片肉眼可见，但生成的canvas对应区域全是白色。这里基本三方面原因：

• 图片来自PACS影像系统或者独立的文件服务器，域名和当前系统域名不同；
• 文件服务器响应头里没有Access-Control-Allow-Origin，canvas绘制外部图片时被浏览器安全策略拦截；
• html2canvas的useCORS配置只负责让图片“尝试跨域加载”，但最终能不能画进canvas取决于服务器是否允许。

处理这个问题的前提是医疗内网允许调整文件服务器的响应头。我实践下来的方案是：不要绕开CORS，而是让后端给图片资源加一个统一代理接口，前端把所有img的src改为 /emr-file-proxy?url=encodedUrl 的形式。这样在渲染时所有图片都变成了同域资源，跨域问题从根源上消失。注意不能直接把原地址改成dataURL去请求，那样会带来新的缓存和内存问题。

字体的问题稍微隐蔽一些。如果电子病历CSS里定义了一种医院私有字体，但截图容器所在页面没有显式引用或者是通过@font-face动态加载的，浏览器可能等不到字体加载完成就开始画canvas，导致所有中文字符都落到后备字体上，排版混乱。这里建议在截图前强制触发一次字体加载：先把页面隐藏起来，用所有需要的字体渲染一段诊断文本，再等document.fonts.ready结束。很多截图白屏、排版错乱的问题其实是这个原因。

4. 不同浏览器适配策略与血泪坑

4.1 Chrome、Edge、Firefox下的相对顺利

现在医院新采购的电脑大多使用Chrome或Edge，Chromium内核的截图渲染基本顺利，但也要注意版本差异。老一点的Chrome 80版本对canvas的CSS backdrop-filter、box-shadow支持有差异，偶尔出现截图背景透明。处理方式是执行截图前遍历所有节点，把半透明背景统一替换为纯白，去掉影响不大的阴影效果。Firefox在canvas导出大图时较慢，建议保留进度提示，不要让医生误以为页面卡死。

4.2 IE11的对抗性适配

虽然微软早已放弃IE11，但医疗内网总会有各类老旧控件和上级系统遗留，导致现在仍有一部分工作站默认浏览器是IE11。DOM转canvas在IE11里能用，但有两个显著问题：

• canvas.toDataURL可能返回空白，原因是IE导出超大canvas时存在安全限制；
• Promise、fetch、Object.assign等接口在IE11中缺失，html2canvas新版本跑不起来。

对IE11我的建议是放弃纯前端截图这条路，不要试图用各种polyfill把现代库强塞进一个十几年前的浏览器里。项目里的降级方案是：检测到window.navigator.userAgent中包含Trident/MSIE时，前端自动请求后端截图服务，后端用一个独立的渲染进程打开同一份病历URL并输出图片，前端拿到图片地址展示。这个降级思路在后文会展开说明。如果一定要在IE前端截图，只能回到UM编辑器老版本自带的绘图控件方式，但那个插件依赖Flash，现在没有维护价值。

4.3 国产双核浏览器的模式切换问题

360安全浏览器、360极速浏览器、搜狗浏览器等在医疗单位很常见，它们都有兼容模式和极速模式。极速模式走Chromium内核，截图逻辑和Chrome一致，基本没有问题。难点在于兼容模式，它本质是IE内核的壳，很多代码会被彻底打回原形。我项目里的做法是写一个检测函数，从navigator.userAgent里识别360浏览器的内核标识，如果是兼容模式，直接在截图按钮上弹出提示，要求切换到极速模式后重试。

javascript复制function is360CompatibleMode() {
  const ua = navigator.userAgent.toLowerCase();
  const is360 = ua.includes('360ee') || ua.includes('360se');
  const isTrident = ua.includes('trident') || ua.includes('msie');
  return is360 && isTrident;
}

有人会觉得给用户增加操作成本，但相比兼容模式下各种无解的渲染问题，一个明确的操作提示反而能降低信息科的电话咨询量。医院信息科的人不是不会切换，而是不知道问题出在哪，把引导做在按钮旁，大家配合度很高。

4.4 截图失败后的兜底策略

即使做足了适配，仍会遇到医院工作站的“特殊环境”：系统时间导致的证书失效、单位网络劫持、安全软件注入导致DOM异常。截图按钮不能就此变成不可用状态。我设计了三级兜底：

1. 第一级：同页面重新渲染截图，比如清理浮动层、等待字体后重试一次；
2. 第二级：前端仍失败，将当前病历数据提交给后端，由后端侧的服务组件完成页面渲染与图片生成；
3. 第三级：把病历正文HTML原样导出，让医生用Word或浏览器打开后另存。

后端渲染方案我推荐在服务器上部署无头浏览器服务（比如Puppeteer），但要注意电子病历图片资源的访问鉴权，后端渲染进程要带着有效会话去请求页面，不然截出来的图里只剩登录框。

5. 医疗场景绕不开的隐私与合规细节

5.1 截图不能截到“不应该出现”的内容

电子病历页面上除了正文，常常有悬浮的患者姓名、住院号、床号提示条、医保类型浮窗、医生待办气泡。这些信息对操作者来说是必要的，但一旦截图下来发给患者或外院，就可能造成不必要的隐私扩散。所以截图前的内容净化相当重要。我采用的规则是：截图容器的父层使用position:fixed放到屏幕外，同时向业务层约定一个“截图专用URL参数”，当页面以截图模式渲染时，隐藏所有患者提示条和工具栏。

如果病历和患者信息是在同一个UM内容里，还应在取内容后执行正则清理，把页面里展示用但不需要进入截图文档的患者姓名、身份证号替换成遮蔽符，只保留主诉、诊断、医嘱等真实病历信息。

5.2 图片本身要有防篡改和审计能力

图片生成只是开始。病历截图是要进入电子病历归档系统的，归档的图片至少要有三个辅助信息：

• 防篡改哈希：生成图片后由前端或后端计算MD5/SHA256，随图片一起入库；
• 操作审计：什么时间、哪个工号、通过哪个病历ID发起了截图，这步必须有记录，不能省；
• 水印标识：在图片右下角固定输出生成时间、操作人ID、病历编号的水印，避免图片被截断后无法追溯。

我在实现水印时不是直接画在canvas上，而是在导出图片后用canvas二次绘制，这样不会影响原病历正文的清晰度，也防止别人用裁图的方式掩盖来源。水印颜色建议用半透明灰，太重的颜色会让病历文字产生视觉干扰。

5.3 静态资源和内网字体要统一管理

部署在医疗内网的电子病历系统，前端页面引用字体时有时会引用外链CSS，这在内网环境是致命的。截图容器打开后字体加载不出来，所有中文落到宋体后备字体，版式可能变化。这里建议把电子病历所用的正文字体、标题字体、表格字体全部下载后放到同域静态资源目录下，通过相对路径引用。截图前优先使用document.fonts.load主动加载常用字重，确保canvas绘制时字体已经就位。

5.4 截图结果如何进入归档流程

前端生成图片后不要直接本地保存完事。稳妥的方式是先把图片上传到文件服务，拿到文件ID，然后调用电子病历归档接口，将病历记录号、版本号、图片文件ID关联起来。这样医生在电脑上看到的本地图片只是一个副本，真正生效的是归档服务里那个带哈希、带审计记录的文件。对于知情同意书这类需要签名的文件，我建议签名板和签字保存动作都完成后，再触发截图，保证图里显示的是医生和患者双方最终的签字结果。

6. 项目落地中的真实弯路和验收建议

6.1 一次令人印象深刻的排查：PACS影像全白问题

这个问题的排查过程很值得分享。病历里嵌入了患者CT影像缩略图，原页面正常显示，但截图输出的图片中所有CT区域全是空白，而文字和表格都正常。我一开始怀疑是图片懒加载，于是提前设置img的src，等onload事件完成后再截图，结果仍然空白。

后来打开浏览器Network面板发现，图片请求虽然返回了200，但响应头被网关设置为了Access-Control-Allow-Origin: *。看起来正常，问题出在PACS服务器返回的图片本身带有一个禁止缓存的响应头，而且图片的URL里还带着过期签名参数，html2canvas内部请求图片时没有带上当前页面的Cookie。图片在浏览器正常显示是因为页面顶部img标签已经通过HTTP缓存取到了数据，而html2canvas在克隆DOM后重新发请求时，URL签名刚好过期，于是拿到了401。

最后解决方式正是前面说的同域代理接口，后端内部保留PACS会话去拉取图片并流式返回到代理地址，前端截图容器引用的都是代理地址，彻底绕开了签名过期和Cookie丢失的问题。这个过程让我意识到，医疗系统的图片资源往往比普通互联网系统复杂得多，截图链路必须把图片获取方式尽早与业务后端对齐，不要等到上线前才调试跨域。

6.2 性能、内存与用户等待体验

截一份二三十页长病历的时候，页面会明显卡顿，连续截几次后浏览器内存占用会一路上涨。优化措施有几个方向。第一，不在页面可视区域内执行截图，而是放到一个脱离文档流的隐藏元素中进行，减少页面重绘负担；第二，每次截图完成后主动释放对象，把canvas的宽高置0，调用removeChild清掉容器；第三，给截图按钮增加一个不可重复点击的锁，正在截图时显示半透明遮罩。医疗场景下医生往往同时开着好几个系统，内存被浏览器吃光会导致整个工作站变慢，所以在性能优化上多花一点时间是值得的。

6.3 功能验收清单

我把这套截图能力交给医院信息科做验收时，给出过一张清单，你以后做类似功能可以直接参考：

这个清单在实际推进里特别有用，因为每个医学信息科的技术水平不同，给一份可执行的验收标准，能避免“医生说截图不行但你不知道哪里不行”的扯皮。

6.4 最后再分享一个使用上的小技巧

截图这种能力不要做成一锤子买卖。当初我做第一版的时候，以为把图和病历关联起来就够了，后来医生反馈说在病历改动后需要重新截图，旧图片和最新病历不一致会造成麻烦。于是我在截图功能里加入了版本号上传机制，医生每次截图后系统对比当前病历的修订版本，如果发现截图时版本低于最新版，就弹一条黄色提示，请医生确认是否需要重新截图。这个改动看似很小，却让图片留痕真正能对抗“版本混淆”的质疑。

另外，如果你也打算用canvas把病历转成图片，请记住：不管你的库抄了多少遍，输出PNG的命名规则一定不要只用时间戳。电子病历截图是证据文件，命名建议直接带上病历号、姓名缩写、版本号，例如 MRN20240115001_张三_V3.png，这样文件从浏览器下载后落到桌面，哪怕离开系统也可以从文件名识别来源。这个细节虽然不起眼，在医疗纠纷回溯时却是第一道防线。