我第一次把虚拟试穿接进 ComfyUI，是在一个电商换装的小项目上。客户给了 60 张模特图、80 张服装图，要求”一天之内出一套能跑的量产流程”。我当时想得很简单：两个 LoadImage 节点塞进去，接一个 Clothes Changer，点 Queue，完事。
结果第一张虚拟试穿图的领口歪了三厘米，第二张图的袖子把胳臂吞进去了，第三张图的连衣裙下摆直接穿过了大腿。我盯着屏幕看了十分钟才意识到，问题不在节点，而在输入和那个被我一路默认打开的 keep_pose 开关。
这篇教程就把这套虚拟试穿流程从头到尾拆开讲。主线只有一条：两张图（人物图 + 服装图）加一个开关（keep_pose）。你把这三样吃透，剩下 90% 的坑都能自己趟过去。我会给完整的节点连接清单、参数 JSON、API 调用示例，还有几张我实际在项目里用过的表。
先把结论摆出来：虚拟试穿真正难的是”决定不做什么”
这里说的”不做什么”，指的是三件具体的克制：不为了多一种姿势去牺牲服装版型、不为了省事去凑合一张不合格的人物图、不在同一次实验里同时动两个变量。前两件关于输入，第三件关于流程。
这三件听起来都是常识，但我在实际项目里见过的失败，八成都能归到其中一条上。所以后面写的每一个参数、每一条规矩，其实都是这三句话的展开。
上面那个项目最后交付的结果，是 60 张里 52 张可用、8 张进人工。而回头看，那 8 张里有 6 张的问题，在按下生成之前就已经注定——要么人物图是侧身，要么服装图是从别人身上抠下来的。模型只是把准备阶段的疏忽，忠实地放大成了成品里的瑕疵。
所以我后来做虚拟试穿，有条不成文的规矩：先把两张输入图和那个开关想明白，再动手连线。开头花十分钟看素材，能省掉后面两小时的调参。
市面上的教程大多在讲”怎么装节点””怎么点生成”。这些当然要讲，但那是 20 分钟就能学会的东西。真正让一个试穿流程从”能出图”变成”能交付”的，是三件事：选对方案、喂对输入、敢不敢关掉 keep_pose。
两类方案的底层分工
ComfyUI 生态里的虚拟试穿，现在有两条清晰的路线，选哪条直接决定你后面要花多少时间调参：
第一条是本地节点式，代表就是 Clothes Changer 这一类自定义节点。它把服装参考对齐到人物姿态上做合成，保留面部、头发、身体结构，只换衣服。内部一般分三步：服装区域检测 → 姿态感知的对齐与形变 → 边缘混合。全程在你自己的显卡上跑，每一帧都不出你的机器。
第二条是云端 API 式，代表是 Kling 和 Bria。Bria 提供专门的 Virtual Try-On 模型，接口直给两张图；Kling 那边虽然也有试穿能力，但它真正的长板在姿势与动作控制，走的是 motion control 这条路线。你在 ComfyUI 里看到的 Kling 节点，很多是把云端能力包成了本地节点调用，图还是要传到服务端。
Clothes Changer 节点在虚拟试穿里做什么
这里有个细节值得展开：服装区域检测的准确度，直接决定后面两步的上限。检测框如果画小了，衣服换不全，旧衣的边缘会露出来；画大了，会把背景和皮肤一起框进去，边缘混合时就会带脏。而检测的准确度主要依赖两件事：人物图里旧衣服和背景的对比度，以及人物图和服装图的品类是否一致。这就是为什么后面讲预处理时，我会反复强调”背景干净”——它直接影响第一步。
姿态感知的对齐这一步最难，也最容易被误解。它并不是简单地把服装图缩放后”贴”上去，而是根据人物的肩线角度、手臂弯曲程度、腰部位置，把服装图的版型做局部形变。袖子要沿着手臂的角度弯折，下摆要根据胯宽张开，这些都需要模型对”这件衣服在人身上应该长什么样”有先验。keep_pose 正好作用在这一步的关键决策上。
这里再补充一个观察：对齐阶段的误差是会被后续放大的。肩线偏一厘米，到袖口可能偏三厘米；腰线偏两厘米，到下摆可能偏五厘米。所以在这一步之前，两张图的肩宽和腰线位置尽量对上，比事后调任何参数都有效。这也是为什么”两张图尺寸接近”这条规矩要排在第一。
在讲虚拟试穿两条路线的分工之前，得先把这个节点在虚拟试穿里的动作讲清楚，不然后面调参数你会不知道在调什么。Clothes Changer 这类节点的职责，用一句话说就是：把服装参考图对齐到人物姿态上做合成，保留面部、头发、身体结构，只换衣服。
它内部通常拆成三个步骤。第一步服装区域检测：从人物图里把”现在穿着的衣服”这块区域框出来，作为要替换的范围。第二步姿态感知的对齐与形变：根据人物的肩、肘、腕、腰、膝这些关键位置，把服装图的版型”掰”成能在这个人身上成立的样子。第三步边缘混合：把掰好的衣服贴回人物图，处理衣领、袖口、下摆这些交界处，让它和皮肤、头发过渡自然。
这三步里，第二步决定虚拟试穿的”形”，第三步决定”质”。keep_pose 开关影响的是第二步——开的时候，对齐过程只允许轻微的形变，姿势不动；关的时候，对齐过程可以推动身体重新摆位。而 edge_blend 这类参数影响的是第三步。搞清楚这个对应关系，调参时你就不会错怪开关。
为什么这两条路线不是替代关系
还有一个很少被提到的差异：调参的”手感”完全不同。本地节点的参数是一套连续的旋钮，你今天调 0.85、明天调 0.72，每一档都能留下经验；云端 API 的调用参数通常很少，你没法”微调”，只能换一版模型或者换一张输入。对愿意钻细节的人来说，本地节点的成长曲线更陡；对只看结果的人来说，云端更省心。
还有一个观察：本地节点式的门槛在于”第一次”，云端 API 的门槛在于”每一次”。本地第一次装节点、下模型、调通工作流可能要耗掉半天，但之后就一劳永逸；云端第一次调用十分钟就能出图，但每次都要考虑成本、并发、限流。做长期项目时，这两种门槛的形态差异会非常明显。
所以我在选型时会问一个很实际的问题：这个项目会做多久。只做一次的活动图，走云端；要做一年的商品库，走本地——因为本地节点调出来的参数可以沉淀成模板，而云端的经验基本不可迁移。
做虚拟试穿时，很多人的误区是把它们当成”新款和旧款”。其实不是。本地节点的优势是可控与可批量：seed 固定、参数可调、能挂批处理、能二次开发。云端 API 的优势是质感与省心：不用调参，出的图在布料质感和光影上通常更”贵”，因为背后是更大的模型和更精细的推理。
所以我在项目里的实际做法是：本地节点跑初稿和批量筛选，云端 API 只给要上首页的那几张。60 张图里我可能只会挑 8 张上云端精修。这样成本和时间都可控。
踩坑记录：三个让我改流程的瞬间
讲具体方法之前，先说三个真实踩过的坑，它们直接塑造了现在这篇文章的结构。
坑一：接反输入口。第一次搭图，我把服装图接到了”人物”输入，跑出来一批把人脸套在平铺 T 恤上的图。当时我以为是模型坏了，重下了两次模型才发现是线的问题。所以后面我坚持在连接清单里写清楚每个口连什么。
坑二：以为长裙必须开 keep_pose。客户说”姿势不能变”，我就一路 keep_pose = true。结果 12 张长裙里 9 张下摆穿进腿里。后来允许姿势微调、关掉开关，一次就过了 10 张。这件事让我明白，开关和”客户要求”之间需要一次翻译，客户说的”姿势不能大变”和”像素级不动”是两回事。
坑三：用 480px 的手机图硬跑。短边不到 500px 的人物图，模型在边缘混合阶段几乎无从下手，袖口一圈必然带色。换成 1200px 的原图后，同一套参数同一条工作流，问题自己消失了。
虚拟试穿的三种交付形态，先对号入座
在选方案之前，先想清楚你要交付的是什么。我把虚拟试穿的交付形分成三种：对照图（同一姿势前后对比，看换没换对）、单品图（只要一张好看的成片，不在乎姿势）、序列图（同一人多套衣服，要风格统一）。三种形态对方案的要求完全不同。
还有一个反常识的经验：对照图反而最难做。因为它把”姿势一致”和”衣服好看”两个目标同时摆在台面上，而这两者在 keep_pose 开着的时候天然冲突。做到能看，往往要靠”先关后开”跑两遍；做到好看，就得承认某一个目标要让步。新手最容易在这里陷入完美主义，然后三天出不了图。
对照图对姿势一致性要求最高，几乎只能本地跑加 keep_pose 开；单品图对质感要求最高，云端往往更省事；序列图对参数稳定性要求最高，本地跑的优势最大。先确定形态，后面的选择会轻松很多。
虚拟试穿方案对比：本地节点式 vs 云端 API 式
还有一个成本上的隐性差异：试错的成本形态不一样。本地节点的试错成本是时间，一张几秒，试一百次也就几十分钟；云端 API 的试错成本是钱，一次几毛到几块，试一百次就是几十到几百块。所以做本地流程时，我鼓励团队”多试”；做云端流程时，我要求团队”先想清楚再调”。
任何一张虚拟试穿成品，本质上都是两路信息合成的结果：一路是”谁在穿”，来自人物图；一路是”穿什么”，来自服装图。而 keep_pose 是那个决定”谁让步”的仲裁者。这两路信息只要有一路不干净，仲裁就得猜，猜的结果就是瑕疵。
下面这个结构图，是我给团队新人的第一页讲义，五分钟能讲完，但对后面所有问题的理解都有帮助。
结构就是这么简单。右边那一个节点，占了这个流程 80% 的不确定性；左边两个加载器，占了另外 20%。中间没有任何隐藏环节——这也是我推荐本地节点式的理由，每一根杠杆都看得见摸得着。
下面这张表是我自己在给虚拟试穿选方案时会对着看的版本。注意最后一列”翻车率”——它比性能参数更能决定你的项目排期。
| 维度 | 本地节点式（Clothes Changer） | 云端 API 式（Bria / Kling） |
|---|---|---|
| 输入形态 | 人物图 + 服装图，两个 LoadImage | 人物图 + 服装图，多数为 URL 或 base64 |
| 姿势控制 | 有 keep_pose 类开关，开=保姿势，关=允许重排姿态 | Bria 侧重贴合精度；Kling 侧姿势/动作走 motion control |
| 单张耗时 | SDXL 约 15-40 秒；FLUX 量化版 30-90 秒（视显存） | 通常 8-20 秒，受网络与队列影响 |
| 显存门槛 | SDXL 舒适 8GB；FLUX 量化版 8GB 能跑、12GB 舒适 | 不占本地显存 |
| 单张成本 | 电费，几乎为零 | 按次计费，批量时成本线性上升 |
| 可复现性 | seed 固定即可 1:1 复现 | 服务端模型更新后结果可能漂移 |
| 批量能力 | 批处理节点、脚本循环，几百张无压力 | 受并发与限流约束，需排队 |
| 隐私 | 全程不出本地 | 图片需上传到服务端 |
| 布料质感 | 依赖底模与 LoRA，需要调 | 开箱即用，通常更”贵” |
| 翻车率 | 输入干净时较低，输入脏时极高 | 较低，但对输入尺寸与构图仍有要求 |
| 适合场景 | 批量筛选、内部打样、私有数据、可二次开发 | 对外交付、高质感单图、无显卡团队 |
这张虚拟试穿方案对比表读下来，你会发现两件事。第一，本地节点式在”量”上碾压，云端在”质”上更稳。第二，两者的输入要求高度重合——都要人物正对镜头、背景干净、服装图清晰。这意味着你为本地流程做的输入预处理，换到云端一样能用，不会白做。
什么情况下虚拟试穿必须选本地
三个信号：一是数据不能出内网，比如品牌未发布的新品；二是数量大于 100 张，云端按次计费会疼；三是需要固定 seed 做 A/B，你要证明”换了服装图差异有多大”，云端做不到严格复现。
什么情况下虚拟试穿直接上云端
反过来，如果你只有笔记本核显、或者要的是”一眼贵”的成片、或者客户只给 5 张图但要求今天看到效果，别折腾本地。装节点、下模型、调参的时间成本，远超几十块 API 钱。
云端 API 那条线，怎么在 ComfyUI 里用起来
云端方案在 ComfyUI 里的形态，通常是一个封装了 HTTP 请求的节点：你把两张图以 URL 或 base64 的形式喂进去，节点返回一张合成好的图。它和本地节点的区别在于你没法看到中间的检测和混合过程，出了问题只能在输入上想办法，或者在输出之后做补救。
Bria 这条线适合什么
Bria 的 Virtual Try-On 模型主打的是贴合精度，对平铺图的版型还原很稳，袖子、领口这些地方通常不需要你手动补。缺点是它对输入的要求和你自己跑本地节点一样严格——还是那五条规矩。所以别指望换成云端就能省掉预处理。
Kling 的定位要说清楚
Kling 那边真正的长板在姿势与动作控制，走的是 motion control 路线。换句话说，如果你要的是”同一个人、同一件衣服、走两步、转个身”这样的动态展示，Kling 那条线比静态试穿更合适；如果你只要一张图，静态试穿节点更直接。这两件事不要混着谈。
一句话区分两张表
什么情况下云端也救不了
云端模型再强，也救不了这几种输入：人物被大面积遮挡（抱臂、背包、围巾）、服装图自带别人的身体轮廓、两张图色温相差一档以上。这几种情况下你花钱跑云端，出来的图一样有瑕疵，只是瑕疵的位置可能从袖口挪到了领口。所以我的原则是：先本地跑一张探路图，看出来属于这几类，就别急着上云端。
静态试穿看”贴得准不准”，动作控制看”动得自不自然”。前者决定你选本地节点还是 Bria，后者决定你要不要接 Kling。两者可以串起来用：先用本地或 Bria 出一张穿好的定稿图，再把它丢给动作控制做一小段展示。
虚拟试穿环境准备：装节点、下模型、算显存
先做个心理准备：装节点这一步，新手大概率会卡在依赖上。因为很多试穿节点依赖图像分割、姿态估计的库，包体不小，国内网络下装一次可能要十几分钟。我的建议是先把 pip 源换成国内的，再装，别在 Git 卡住的时候反复重试同一个命令。
还有一件小事但很致命：确认你的 ComfyUI 版本和节点兼容。自定义节点更新频率很高，ComfyUI 本体太旧时，节点能装上、能显示，但一点队列就报 “KeyError”。遇到这种情况，先升本体，别急着怀疑节点。我一般会把本体和节点都更新到同一周发布的版本，稳定性最好。
有一类问题经常被误判成”模型不行”，其实是环境问题。最典型的三种：装了节点但依赖没装全，节点加载了但只加载了一半；显存不够时 ComfyUI 会偷偷把一部分层丢到内存，速度掉三倍，你只以为模型慢；模型文件下了一半，节点照样能加载，但推理时输出的全是噪点。
所以下面这三步，我建议每一批新素材开跑之前都走一遍，五分钟的事。虚拟试穿最怕的就是在这种”看起来能跑”的状态里跑了两百张，才发现全废。
本地虚拟试穿路线开始之前，先确认三件事。第一，ComfyUI 已经能正常出 SDXL 或 FLUX 的图。第二，显存够。第三，你有一个专门放试穿素材的目录，人物图和服装图分开放，别混在一起。
虚拟试穿节点安装的两种方式
Clothes Changer 这类节点通用的安装方式是走 ComfyUI-Manager：打开 Manager → Install Custom Nodes → 搜关键词 → Install → Restart。如果你不用 Manager，就手动 clone 到 custom_nodes 目录，再装依赖：
cd ComfyUI/custom_nodes
git clone <节点仓库地址> comfyui-clothes-changer
cd comfyui-clothes-changer
pip install -r requirements.txt
# 回到根目录重启
cd ../.. && python main.py --listen 0.0.0.0 --port 8188
装完重启后在节点搜索框里输入 “Clothes”，能看到节点出现在列表里就说明加载成功。如果看不到，99% 是 requirements.txt 里的某个依赖没装成功，去看启动日志里的 ImportError，按名字重装那个包就行。
显存与模型选择
给一个具体的对照：8GB 显存跑 1024 短边的 SDXL 虚拟试穿，单张稳定在 20 秒左右，显存峰值大概 7.2GB，还剩一点余量；同样的图换 FLUX 量化版，单张 50 秒上下，峰值能摸到 7.9GB，稍微同时开个浏览器就可能 OOM。这个差距在实际批量里会被放大——200 张就是 66 分钟对 166 分钟。
显存这块的实测经验是：SDXL 在 8GB 上跑得很舒服，出图 1024×1024 不会爆；FLUX 的量化版 8GB 能跑但紧，分辨率上到 1536 就容易 OOM，12GB 才算舒适。虚拟试穿因为要多加载一路图像编码，实际占用会比同分辨率文生图再高 1-2GB，所以按这个标准往上预留一档更保险。
虚拟试穿的 Fast mode：4 步 Lightning LoRA 的取舍
很多试穿工作流自带一个 Fast mode 开关。打开时走 4 步 Lightning LoRA，但实际配置是采样 6 步、CFG 1；关掉则走完整的 30 步。这里的坑是：Fast mode 下提高 CFG 不是”更听话”，而是直接糊。Lightning 这类蒸馏 LoRA 就是为 CFG 1 设计的，你把 CFG 拉到 4 以上，画面会出现高对比噪点和色块。
我的经验法则：批量筛选阶段开 Fast mode，一张 6 步，60 张五六分钟跑完；选中候选后关 Fast mode 用 30 步重跑，边缘混合的瑕疵率大概能从肉眼可辨降到需要放大才看得清。这中间差的不是”好看”，而是”袖口那一圈有没有溢色”。
完整搭建虚拟试穿：把两张图接进 Clothes Changer
关于工作流文件的管理，也给个建议：每改一版参数，就把工作流另存一份，文件名带上日期和版本号，比如 tryon_v3_fast_kp1.json。虚拟试穿的参数组合很多，来回试的时候很容易”忘了刚才那个好版本是怎么配的”。存一份的成本几乎为零，找回来的成本可能是一下午。
再补充一个关于”为什么只有四个节点”的理解。有些人第一次看到这么简单的图会怀疑是不是漏了什么——没有 ControlNet、没有 IP-Adapter、没有分阶段采样。对，就是没有。Clothes Changer 这类节点把姿态对齐、服装匹配、边缘融合全封在一个节点里，你不需要手动拼这些环节。这既是它的优点（上手快），也是它的局限（出问题不好拆开定位）。
再啰嗦一句关于”先跑一张”的重要性。我见过太多人一次性把 200 张丢进队列，然后去吃饭回来发现全部失败，原因是最开始那一张就报错了，后面全是同样的错。正确的做法是：先跑一张，肉眼确认袖口、领口、下摆都正常，再开批量。这张图我管它叫”探路图”，它的存在价值就是省掉你一次吃午饭回来发现白干的绝望。
现在进入正题。整个图的骨架非常短，四个节点就能跑通。我把它拆成”连接清单”和”参数”两部分讲，因为新手最常犯的错就是把服装图接到了人物图的位置。
先看一眼虚拟试穿的最小可跑结构
之所以强调”最小”，是因为新手最容易在这张图上加东西。看到一个能跑的工作流，第一反应是”再加个高清修复吧””再加个 ControlNet 吧”，结果加到十来个节点，出了问题完全定位不了。先用四个节点跑通，把每一步的输出都看一遍，再往上加——这是我一贯的建议。
任何人第一次打开一个虚拟试穿工作流，都应该先确认它的结构。最小结构只有四段：
第一段是两个加载器。LoadImage 节点各一个，一个吃人物图，一个吃服装图。它们的输出都是 IMAGE 类型，没有别的花样。唯一的区别是文件名，但为了避免混淆，我习惯把节点标题改掉——右键 → Title，改成”人物图”和”服装图”，连线的时候眼睛不用来回确认。
第二段是核心节点。Clothes Changer 有两个 IMAGE 输入口，一个 image_person、一个 image_garment，外加 keep_pose、fast_mode、steps、cfg、seed 这些参数。它是整张图的唯一”决策点”，所有取舍都在这里。
第三段是输出。SaveImage 接 Clothes Changer 的 IMAGE 输出，不需要别的处理。有人会中间插一个 Upscale，我的建议是先别插——先把 1024 短边跑顺，确认贴合没问题，再考虑放大，否则你分不清瑕疵是放大带来的还是试穿带来的。
第四段是可选的后处理。比如挂一个 Mask 预览节点看服装区域检测的结果，或者挂一个图像对比节点把两张输入和输出并排显示。这两个在调参阶段非常有用，正式量产时删掉即可。
虚拟试穿的节点连接清单
下面是可以直接对着连的清单，编号和节点类型一一对应：
# 虚拟试穿基础工作流连接清单
[1] LoadImage (person.png) -> 人物图
[2] LoadImage (garment.png) -> 服装图
[3] Clothes Changer
image_person <- [1].IMAGE
image_garment <- [2].IMAGE
keep_pose = true
fast_mode = true
seed = 20261105
steps = 6 # Fast mode 实际步数
cfg = 1.0 # Lightning LoRA 必须为 1
denoise = 1.0
[4] SaveImage
images <- [3].IMAGE
filename_prefix = "tryon/sdxl"
注意三个细节。第一，Clothes Changer 有两个图像输入口，一个是人物、一个是服装，名字很像，接反了画面会变成”把人的脸套到衣服平铺图上”。第二，cfg 在 Fast mode 下必须是 1.0。第三，SaveImage 的 filename_prefix 带上目录前缀，批量跑的时候所有结果自动落到同一个文件夹，省得你事后翻。
还有一点容易被忽略：两个 LoadImage 节点的实际尺寸不必相同，但加载后最好先对齐再进核心节点。有些工作流在 LoadImage 后面挂了 Resize 节点，把两边短边统一到 1024，这一步看似多余，实际上能显著降低”二次拉伸”的概率。如果你的工作流里没有这一步，而两张图尺寸差得多，建议手动补上。
虚拟试穿的参数配置 JSON
先说明每个参数管什么，再给 JSON。这样你改的时候知道自己在动哪根杠杆。
keep_pose 管姿势，前面已经讲过。 garment_fit 管”服装对身体的贴合优先级”，值越高，模型越倾向于让衣服保持原版型，值越低越倾向于迁就身体。 edge_blend 管边缘过渡的软硬，高值柔和、低值锐利。 denoise 在试穿里一般保持 1.0，降下来会让原衣的残影留在衣服上。 steps 与 cfg 跟 Fast mode 绑死，前面讲过。 width 和 height 是输出尺寸，建议跟人物图的短边对齐。
如果你用 API 方式提交（后面会讲），或者想把自己的参数存成模板，下面这份 JSON 就是 Clothes Changer 这一节点完整的参数结构：
{
"class_type": "ClothesChanger",
"inputs": {
"image_person": ["1", 0],
"image_garment": ["2", 0],
"keep_pose": true,
"garment_fit": 0.85,
"edge_blend": 0.65,
"denoise": 1.0,
"seed": 20261105,
"steps": 6,
"cfg": 1.0,
"sampler": "euler",
"scheduler": "simple",
"ckpt_name": "sdxl_tryon_fp16.safetensors",
"width": 1024,
"height": 1365
}
}
garment_fit 控制服装对姿态的贴合强度，edge_blend 控制边缘混合的软硬。这两个参数我一般只在修特定问题时动——领口错位调前者，袖口溢色调后者，下面第四章会详细说。
虚拟试穿的 API 调用示例
批量跑虚拟试穿的时候推荐走 API，别在界面里一张张点。流程是：先把图上传到 /upload/image，再提交 prompt 到 /prompt，最后从 /history 取结果。client_id 和 prompt_id 对应上才不会拿错图。
在写代码之前，先在界面里把工作流跑通一次，然后点”Save (API Format)”导出一份 JSON。这份 JSON 就是你的模板，脚本只需要替换里面 LoadImage 的 image 字段和 ClothesChanger 里的参数值，其他原样提交。这样做的意义是——你调的每一个参数都在界面里先被验证过，脚本里不会出现界面里从来不生效的字段。很多人直接手写 JSON，结果某个字段名写错，节点默默用了默认值，你还以为是模型不行。
import json, requests, time, uuid
BASE = "http://127.0.0.1:8188"
CID = str(uuid.uuid4())
def upload(path, name):
with open(path, "rb") as f:
r = requests.post(f"{BASE}/upload/image",
files={"image": (name, f, "image/png")},
data={"overwrite": "true"})
return r.json()["name"] # 子目录时返回 subfolder/name
person = upload("assets/person_001.png", "person_001.png")
garment = upload("assets/garment_001.png", "garment_001.png")
wf = {
"1": {"class_type": "LoadImage",
"inputs": {"image": person}},
"2": {"class_type": "LoadImage",
"inputs": {"image": garment}},
"3": {"class_type": "ClothesChanger",
"inputs": {"image_person": ["1", 0], "image_garment": ["2", 0],
"keep_pose": True, "garment_fit": 0.85,
"edge_blend": 0.65, "denoise": 1.0,
"seed": 20261105, "steps": 6, "cfg": 1.0,
"width": 1024, "height": 1365}},
"4": {"class_type": "SaveImage",
"inputs": {"images": ["3", 0],
"filename_prefix": "tryon/batch01"}},
}
r = requests.post(f"{BASE}/prompt",
json={"prompt": wf, "client_id": CID}).json()
pid = r["prompt_id"]
while True:
h = requests.get(f"{BASE}/history/{pid}").json()
if pid in h:
for n in h[pid]["outputs"].values():
for img in n.get("images", []):
print("done ->", img["subfolder"], img["filename"])
break
time.sleep(2)
这段脚本跑通之后，把 person_001 换成循环变量，就是一个最小可用的批量试穿流水线。注意 seed 我写死了——批量阶段固定 seed，是为了让”换服装图”成为唯一变量，这样出问题你能立刻定位是哪边的问题。
虚拟试穿的输入清单怎么写
这份清单的使用方式也有讲究。它不是”检查一遍就完了”，而是每一批素材都重签一次，签完贴在本批次的目录里。因为素材的来源经常换，上周合格的供应商，这周可能换了拍摄团队、换了灯光。清单的意义在于把每次的质量都钉在纸上，出问题时可以回溯到哪一环变了。
我让团队每次交素材都签一张输入清单，逐项打勾。清单不长，但能把”忘了”这个最大的敌人挡住：
- 人物图短边 ≥ 768，服装图短边 ≥ 768，两者比例差 < 1.5 倍
- 人物正对镜头，肩线水平，四肢无大面积遮挡
- 人物背景为纯色或浅色虚化，衣服边缘无杂物
- 服装图为平铺或商品图，背景纯白，褶皱完整
- 两张图光照方向一致，色温偏差不超过 200K
- 文件名符合
p###_g###规则，人物与服装编号能对上 - 在
pairs/目录中已生成并排预览图，人工看过一遍
七条里只要有一条没打勾，就不要进批量。这套清单不是官僚主义，是让虚拟试穿的返工率从三成降到一成的关键。
keep_pose 开关：开还是关，这是个产品决策
还有一个判断维度很少被提到：这件衣服的”卖点”在哪。卖点在版型（廓形大衣、A 字裙），就该关；卖点在细节（刺绣、印花、领口工艺），就该开。因为细节要看清，就得让画面重心稳住；版型要看清，就得让衣服有空间舒展开。
这一节的结构是这样的：先讲两种模式各自的真实差异，再讲一个我反复用的判断口径，然后给判断表，最后讲一个绕开纠结的折中技巧。如果你只想快速做决定，可以直接跳到判断表，但建议还是把前面两小节看完——那张表能用，但用不好。
在进入具体判断之前，我想先说一个观察：大多数人对这个开关的第一直觉是错的。第一直觉是”开着更安全，毕竟不改姿势”，但实际跑下来，开着反而更容易出”衣服不对劲”的图。因为开着时，模型被你限制在原来的姿势里，它唯一的自由度就是怎么把衣服塞进这个姿势，于是所有妥协都压在了衣服上。
把这个直觉掰过来，是我带新人时最花时间的一件事。往往要他们自己跑二十张对比图，亲眼看到开着的那批肩线塌、袖子扁，才会真正信。
虚拟试穿里最容易被忽略的一件事是：这个开关背后的判断，其实不是技术判断，而是沟通判断。客户说”帮我换件衣服”，他没说的部分是”脸、姿势、原来的感觉都别动”。设计师说”这衣服穿不出味道”，他真正想说的是”这个姿势撑不起这个版型”。
所以我的经验是，谈需求的时候要把这句话翻译出来：“您要的是同一张图里的同一件衣服被人换掉了，还是同一个人穿出了这件衣服的样子？”前者开开关，后者关开关。这句话我用了三年，几乎没有客户拒绝回答。
这是整篇文章最重要的一节，也是绝大多数教程一带而过的地方。keep_pose 不是”画质选项”，它是一个语义开关，决定了模型把”符合原图”和”符合服装”这两件事哪个放在前面。
两种模式的真实差异
打开（keep_pose = true）：模型锁定人物原有的姿势、朝向、四肢位置，只把衣服换掉。好处是结果和原图能一一对应，做对比图、做前后对照毫无压力；坏处是服装被迫迁就姿势——一件廓形宽大的大衣套在一个双臂交叉的人身上，袖子会被硬挤成奇怪的形状，肩线也会塌。
关闭（keep_pose = false）：模型允许重排姿态来适配服装，衣服的版型、垂坠感、褶皱会更自然，尤其是长裙、宽袖、风衣这类对姿势敏感的品类；坏处是姿势变了，可能与原图差异很大，模特的手臂位置、身体朝向都可能改。
从参数角度理解：keep_pose 在 true 时，对齐阶段的形变预算被压得很低，模型只能在很小的范围内移动关节附近的布料；设为 false 之后，形变预算放开，模型有空间把袖子捋顺、把下摆撑开。所以这个开关的本质不是”保姿势”或”不保姿势”，而是“给不给布料留出被穿成立的空间”。这么理解，判断表就好记了。
“keep_pose 关掉才是真正的换装，开着只是换皮”
这句话我在内部培训里说过很多次，一开始有同事不理解。我的解释是：开着 keep_pose，你换掉的只是一层贴在身体表面的像素，衣服的版型没被真正”穿上”；关掉之后，模型才会为了让衣服成立去重新安排身体，这个动作才叫试穿。
打个比方：你拿一件男装店的西装，让一个双手插兜的人站着别动，你只能把西装”贴”在他身上；只有允许他动一动、把胳膊放下来，西装才能穿出样子。前者是修图，后者是试衣。
判断表：什么时候该开，什么时候该关
在给表之前，先提醒一句：在虚拟试穿里，keep_pose 不是二元的”对错”，而是二元的”代价”。开着，代价是衣服版型被压缩；关着，代价是姿势不再可控。所以选择标准不是”哪个效果好”，而是”你更能接受哪一种变”。这句话听起来像废话，但真正做决定的时候，很多人会在这里卡住。
| 你的目标 / 服装类型 | 建议设置 | 理由 | 可能出现的代价 |
|---|---|---|---|
| 上下装搭配成套、需前后对比 | keep_pose = true | 姿势一致才能看出”只换了衣服” | 宽大廓形容易塌肩 |
| 紧身 T 恤、针织衫、瑜伽服 | keep_pose = true | 贴身品类对姿势不敏感 | 几乎无 |
| 宽松大衣、羽绒服、风衣 | keep_pose = false | 廓形依赖身体留白 | 姿势会变，慎用于对比图 |
| 长裙、阔腿裤、汉服类 | keep_pose = false | 下摆与褶皱需要姿势配合 | 腿部位置会重排 |
| 原姿势有遮挡（抱臂、插兜、背包） | keep_pose = false | 遮挡处在 true 下必出伪影 | 整体构图可能偏移 |
| 商品详情页主图，要求复现原姿势 | keep_pose = true | 姿势是品牌资产 | 需人工修补肩线 |
| 社媒种草图，要”好看” | keep_pose = false | 自然度优先 | 无（姿势变化反而是优点） |
| 需要固定姿势做多套服装序列 | keep_pose = true + 高分辨率原图 | 序列一致性 | 需批量后处理 |
这张表的核心读法是：服装对身体的留白要求越高，越应该关掉 keep_pose。因为留白不是”没画东西”，而是”衣服撑出来的空间”，姿势不给这个空间，模型就只能硬挤。
再补一句实操观察。我按这个表跑了两批同样的服装图，一批全开、一批全关，肉眼对比下来，开着的图在领口和肩线上更”稳”，关掉的图在袖子和下摆上更”活”。两边强项刚好互补。于是我在实际项目里干脆对同一张图两个模式都跑一次，并排挑，挑中的概率比只跑一种高不少——反正 Fast mode 一张几秒，多跑一次不心疼。
一个折中技巧：先关后开
遇到非常纠结的图，我常用的流程是两次跑：第一次 keep_pose = false，拿到一张衣服版型正确的图；第二次以这张图作为新的人物图，keep_pose = true，固定 seed 跑一次轻度的细化。这样得到的是”姿势接近原图、衣服也成立”的结果，代价是多花一倍时间。对于要上首页的图，值。
这个技巧的原理其实是把一次决策拆成两次：第一次让模型去解决”衣服怎么穿得对”，第二次让模型去解决”看起来像不像原人”。每一次只让它专注一件事，成功率自然高。反过来，一次让它同时兼顾两件事，就会出现”两边都做了一半”的中间态——衣服没完全成立，姿势也没完全保住，是最难看的结果。
常见误判：不要用开关去修补拟合问题
有一种情况要特别提醒：如果服装图和人物图的品类完全不匹配，比如拿一件连体工装去套一条半身裙的人物图，那不管开关怎么拨都没用。因为对齐阶段需要的是”同类替换”，上下装互换、连体换分身，超出了这个节点的能力边界。遇到这类需求，正确的做法是把人物图换成只穿上衣的、或者只穿下装的，分段处理。
输入图预处理的五条硬规矩，逐条拆开讲
五条规矩总览
这五条不是并列的关系，而是有一条主线：让模型少猜。分辨率低，模型要猜纹理；正对镜头这一条，模型要猜身体朝向；背景脏，模型要猜哪部分是衣服；服装图不是平铺，模型要猜衣型；光照不一致，模型要猜阴影方向。每一条都是在减少一个”猜”的机会，五条全做到，模型就只剩最难的那一个判断——怎么把衣服穿上。
预处理还有一个容易被跳过的动作：把两张图并排放到同一块屏幕上比较。不是肉眼扫一眼，而是真的并排放大到 100%，对比人物的肩膀高度、衣服的肩宽、两者的色温。这一步能提前发现 80% 的对齐隐患。我甚至会在素材目录里建一个 pairs/ 子目录，把每一对配好的图做一张左右拼接的预览图，批量检查。
下面五条我在团队里挂在墙上，新人第一周必须背下来。它们不是”最佳实践”那种可选的建议，而是硬约束——违反了，就得接受出片率掉一半。
另一个反直觉的经验是：虚拟试穿的输入预处理，比试穿本身更值得投入时间。同样一套参数、同一条工作流，输入处理花十分钟和花一分钟，出片率能差 3 到 5 倍。我的比例大概是 1:3——每花一分钟搭图，就配三分钟整理素材。
老实说，我在这个项目里踩过的坑，八成都能归到输入图不合格。下面五条规矩，我按”犯了会有多疼”排序。
在展开之前先给一个总原则：虚拟试穿的合成有多好，取决于两张图各自有多”干净”。这里的干净不是”好看”，而是”没有歧义”——人物图里不能有让人搞不清哪部分是身体的遮挡，服装图里不能有让人搞不清哪部分是衣服的杂物。你喂进去越没有歧义，模型需要猜的地方就越少，出错的机会也越少。
虚拟试穿的短边为什么卡在 768 这条线上
虚拟试穿里，边缘混合阶段需要的细节密度，和服装图的织物纹理是挂钩的。一条针织的罗纹、一层牛仔的斜纹，短边低于 768 时基本被平均掉了，模型只能凭空”编”一块平滑的面料，结果就是衣服看起来像贴纸。768 是能保住这些纹理的下限，1536 是收益开始变平的上限。
虚拟试穿两张图尺寸差多少算”接近”
我的经验是短边比不要超过 1.5 倍。1024 配 1024 最稳，1024 配 800 也还行，1024 配 600 就开始出问题——这时候二次拉伸的比例超过 70%，肩膀和腰身的比例会明显走样。
规矩一：短边 768–1536px，两张图尽量接近
输入短边建议落在 768 到 1536 之间。低于 768，边缘混合处会糊；高于 1536，收益递减且显存吃紧。更重要的是人物图和服装图的尺寸尽量接近，因为对齐阶段是按比例做形变的，两边比例差太多，模型会二次拉伸，伪影就是这么来的。
规矩二：人物正对镜头
人物正对镜头的图最容易对齐。侧身 45 度以上、俯拍、仰拍，都会让对齐阶段”猜”姿势，而猜错的直接后果就是领口错位和袖子溢色。如果原图是侧身，先裁切或重拍，别指望模型硬修。
还有个更隐蔽的情况：人物是正的，但相机是斜的。手机手持拍的时候，地平线偏两三度很常见，人眼会自动校正，但虚拟试穿的对齐不会。所以在预处理时顺手做一次水平校正——以肩线或两眼连线为基准转正，很多时候能直接消掉肩线歪斜的问题。
规矩三：背景干净
纯色背景或浅色虚化背景最好。背景里的杂物会影响服装区域检测，尤其是深色物体贴着衣服边缘时，检测框会往外扩，边缘混合处就会带进背景色。
判断背景是否合格，我用一个很土的办法：把图缩到 25% 看。缩小之后仍然显得干净的，基本没问题；缩小之后边缘有明显灰边的，说明背景不够纯。这个办法比放到 200% 盯着看更接近最终成品在页面上的观看条件。
规矩四：服装图最好是平铺图（flat lay）或清晰商品图
如果只能拿到模特穿着图，走之前那一步：先把人抠掉。抠图之后留下的衣服轮廓，多少会带一点原模特的身体弧度，但比直接喂进要好得多。抠的时候宁可多留一点衣服边缘，也别把袖口裁掉——衣服的完整性对虚拟试穿来说比背景的纯净更重要。
虚拟试穿的服装图，褶皱信息比颜色更重要
这句话我专门拿出来说，因为绝大多数人刚好反过来想。大家拿到一张服装图，第一反应是”这个颜色对不对、这个花色清不清楚”，然后就去调色的饱和度、对比度。但颜色错了，模型还能从像素里读出一致的色值；褶皱没了，模型就彻底失去了布料的体积感。
为什么褶皱决定成败
一件衣服在身上成立，靠的是三样东西：轮廓、褶皱、阴影。轮廓来自版型，褶皱来自布料和身体的相互作用，阴影是前两者的结果。一张被电商滤镜磨平的商品图，把后两样全删掉了，模型只能按”最平的方式”把衣服盖上去，看起来就像贴图。这就是为什么同样一件衣服，平铺图和棚拍穿着图跑出来的质感差得很远。
平铺图的褶皱信息最完整，商品图次之。最差的是”模特穿着同款”的街拍图——它自带别人的身体轮廓，模型会把别人的体态当成服装的一部分学进去。如果只能拿到街拍图，先抠图、去掉身体。服装图里的褶皱信息，比颜色更重要，这一点我后面还会展开。
规矩五：光照方向一致
人物图的打光和服装图的打光方向要接近。人物图是左侧光、服装图是右侧光，合成出来的衣服会出现”影子朝反方向”的违和感，这种违和你一时说不清是哪里不对，但眼睛会立刻察觉。预处理时把服装图的亮度翻转一下，或者用统一的白底棚拍图，能省很多事。
规矩之外的加分项：先做一次尺寸归一
五条硬规矩之外，还有一个几乎零成本的动作：批量预处理时用同一个脚本把两张图的短边统一到 1024。用哪条命令都行，Pillow、ImageMagick、Photoshop 批处理都可以，关键是”统一”。我见过一个团队用不同的工具裁切，结果有一半的图短边是 1024、另一半是 1080，比例也各不相同，模型在每一张上都要重新适应尺寸，瑕疵分布就变得毫无规律，根本没法定位根因。统一之后，你会突然发现”同样的参数，有的图好有的图坏”这件事，其实来自素材本身，而不是随机。
输入图规格速查表
| 项目 | 推荐值 | 下限 | 不合格后果 |
|---|---|---|---|
| 短边分辨率 | 1024–1536px | 768px | 边缘模糊、纹理丢失 |
| 人物：服装 尺寸比 | 1 : 1（尽量） | 不超过 1 : 1.5 | 二次拉伸、比例失真 |
| 人物朝向 | 正对镜头，偏差 < 15° | 偏差 < 30° | 领口错位、袖口溢色 |
| 人物背景 | 纯色或浅色虚化 | 杂物不贴衣物边缘 | 检测框外扩、带背景色 |
| 服装图形态 | 平铺图 / 商品图 | 抠干净的正面平铺 | 褶皱丢失、体态被误学 |
| 服装背景 | 纯白 / 透明底 | 单色 | 杂色渗入边缘 |
| 光照方向 | 两张图同为正面或同侧光 | 方向差 < 45° | 阴影反向，违和感强 |
| 文件格式 | PNG 无损 | JPEG 质量 ≥ 95 | 压缩块被放大 |
这张表打印出来贴在显示器边上不丢人。我见过一个团队连续三周抱怨”模型不行”，最后发现是他们的素材全是手机直出、短边只有 480px。换了素材，”模型”立刻就好了。
一张表看完输入规格
把上面五条规矩收拢成一张速查表，下面是完整版。打印出来作为素材验收标准，比口头传达有效得多。
| 检查项 | 理想值 | 可接受 | 不可接受 |
|---|---|---|---|
| 人物图短边 | 1024–1536px | 768–1024px | < 768px |
| 服装图短边 | 1024–1536px | 768–1024px | < 768px |
| 两张图比例差 | < 1.2 倍 | 1.2–1.5 倍 | > 1.5 倍 |
| 人物朝向偏差 | < 10° | 10–30° | > 30° / 侧身 |
| 人物背景 | 纯色 / 透明 | 浅色虚化 | 杂物贴衣物边缘 |
| 服装图形态 | 正面平铺 | 正面商品图 | 模特穿着图 / 街拍 |
| 服装图背景 | 纯白 | 单色 | 多色 / 带阴影 |
| 褶皱完整度 | 自然褶皱清楚可见 | 轻微褶皱 | 过度磨皮、完全平整 |
| 光照一致性 | 同向顶光或正面光 | 方向差 < 45° | 一左一右 / 一硬一软 |
| 色温偏差 | < 200K | 200–500K | > 500K |
| 文件格式 | PNG | JPEG ≥ 95 | JPEG < 85 / 截图 |
这张表我贴在了团队素材盘的首屏。每次新项目进来，第一件事就是让素材负责人按这张表过一遍，不通过的退回重拍或重新找图。半年下来，虚拟试穿的一次通过率从四成出头提到了七成多，工并没有多花，只是把功夫挪到了前面。
虚拟试穿的贴合逻辑：先想清楚再调参
为什么要把这一节放在贴合失败之前？因为绝大多数人在遇到问题时，第一反应是”调哪个参数”，而不是”这是不是一个结构性矛盾”。参数是最后一公里的修补工具，它救不了结构性的错配。先想清楚贴合逻辑，你才知道什么时候该收手调参、什么时候该推倒重来。
调参之前，先把一个逻辑想明白：贴合不是”把衣服压到人身上”，而是让衣服和人互相迁就到一个共同成立的形状。这个共同形状由三个因素决定：衣服的版型、人的体态、姿势提供的空间。三者之中，你能改的是第三个（通过 keep_pose），能换的是前两个（通过换图）。参数只能在前三者定下来之后做微调。
为什么调参总是”按下葫芦浮起瓢”
因为它是个零和博弈。你把 garment_fit 调高，领口正了，袖子却变紧了；你把 edge_blend 调低，袖口干净了，脖子那里却出现了一道硬边。这不是参数不好用，而是你在用参数去补结构上的矛盾。结构问题只有一个解：换输入，或者换开关。
所以我给自己定了一条：同一个参数最多连续调两轮，调不好就回去改输入。两轮之后还在反复，说明问题根本不在这个参数上。
贴合逻辑的优先级排序
按”改起来最省事”排序，我的优先级是：换服装图（最快，重新找素材就行）→ 换人物图（次快，要重新拍或找）→ 调 keep_pose（一次跑一张，几秒钟试出来）→ 调参数（最慢，要反复试）。很多人反着来，一上来就调参数，结果花了半天发现换张图就能解决。
ComfyUI 里跑虚拟试穿，和直接用 Bria 网页版有什么区别
区别在于你能控制多少。网页版你只能换图、点生成；ComfyUI 里的虚拟试穿，你可以固定 seed、批量喂图、把结果接到下游节点继续处理（比如自动加背景、自动拼对比图）。对做内容的人来说，后者意味着”一次点击变成一条流水线”。
另一个区别是误操作的成本。网页版点错了无非再点一次；ComfyUI 里改了参数忘了存，第二天可能完全复现不出那张满意的图。所以我在团队里要求，任何一次”满意结果”都必须当场存工作流。
虚拟试穿的服装图和人物图，谁更重要
这是个经常被拿来争论的问题，我的答案很明确：人物图更重要。因为人物图决定了”能不能穿”，服装图决定了”穿得像不像”。人物图不合格，比如侧身、低清、遮挡，整张虚拟试穿根本立不住；服装图不够好，你至少能得到一张”衣服简单但成立”的图，还能靠后续处理补。
所以时间分配上，我会把 60% 的精力放在人物图筛选，40% 放在服装图。这个比例和大多数人的直觉相反，但跑过几百张之后你会同意我。
虚拟试穿的结果要不要放大
要，但不要用生成式放大。我的做法是先出 1024 到 1536 的虚拟试穿结果，再用普通的 Lanczos 放大到交付尺寸，最后轻微锐化。生成式放大容易在衣服的纹理上”编”出不存在的细节，比如把纯色织物补出奇怪的纹路，反而破坏真实感。
如果交付尺寸需要 2048 以上，更好的是把虚拟试穿本身的输入提到 1536，再放大一倍。这样核心合成在高分辨率下完成，边缘更干净。
虚拟试穿和传统修图的根本区别
还有一层区别是可批量性。传统修图，换一件衣服就是一次手工，一百件就是一百次；虚拟试穿调好一次，一百件只是一个循环。所以传统修图的价值在”单张能到极致”，虚拟试穿的价值在”平均分大幅抬高”。做内容站的人应该清楚，绝大多数内容需要的从来不是极致，而是稳定达标。
明白这一点，就不会纠结”为什么虚拟试穿某一张不如精修的图”。因为它的目标不是打败精修，而是让九成的图不需要精修。
传统修图换衣服，是把一件衣服”P”到人身上，形状、褶皱、光影全靠人手一笔笔画。虚拟试穿不一样，它重新生成了衣服覆盖的那块像素，让模型按自己对布料的理解去画。所以修图的结果服从你的手，虚拟试穿的结果服从模型的先验。
理解了这个区别，你就不会问”为什么虚拟试穿出来的衣服和我给的不完全一样”。它本来就不是复制粘贴，它是”照着这件衣服重新画一遍”。
阴影是虚拟试穿里最容易被忽略的一项
衣服穿在身上，一定会在身体上留下投影——下巴投在锁骨上、袖子投在腰上、裙摆投在腿上。好的虚拟试穿会自己补出这些影子，差的会漏掉，于是衣服看起来”飘”在身体前面。这也是为什么光照方向一致这条规矩那么重要：模型补影子时，会参考两张图里既有的光向，两张图打架，影子就乱。
虚拟试穿的模型怎么选：SDXL 还是 FLUX
我的经验是看显存和时间。8GB 的机器，SDXL 是唯一舒适的选择，1024 短边二十秒出头；12GB 以上，FLUX 量化版可以上，质感更细腻，但单张可能到一分钟。虚拟试穿是批量场景，速度往往比画质更关键，所以我大多数项目跑的是 SDXL。
另外，SDXL 和 FLUX 在边缘处理上的风格不同：SDXL 的边缘更容易出现”软过渡”，溢色的概率稍高；FLUX 的边缘更”实”，但需要更严格的输入，否则硬边会更显眼。选之前先想清楚你的输入有多干净。
虚拟试穿里最容易被忽略的一步：把结果重新看一遍
工作流跑完、文件落地，很多人就直接交付了。我要求团队多做一步：把输出图和两张输入图并排放在一起看一遍。这一步花不了几十秒，但能发现大量”单看没问题、一对比就露馅”的问题，比如颜色偏了半档、袖长短了两厘米、褶皱方向反了。
人眼对这种细微差异非常敏感，前提是有参照。没有参照的时候，大脑会自动把结果”合理化”。这个过程叫视觉适应，是内容交付里最危险的陷阱之一。
为什么说虚拟试穿的服装图是”第二个演员”
很多人把服装图当成”素材”，其实在虚拟试穿里它更像”第二个演员”——它有自己的肩线、腰线、袖长、下摆弧度，而这些特征都要被完整地搬到人身上。你给一张皱巴巴的、背景带杂物的服装图，相当于给这位演员穿了一身不合身的戏服，怎么拍都别扭。
所以我处理服装图的标准，和处理人物图一样严格：抠干净、白底、正面平铺、褶皱完整。宁可多花十分钟，也别在一张脏图上赌运气。
虚拟试穿能不能处理多件叠穿
可以，但一次只换一件。外套套内搭、连衣裙加马甲这种叠穿需求，我的做法是按从内到外分步跑：先换内搭，把结果当新的人物图，再换外套。每一步都固定 seed，最后得到的是一个能对上的序列。一次性让模型换两件，两件都会对齐不好。
叠穿还涉及一个细节：内搭的领口、袖口会露在外套外面。分步跑时，第二步的外套虚拟试穿要保证内搭露出部分没有被覆盖，这通常靠外套的服装图本身就能解决——只要那张图是真实穿着拍出来的、带内搭的。
虚拟试穿提示词的误区
还有一个更常见的误区：把虚拟试穿当文生图，拼命在提示词里描述衣服。比如写”a long black wool coat with double-breasted buttons”，然后发现出来的衣服和服装图不一致。原因很简单——模型看的是服装图这一路，不是文字这一路，文字写再多也改变不了衣服的形状。
经常有人问”虚拟试穿要不要写提示词”。我的答案是不用太费心。这类节点的核心是图像对齐，不是文本生成，提示词对结果的影响远小于两张输入图。你写”a woman wearing a red coat”和什么都不写，差别可能只是色调的一点点偏移。
真正值得写的是否定词，比如避免”extra fingers””distorted”这类结构性错误。因为虚拟试穿在重绘脸部附近时，偶尔会顺带处理到手部，加几条否定词能减少废片。但别指望它解决袖子、领口这些贴合问题——那些不属于文本的管辖范围。
虚拟试穿的工作流应该被版本化
我的团队成员都用 Git 管理 ComfyUI 的工作流文件。每改一次，提交一次，写清楚改了什么、为什么改。虚拟试穿的项目动辄跑几百张，没有版本管理的话，三天后你根本找不回”那次效果最好的版本”。
版本化还有一个副产品：团队能互相 Review。有人调出了更好的边缘参数，另一个人能看到并学习。这件事对长期能力积累的价值，远超过省下的那几分钟提交时间。
虚拟试穿里，服装区域检测不准会有哪些表现
检测不准是最难排查的一类，因为它不表现为”衣服错位”，而表现为”换不完”。具体有三种：领口处露出一截旧衣、袖口外侧带一圈旧衣的颜色、下摆边缘有一条旧衣残影。这三种都是检测框画小了。
反过来，检测框画大了的表现是背景渗入、手臂边缘出现脏色。判断方法很简单：放大看问题区域和衣服主体的交界处，如果颜色是从外往里渗的，就是框画大了；如果是从里往外漏的，就是框画小了。这个判断花不了十秒，但它能决定你后面是调参数还是换图。
虚拟试穿四类贴合失败：症状、成因与修法
下面四条我尽量给”能直接照着做”的动作，而不是”建议提高质量”这种话。因为在这个位置，人的耐心已经很薄了，需要的是明确的下一步。
还有一个虚拟试穿的前置判断：这四类问题里，哪一类是你这个品类必然要面对的。做羽绒服的团队，第一优先级永远是袖子和肩线；做连衣裙的团队，第一优先级永远是下摆；做衬衫的，第一优先级永远是领口。搞清楚自己的”高发区”，比把所有参数都调一遍更高效。
这四类问题我按出现的频率排过序：袖口溢色最常见，大概每 10 张里有 3 张会有轻微表现；领口错位次之，大概 2 张；下摆穿透集中在长款，短款几乎不出现；褶皱丢失最隐蔽，你不仔细看根本发现不了，但一放到详情页主图的位置就露馅。
排序的意义在于注意力分配。批量筛选阶段，我第一眼看的永远是袖口——因为它是最高频的失效点，先用它筛掉一批，后面的问题就好定位了。
服装与人体贴合度的问题，主要就出现在四个位置：袖子、领口、下摆、褶皱。这四处的共同点是——它们都是”布料与身体发生关系”的地方。下面逐条拆。
有一个总规律值得先记住：袖子的问题多半是”宽度”问题，领口的问题多半是”位置”问题，下摆的问题多半是”前后”问题，褶皱的问题多半是”信息”问题。出了瑕疵先归类，再想根因，能省掉大量瞎调。
第一类：虚拟试穿的袖口溢色
症状是袖子边缘一周出现一条不属于衣服颜色的细线，常见的是背景色、肤色或旧衣服的颜色渗进去。成因八成是人物图的袖子边界不清晰或服装图没有纯色背景，边缘混合阶段把过渡区的平均色采了进来。
修法：先把服装图背景处理成纯白，再把 edge_blend 从 0.65 降到 0.45，让边缘过渡更”硬”一点；如果还不行，把输入短边提到 1280 以上重跑——溢色在高分辨率下会明显变细，很多时候肉眼就看不见了。
第二类：虚拟试穿的领口错位
症状是领子的开口偏左或偏右，或者 V 领变成了圆领。成因是人物转头或倾斜导致对齐阶段的颈部关键点估计偏差，或者人物图与服装图的领口版型本身差异过大（比如服装图是立领，人物图原衣是低领，模型在两者间纠结）。
修法：优先换一张正对镜头的人物图，这一条能解决七成领口问题；其次把 garment_fit 提到 0.9 以上，让服装版型优先；最后再考虑关掉 keep_pose 让模型重排一次——很多时候领口一正，整张图就成立了。
第三类：虚拟试穿的下摆穿透
症状是长裙或长外套的下摆穿进了腿里，或者下摆边缘出现一条锯齿状的”断裂线”。成因是下摆区域与腿部区域在深度上重叠，而模型的对齐没有正确排出前后关系，尤其在收腿、交叉腿的姿势下最容易发生。
还有一种”假穿透”值得区分：衣服本身没问题，是人物图里原来的下摆位置太高，新衣服的下摆被拉到了那块空白区域，看起来像悬空。区分方法很简单——看下摆下缘有没有和腿部像素交界，有尖锐锯齿交界的是真穿透，边缘平滑但位置不对的是假穿透。前者关开关，后者换人物图。
修法：关掉 keep_pose 是第一选择，让模型重排腿部姿势给下摆腾出空间；如果不允许改姿势，就在人物图里裁掉下半身、只保留上衣部分做试穿，再把下半身单独跑一次再拼。这种”分段试穿”有点笨，但在硬性要求下的成功率最高。
第四类：虚拟试穿的褶皱丢失
症状是衣服看起来像贴在身上的贴纸，没有布料该有的起伏和阴影。成因几乎只有一个：服装图的褶皱信息不足。一张被过度磨皮、或者被电商滤镜拉平的商品图，褶皱本来就没有，模型自然也造不出来。
修法
换一张褶皱完整的平铺图，这比调任何参数都有效；其次把 denoise 保持 1.0 别降，降低 denoise 会让模型保留人物原衣的褶皱，反而更乱；还可以在服装图一侧做轻微对比度提升（+10% 左右），把褶皱的明暗差拉开。
虚拟试穿问题修复对照表
| 问题 | 主要症状 | 根因 | 首选修法 | 次选修法 |
|---|---|---|---|---|
| 袖口溢色 | 袖子边缘有异色细线 | 边缘过渡区采到背景/肤色 | 服装图背景改纯白 | edge_blend 降至 0.45，短边提到 1280 |
| 领口错位 | 领子开口偏向或版型改变 | 颈部关键点偏差 / 版型冲突 | 换正对镜头的人物图 | garment_fit 提到 0.9 以上 |
| 下摆穿透 | 衣摆穿进腿、锯齿断裂 | 前后景深度关系错误 | 关掉 keep_pose | 分段试穿后拼合 |
| 褶皱丢失 | 衣服像贴纸，无起伏 | 服装图褶皱信息不足 | 换褶皱完整的平铺图 | 服装图对比度 +10%，denoise 保持 1.0 |
| 肩线塌陷 | 宽肩服装撑不起来 | 原姿势限制留白 | 关掉 keep_pose | 换外层廓形更清楚的服装图 |
| 颜色偏差 | 成衣色比服装图暗/灰 | 光照方向不一致 | 统一两张图的打光方向 | 服装图轻微提亮 +5% |
这张表的用法是先看根因列，别直接跳到修法列。因为同一个症状可能有两个根因，比如”领口错位”既可能是关键点偏差也可能是版型冲突，前者换图，后者调参数。搞清楚了再动手，比盲试十次参数省事。
虚拟试穿批量流程：怎么把 60 张跑成 60 张
批量之前先定一个最低标准：什么东西必须一次通过，什么可以事后补。我的标准是”袖口、领口、下摆必须一次通过，褶皱和色偏可以事后补”。因为前三个是结构性的，补起来痕迹重；后两个是表层的，补起来几乎看不出。用这条标准去筛，能省下大量修复时间。
批量的真正难点不是技术，而是可追溯。60 张跑完，你手里有 60 个文件，接下来一周你会反复问自己：这张是开着开关跑的还是关着的？那个袖口溢色的是哪一版参数？如果一开始就把这些信息写进文件名，这些问题一秒就能回答；否则就是一场考古。
还有个关于时间安排的技巧：把批量跑放在你不看屏幕的时候。虚拟试穿单张是秒级，200 张也就十几分钟，人盯着反而容易焦虑，中途改参数会把批次搞乱。我的习惯是晚上把队列挂上，第二天早上一次性看结果，反而比边跑边调更容易看出版差。
批量之前还有一个决定要想清楚：要不要在一次批量里混跑两种 keep_pose。我的做法是按品类分两批——宽松款一批关，贴身款一批开。混在一起跑虽然省事，但事后你会发现自己根本记不清哪张是哪批的，尤其是文件名没规范的时候。
还有个小技巧：批量时把前 5 张单独跑一次、人工抽检，如果这 5 张里有 2 张以上有问题，就说明批量本身有系统性错误（参数、素材格式、尺寸），这时候停下来比继续跑值。
单张虚拟试穿跑通之后，真正的工程问题才开始。批量阶段有三件事必须定下来：seed 策略、参数分组、命名规则。
批量虚拟试穿前，先跑一张”探路图”
“探路图”这个习惯我用了很多年，最早是在渲染农场做动画时养成的。它的核心不是”先跑一帧看看”，而是用最低的成本，验证最高层级的不确定性。在虚拟试穿里，最高层级的不确定性是：这两张图到底能不能配。
所以探路图我会选整套素材里最不典型的那张去跑——人物姿势最怪的、或者服装版型最特殊的。如果最差的那张都能看，剩下的基本没问题；反过来，拿一张最标准的去试，试了等于没试。
虚拟试穿的 seed 策略
我的做法是全局固定 seed + 单独记录。批量阶段用一个固定 seed（比如 20261105），让所有图在同一个随机起点下生成，这样你换服装图时，差异全部来自服装图。等到挑出满意的几张，再给每张分别试 3-5 个 seed 做微调，把最终 seed 写进文件名。
虚拟试穿的参数分组
把参数分成两组：A 组是”跟图走”的，比如 keep_pose、garment_fit、edge_blend，因为不同品类需要不同值；B 组是”跟流程走”的，比如 steps、cfg、sampler，全批次统一。API 批量时把 A 组做成一列 CSV，用脚本读进来替换，这是最省心的做法。
虚拟试穿的命名规则
文件名带上关键参数，比任何数据库都实用。我的格式是 {person}_{garment}_{keep}_{seed}.png，例如 p001_g017_kp1_s20261105.png。三个月后回来看，你一眼就知道这张图是开着 keep_pose 跑的——因为”这张是不是开着开关”是返工时最常需要确认的信息。
虚拟试穿之后的人工修复流程
修复还有一个前提：确认这张图值得修。判断标准是它会不会出现在最终交付的核心位置。会，就修；不会，就丢进备选池，别浪费时间。内容生产里最常见的浪费，是把时间花在不会被人看到的图上。
修复这件事，团队里最好只有一个标准。三个人各修各的，最后交出去的一套图风格会散。我的做法是写一页修复规范：只允许动哪些区域、蒙版羽化多少像素、修完之后保留原始文件在哪。规范很短，但它让”修过的图”看起来像”没修过的图”，这是修复的最高标准。
修复这件事，最怕的不是麻烦，而是把本来可以重跑解决的问题，硬用手工去补。手工补出来的东西往往在放大之后原形毕露：边缘有轻微不连续、褶皱的方向和周围对不上、阴影的软硬不一致。客户可能一时看不出，但换一张图放在一起对比，就会立刻发现哪张是”修过”的。
所以我把修复当成最后手段，而不是第二手段。真正该花时间的地方，永远是”为什么这张会出错”，而不是”怎么把这张救回来”。
再好的虚拟试穿流程也会有几张需要修。我给自己定的规矩是：单张修复不超过 10 分钟，超过就重跑。因为重跑一张 6 步的成本远比手工修十分钟低，而且重跑更不容易留痕。
这条规矩还有个隐藏好处：它逼我把注意力放在根因上。因为这套虚拟试穿流程里”修”的预算有限，我不会一发现问题就钻进去手工处理；”重跑”很快，所以我更愿意去问”为什么会这样”，而不是”怎么把这块补起来”。久而久之，流程本身的质量会往上走。
虚拟试穿修复的三个层级
三层之外，还有一种”不上台面但很有效”的手段：换一张同款、不同角度的人物图。很多问题的根源其实是这一张人物图本身不适合，换一张正面、光平、背景干净的，同一条工作流、同一套参数，出来的图能好一个档次。这不算修复，算”换题”——但很多时候，换题比解题快。
三个层级之外，我还加了一条内部规矩：每一张修过的图都要留一张”原始输出”，命名加后缀 _raw。原因很现实——修的时候觉得”这样就够了”，一周后客户改需求，想回到原始版本重跑，结果发现原始文件已经被覆盖了。留一份 raw 的成本是几十兆硬盘，不留的代价是一次返工。
第一层，重跑：换 seed、关/开 keep_pose、换输入图，任何一项都可能解决问题。优先做这一层。
第二层，局部重绘：只对出问题的区域做 inpainting，比如把袖口圈出来重绘。这一层要注意蒙版要略微超出问题区域 10-20 像素，否则接缝会很明显。另外，重绘时务必让 keep_pose 保持和原图一致——如果原图是关着开关跑的，重绘却开着，局部会突然”变正”，和周围对不上。
第三层，手工修：Photoshop 里修边缘、拉直领口、补褶皱。这一层只在”图必须交、且重跑也不解决”时用，而且一定保留原图作为对照。
一张问题图，实际的判断顺序
我通常会问自己四个问题，按顺序：问题只在一张图吗？→ 是，重跑。换个服装图能解决吗？→ 能，说明是服装图的问题，换输入。关掉 keep_pose 能解决吗？→ 能，说明是要不要保姿势的问题，回到决策层。以上都不行？→ 才进修复。
这个顺序的好处是，它把 90% 的问题挡在了修复之前。我见过太多人一上来就开 PS，修了半天发现是原图没正对镜头。
我的虚拟试穿取舍清单：什么情况用什么组合
三个阶段之间的切换点，我一般用”候选数量”来判断：候选压到 20 张以内，进精修；精修后压到 5 张以内，进交付线做云端。数字不用太精确，关键是每个阶段都有一个明确的退出条件，否则很容易在某个阶段反复打转。
有人问我，为什么不像很多教程那样给一张”最佳参数表”。因为虚拟试穿没有最佳参数，只有”适配你这批素材”的参数。同一组数值，在背景干净的素材上是神，在背景脏的素材上是灾难。所以这张清单给的是流程节奏，而不是魔法数字。
另有一条经验：不要把”分辨率”和”步数”同时往上拉。1280 短边配 30 步，一张图可能要一分半，200 张就是一小时，多数时候你并不需要这么高的配置。我的习惯是先只提分辨率、步数留 6，看效果；不够再把步数提到 30。因为分辨率解决的是”细节够不够”，步数解决的是”细节干不干净”，多数情况下前者是瓶颈。
在给组合之前，先说清楚为什么取舍要分阶段。虚拟试穿这件事的失误有两种：一种是”错得明显”，比如袖子穿帮、领口歪掉；另一种是”对得不对味”，比如衣服颜色偏了一点、褶皱浅了一点。前者用快跑就能筛出来，后者必须慢跑才能看出来。所以流程天然应该从快到慢、从粗到细，而不是一上来就追求完美。
下面这套参数组合是我在项目里实际跑的。所有数字都是 24GB 显存机器上的实测体感，8GB 机器可以把短边降一档，做法不变。
批量筛选期
这个阶段的唯一目标是”快速否定”。一晚上过两三百张的时候，我不会停在任何一张上超过三秒，只看三件事：袖口有没有溢色、领口有没有歪、下摆有没有穿。三件事都过，打个标放进候选；任一没过，直接过。停留越久，越容易陷入”这张是不是还能救”的自我怀疑。
SDXL 短边 1024、Fast mode 开（6 步 / CFG 1）、keep_pose 按品类分两批跑、seed 固定。目标是”快”，不追求单张完美。这个阶段我一晚上能过 200 到 300 张，选出 30 到 40 张候选。
精修期，先关掉 Fast mode
候选图关 Fast mode 走 30 步、短边提到 1280-1536、对纠结品类同时跑 keep_pose 开与关两版、每个候选试 3 个 seed。目标是”稳”。
精修期的核心不是”参数调得更细”，而是把变量收少。筛选阶段你可能同时开着批量、换图、固定 seed；精修阶段就该反过来：一次只改一个参数，一次只看一个位置。比如这一轮只关注袖口，下一轮只关注领口。这样每轮结束你都确切知道”是哪个改动带来了改善”，而不是笼统地觉得”好像好一点了”。
交付期
本地跑不动的图丢云端，Bria 走试穿；需要动作展示的话，Kling 那边走 motion control 生成一小段。目标是”贵”。
这里再补一个我经常被问的问题：能不能一直开着 Fast mode 交付。答案是可以，但有前提——品类是贴身的、输入是干净的、分辨率够高。这三条满足时，6 步和 30 步的差别很小；反之，只要有一条不满足，30 步的差别就会立刻显现在袖口和衣摆上。我的判断标准是”瑕疵出现在瑕疵率 10% 以内就交付”，超过就老实走 30 步。
三个阶段共用同一套输入预处理——这就是前面说的，为本地流程做的输入规范，云端一样吃。
把整套流程沉淀成可复用资产
为什么值得做这件事？因为虚拟试穿这个领域变化很快，模型一版一版在更新，参数和节点也可能改名。唯一能沉淀下来、换模型也不作废的，是”什么样的输入算合格”和”什么样的失败对应什么根因”。这两样东西才是资产。
项目做完之后我做了一件事，后来每个试穿项目都受益：把这次跑下来验证有效的部分，变成资产。具体是三种东西。
资产一：一套虚拟试穿预处理脚本
把短边统一到 1024、把服装图背景刷白、把两张图并排拼一张预览图，这三步全部写成脚本，一条命令跑完一整批。脚本本身不复杂，几十行就够，但它把”五条硬规矩”从”记得做”变成了”自动做”。人一忙就会漏步骤，脚本不会。
资产二：一份虚拟试穿参数档案
这个品类用哪组参数、哪个 keep_pose、哪个 edge_blend，全部记下来，按品类归档。下次遇到同类需求，直接从档案里取，比从零试快得多。档案里最重要的是备注列：这张图当时为什么把 garment_fit 调到 0.9，这个信息比参数本身更有价值。
资产三：一组虚拟试穿失败样本
失败样本的整理方式，我建议一个文件夹一个类别，文件夹名直接写”症状 + 根因”，比如 袖口溢色_服装图背景不纯。里面的图片按”输入原图 / 参数截图 / 输出结果”三张一组。新人遇到类似现象，翻一遍就知道该怎么办，不需要再找老人问。
这个很多人不做，但我觉得最有用。把每一类失败都留一张最典型的样本，标注它的成因和修法，团队里谁遇到类似问题，对照样本一看就知道怎么办。失败样本的价值在于它节省的是”重新分析”的时间，而重新分析往往是最贵的环节。
三样东西加起来，一个团队的试穿能力就能从”靠某个人的手感”变成”靠流程”。这也是我在文章开头说的——真正让流程从能出图变成能交付的，不是模型，是这些沉淀下来的东西。
写给第一次跑虚拟试穿的人：四步走完
先给一个最小路线：找一张正面站姿、短边 1024 左右的人物图，一张白底平铺、褶皱清楚可见的服装图；装好节点，按连接清单接四个节点，Fast mode 开着、keep_pose 先开，跑一张确认”人还是那个人、衣服换了”；再固定 seed 把开关关掉跑一张，两张并排看。
这两张图看完，你对虚拟试穿的理解就会超过读十篇教程。因为这件事说到底拼的是手感，而开关的两个状态必须亲眼看。
虚拟试穿这件事，最后一句话
它把一个需要摄影棚、模特、灯光、后期的工作，压缩成两张图和一次点击；但它也最诚实——素材准备得有多认真，结果就有多认真。模型从不骗人，它只是把输入里的每个决定，忠实地放大。
常见问题
最后再补一组常被追问的问题，按”选方案、搭流程、修问题”三个层次排。README 里没有、但实操一定会撞上的那些，基本都在这。
ComfyUI 里有没有现成的虚拟试穿工作流可以直接用？
有，而且不少。它们的基本结构都是两个 LoadImage 加一个核心节点加 SaveImage，区别只在核心节点的实现和模型版本。我建议直接拿一个能跑的当起点，先把两张图换成自己的素材跑通，再去改参数，而不是从空白画布自己搭——试穿的复杂度主要在素材，不在连线。
下载现成工作流时要注意一件事：确认它用的核心节点和你装的版本一致。同名节点不同版本的输入口名字可能不一样（比如 image_person 和 person_image），直接导入会报”缺少输入”。遇到这种情况，删掉核心节点重拖一个，手动连回去，比找旧版本快。
为什么虚拟试穿的结果十次里有三次不一样？
除了 seed，还有两个来源：输入图被改动（比如重新保存时压缩了一次）和环境变化（换了模型精度、驱动版本）。所以复现这件事要连输入文件一起锁住——把素材副本放在只读目录里，别让任何人顺手改色改尺寸。
九成是 seed 没固定。ComfyUI 默认每次生成随机 seed，同一组输入、同一组参数，seed 一变结果就变。虚拟试穿尤其明显，因为姿态对齐里有一点随机性，seed 不同可能导致袖口差半个手指宽。批量阶段一定把 seed 写死，要复现某张满意的图，就把它的 seed 抄下来。
原图是坐姿或蹲姿，能跑虚拟试穿吗？
能跑，但成功率明显低于站姿。坐下时腿部折叠、躯干前倾，服装区域检测的范围会变窄，长款衣服几乎必然要关 keep_pose 让模型重排。我的建议是坐姿图优先只跑上装，下装单独找站姿图处理；如果一定要全身坐姿，短边至少给到 1280，并且对结果的心理预期要打七折。
如果我想在 ComfyUI 里既用本地节点又用 Bria 云端，怎么组织？
我的组织方式是一个文件夹三层：raw/ 存原始素材、local/ 存本地节点的输出、cloud/ 存云端回传。所有文件名共用同一套命名规则，本地和云端各跑一遍之后并排看。云端节点如果只是封装了 API，本质还是把两张图传出去，所以隐私要求高的素材就不要进 cloud/ 这条线。
换衣后肤色或脸部有轻微变化，是正常的吗？
虚拟试穿的默认行为是保留面部、头发、身体结构，但边缘混合处难免有一点点变化，尤其是在颈部、手臂与衣服交界的地方。轻微变化靠提高输入分辨率能压下去；如果脸型明显变了，通常是 keep_pose 关了之后模型重排姿态导致的，开回去就好。脸变形的程度，是你判断”这次结果能不能用”最快的信号。
虚拟试穿时人物图和服装图尺寸不一样会怎样？
很多人会想”那把人物图直接缩小到跟服装图一样大不就行了”。可以，但缩小的那一侧会损失细节，尤其是脸和手指这些高细节区域。更稳的做法是把小的那张放大到接近大的那张，再统一到 1024。放大带来的轻微模糊，比缩小带来的细节丢失更容易被模型处理。
特别提醒：两张图比例差异大时，最容易出问题的是肩宽和腰线，因为这两个是服装版型的锚点，一旦比例被拉偏，整件衣服就跟着偏。所以裁切之前先看一眼肩腰比例，比事后调参数有用得多。
模型会做一次二次拉伸去对齐比例，结果是衣服整体变形——长袖变七分袖、裙长缩短，而且边缘混合处会出现”重影”。建议短边都落在 768-1536px 之间，两张图尺寸比尽量控制在 1:1 以内。实在不行就裁成接近比例，宁可在人物图里多裁一点，也别让模型去补。
keep_pose 打开和关闭，到底差在哪？
如果你只想快速判断，用这一句话：感觉”衣服不像衣服”就关，感觉”人不像原来的人”就开。这两个体感分别对应我前面说的两种代价，比分析服装品类更快，尤其在批量筛选时。
打开时锁定原姿势，只换衣服，适合做前后对比和贴身品类；关闭时允许模型重排姿态来适配服装，衣服版型和褶皱更自然，适合宽松外套、长裙和原姿势有遮挡的情况。我的判断标准很简单：这件衣服需不需要身体给它留空间，需要就关。
ComfyUI 跑虚拟试穿要多少显存？
另外补一句容易被忽略的：虚拟试穿同时加载两个 LoadImage，峰值显存会比单图流程高一点，因为两张图都要常驻。8GB 跑 SDXL 时如果反复 OOM，先把输出尺寸从 1536 降到 1280，通常立刻就好。
SDXL 8GB 跑得很舒服；FLUX 量化版 8GB 能跑但很紧，1536 分辨率容易爆，12GB 才算舒适。虚拟试穿要多加载一路图像编码，实际占用比同分辨率文生图高 1-2GB，选模型时多留一档余量。
袖口那一圈彩色细线怎么消掉？
顺便说一句，这个问题的严重程度和人物图的袖子形态强相关。直筒袖几乎不溢色，落肩袖和蝙蝠袖最容易溢——因为它们的边缘本身就没有清晰的轮廓线，模型无从判断”衣服到此为止”。所以做落肩款的时候，我会把这一项检查放在最前面。
如果三招用完还有，说明问题不在边缘混合，而在服装区域检测——检测框把袖口外的一圈背景也算进去了。这时候换一张袖子与背景对比更强的人物图，往往一步解决。
这是边缘过渡区采到了背景或旧衣服的颜色。先把服装图背景处理成纯白，再把 edge_blend 从 0.65 降到 0.45，最后由低到高试分辨率，一般到 1280 短边就看不见了。三招一起用，比单独调参更稳。
Fast mode 开了以后画面糊成一团，还能加大 CFG 吗？
顺带说一句，关掉 Fast mode 之后 CFG 也不是越高越好。30 步模式下 CFG 一般给 5 到 7，超过 8 画面会变得”塑料感”——颜色过饱和、边缘过锐，衣服看起来像塑料做的。所以从 6 步切到 30 步时，CFG 要一起改，别只改步数。
不能。Fast mode 走的是 4 步 Lightning LoRA，实际配置是 6 步、CFG 1，这个组合是固定的。CFG 一旦拉高会直接出现噪点和色块。想要更清楚，正确做法是关掉 Fast mode 走 30 步，而不是加 CFG。
本地节点式和 Bria / Kling 云端方案，该选哪个？
还有一个维度值得考虑：后续迭代。今天选错方案，明天还能换；但如果一个团队的素材流程是按本地节点建立的（比如每一张都做了严格的预处理），换成云端几乎零成本。反过来，习惯了”随手丢两张图给云端”的团队，临时切本地会非常痛苦。所以如果对长期有打算，我建议先按本地节点的标准建素材规范。
再补一条实操建议：如果你对某个品类完全没有经验，先用云端跑 5 张，看看”这个品类穿好是什么样”，再回本地照着这个目标调。云端在这里的作用是标尺，不是替代品。
看三件事：数据能不能出门、数量在 100 张以上还是以下、要不要严格复现。数据敏感、数量大、需要固定 seed 做 A/B 的选本地；只有笔记本、要一眼贵的成片、客户当天要看的选云端。实际上我最常用的是混合：本地跑全量筛选，云端只处理上首页那几张。
虚拟试穿的输出分辨率，和输入是什么关系
输出分辨率基本等于你在参数里设的 width 和 height，和输入图没有直接绑定。但两者不能离得太远——输入短边 800、输出设 1536，等于让模型凭空补一半的细节，边缘一定糊。我的原则是输出短边不超过输入短边的 1.5 倍，超出就先把输入提上去。
暂无评论内容