ComfyUI图片元数据全解析：从PNG还原工作流到故障排查

写这篇东西的起因，是我自己的一次抓狂经历。几个月前搭好的一套ComfyUI工作流，当时跑得很顺，后来隔了一段时间没用，等想再跑的时候，发现原始的json文件被误删了，只好对着屏幕发呆。后来突然想起来，当时导出的PNG图片还在——ComfyUI的图片元数据里是带完整工作流的，于是赶紧拖了一张进画布，整套节点图瞬间还原，那一刻真是长出一口气。从那之后我就养成了习惯：凡是用ComfyUI产出的图片，基本都留着原始PNG，因为它们根本就是"带图纸的零件"。这篇就把围绕ComfyUI图片元数据的原理、读取方式、丢失场景和报错排查一次讲清楚。

1. 图片里会"说话"的数据：ComfyUI元数据的本质与写入机制

1.1 ComfyUI为什么要把工作流写进图片

用过Stable Diffusion WebUI的人都知道，WebUI生成的PNG会在图片信息里塞入一个文本版提示词，方便你随时回看参数。ComfyUI的思路更彻底，它不只是存提示词，而是把整张节点图的JSON结构完整地嵌入图片文件里。这意味着你拿到任何一张ComfyUI产出的PNG，理论上都可以把它拖回画布，还原出当时那套流程的所有细节：加载了哪个模型、用的是什么采样器、每一步的参数是多少、节点之间怎么连接的。

这个设计解决了一个非常实际的需求——工作流的可追溯性。ComfyUI的工作流本质上是一个程序化流程，节点可以几十个，线可以上百条，单单记住几个提示词远远不够。如果换一台电脑、换一个整合包、或者几个月后回看自己的作品，没有原始工作流时你想复现几乎等于重搭。把工作流写进图片，就是让产物自带"施工图纸"，这是ComfyUI设计里非常聪明的一环。

1.2 PNG格式里的tEXt块与元数据存储原理

要理解元数据为什么不丢，先得知道它存到了哪里。PNG文件并不是一张纯粹的像素图，它是按"数据块"结构组织的。最核心的块是IHDR（图像头）、IDAT（真正的像素压缩数据）、IEND（文件尾）。关键点在于，PNG规范还允许插入若干辅助块，其中就包括tEXt块——一个用来存文本信息的标准数据块。

ComfyUI在保存图片时，会调用PNGWriter相关逻辑，把两份JSON分别编码成文本，写入tEXt块里。打开PNG文件用二进制方式查看，你能在文件靠前的位置看到明晃晃的prompt字段，下面跟着一大串JSON字符串，再往下一点还有workflow字段。这就是元数据能长期保留的底层原因：它和像素数据一起封装在同一个文件容器中，只要PNG文件本身没有被重新编码，信息就一直会存在于文件里。

1.3 元数据里存的是两套JSON，千万别搞混

打开ComfyUI图片的元数据，你会看到两个关键字段：prompt和workflow。它们长得不一样，作用也完全不同。

prompt字段存的是"API格式"的工作流，也就是ComfyUI后端执行时真正读取的那份JSON。它包含每个节点的id、class_type和inputs参数。简单说，这是运行时的"可执行文件"。

workflow字段存的是"UI格式"的工作流，它记录了你在前端画布上看到的全部视觉信息——节点在画布上的坐标、尺寸、分组、连线弯曲路径等。这份JSON是给前端画布渲染用的，也是你把图片拖回ComfyUI时能够在画布上重新看到完整节点图的依据。

这两套JSON经常让人犯迷糊，但理解之后会有个好处：如果你只想复用参数不想恢复布局，解析prompt字段就够了；如果你想完整还原画布布局，就必须依赖workflow字段。反正实际场景中，绝大多数人拖图回画布用的都是workflow这份。

2. 把工作流从图片里"抠"出来的三种实操方式

2.1 最省事的方法：直接把PNG拖进ComfyUI画布

这是ComfyUI内置的"官方还原通道"，也是我最常用的方式。在ComfyUI的界面里，你不需要打开任何额外插件，直接将一张PNG文件拖到画布空白区域，ComfyUI会自动读取该图片中的workflow JSON，并在画布上重建出整套节点。重建之后，节点参数保持原样，连线也保持原样，通常连模型名称都指向同一个文件。

但有一个细节容易忽略：ComfyUI的这个"拖入还原"功能，默认使用的是图片里workflow字段的数据。如果这张图片只有prompt字段而没有workflow字段——例如某些第三方工具生成、或者工作流被清理过——拖进去之后可能会提示找不