一、真正麻烦的不是放大，而是六块图能否属于同一次结果

一张原图被分成六块送去做超分，回来的六个文件都有正确尺寸，并不代表可以直接拼接。最容易被忽略的是，单张图块看着锐利，紧挨着的两条边却可能出现亮度台阶；另一种情况更隐蔽：用户重开任务以后，旧任务的一块结果晚到了，大小和命名都正确，实际上已经不属于当前批次。

这篇围绕一个固定输入的工程模型讨论这两个边界。示例项目叫 TileSeamGate，任务 TSM-1011-33，样例清单为 gallery_tiles_06。它不执行真实超分，也没有在设备上调用Image Kit完成解码和拼图；这样收缩范围，是为了先把能独立说明的问题讲清楚：对什么数据作准入判断，在什么时刻作判断，以及未通过时应该保留什么证据。

演示原图为2400×1600像素，按三列两行分成六个800×800像素的源图块。假设后续使用的业务模型是2倍放大，每块规划输出1600×1600像素，整图目标4800×3200像素。这里的“规划”两个字不能省略。样例里没有真实模型推理产物，六个edgeDelta也是可重复的测试夹具值，并非手机扫描真实图像后测得的边缘色差。

我们先记住一个工程判断：完成一次文件生产和允许结果进入最终作品，是不同的两件事。前者关注有没有可用文件，后者关注文件是否同批、同尺寸、同坐标系以及相邻边缘是否满足业务门槛。两者混为一谈，才会把本来应该中止的半成品包装成成功结果。

二、把问题缩到一个可解释的样例上

这轮固定了六个图块，T01到T04的业务边缘差异值依次为6、8、10、5，全部处于阈值12以内。T05的差异值为17，因此标为SEAM_DELTA；T06的差异值为7，但其epoch是2，而当前有效批次是3，因此标为EPOCH_STALE。检查顺序先比批次，再比业务边缘差异。对已经过期的结果，不应该继续花时间做图像质量比较。

最终统计严格为六个候选、四个通过、两个阻断；两种阻断原因各一条。只要还有任意一个待处理图块，就不批准最终拼图，整体业务状态写成SEAM_HOLD。这里没有所谓“拼完六张再看效果”，也没有用空白填补失败图块。图块缺失与图块质量异常都要在组合动作之前暴露出来。

需要特别说明这个edgeDelta的语义：它表示应用自定义质量分析清单里，当前图块所涉接缝的最大边缘差异汇总值。它不是Image Kit内置的评价指标，更不是系统承诺的阈值。业务如果改成逐边存left/right/top/bottom四个差异值，门禁的结构可以沿用，但计算口径与样例数据必须一起升级，不能在旧报告上只改字段名。

有开发经验的读者大概会想到另一条路：每一对相邻图块直接测亮度均差，拼图的时候再做融合。这个方向没有问题，却是另一项工程任务。当前样例没有原始像素缓冲，也没有重叠区域的像素数据，因此既不能声称测出了真实接缝，更不能给出“融合以后肉眼不可见”的结论。我们只验证从已有证据到是否允许进入拼接的判定链。

三、Image Kit在哪个位置，业务规则又在哪个位置

华为Image Kit的PixelMap能够提供图像信息读取、裁剪、缩放等能力，官方《使用PixelMap完成图像变换》明确展示了getImageInfo()取size.width、size.height的方式。工程里若已经有真正的PixelMap结果，可以在业务门禁之前读取其尺寸，与1600×1600的约定做一次硬校验。这个尺寸检查是系统对象信息读取，不等于超分模型已经完成质量验收。

这里先解决“输入对象是否符合单块尺寸合同”的问题。代码只展示经官方资料能够核对的读取方式；PixelMap由调用者创建与持有，下面的方法既不申请模型资源，也不释放它。真实项目应该把异常、对象所有权和销毁顺序交给明确的资源协调器管理，避免一个页面误释放另一页面正在编码的PixelMap。

import { image } from '@kit.ImageKit';

export async function verifyTileSize(pixelMap: image.PixelMap): Promise<boolean> {
  const info: image.ImageInfo = await pixelMap.getImageInfo();
  return info.size.width === 1600 && info.size.height === 1600;
}

这个函数返回的true只表示尺寸相符。假如源图发生了裁剪、旋转或者EXIF方向处理，单靠宽高不能确定图块所处的原图位置。还要核对tileId、源图摘要、行列索引和任务代次。异常时也不能把读取失败解释成“边缘质量不好”：getImageInfo()失败应走单独的技术错误通道，不能与SEAM_DELTA混为一类。否则线上排障时，模型异常和资源生命周期问题会被统计成同一类。

我们的Node.js模型不依赖HarmonyOS运行环境，负责验证携带这些证据的应用清单；真正从PixelMap到清单的转换属于待接入端口。这样做牺牲了“从按钮点到真实算法”的完整演示，却换来可以逐条回放的业务规则，而且不会凭空发明Image Kit中不存在的detectSeam、superResolveTiles之类接口。

四、一次业务判定要把“过期”放在“质量”前面

如果图块在旧轮次完成，哪怕差异值只有1，也不应该混进新批次。因为同一个tileId有可能对应两次不同参数、不同放大模型甚至不同裁剪边界。检查时先做代次隔离，随后校验几何合同，最后才解释质量阈值。这比“只要尺寸对得上就写到缓存路径”更符合多任务队列的实际情况。

下面的TileEvidence不是官方SDK类型，是TileSeamGate自己定义的输入合同。函数不隐式更新共享状态，因此任何顺序调用都能复现同样的分类。业务阈值12来自本轮示例配置；生产环境必须通过带版本号的策略配置管理，不能直接把12当成设备规格。

export interface TileEvidence {
  id: string;
  epoch: number;
  edgeDelta: number;
  width: number;
  height: number;
}

export type TileDecision = 'PASS' | 'EPOCH_STALE' |
  'SEAM_DELTA' | 'SIZE_CONTRACT';

export function decideTile(row: TileEvidence, activeEpoch: number): TileDecision {
  if (row.epoch !== activeEpoch) return 'EPOCH_STALE';
  if (row.width !== 1600 || row.height !== 1600) return 'SIZE_CONTRACT';
  if (!Number.isFinite(row.edgeDelta) || row.edgeDelta > 12 || row.edgeDelta < 0) {
    return 'SEAM_DELTA';
  }
  return 'PASS';
}

这段代码做了一个有意的取舍：EPOCH_STALE比尺寸错误优先。如果旧回调同时携带损坏尺寸，最终分类仍然是旧轮次，不把它记成当前模型质量回归。反过来，当前轮次的坏尺寸绝不能用修改edgeDelta逃过门禁。边缘差异若是NaN或负数，同样拒绝；业务统计应保留原始证据，不能悄悄把非法值强行归零。

如果接入真实多线程生产，activeEpoch不能只在开始时读取一次。异步方法返回前以及真正把结果写进持久缓存之前，都要重新核对当前代次。否则函数内部判定通过以后，用户已经切换任务，最终提交动作仍可能把旧结果写进新路径。当前离线模型没有异步模型调用，所以不声称验证过跨线程竞态，只把实际集成时需要的第二道门槛写在设计里。

上图是按固定输入制作的DevEco Studio白色主题示意图，不是真实编译截图。左侧目录和中间示例代码展示业务门禁分层，右侧模拟器与底部HiLog展示预定的夹具结果。它不能充当系统PixelMap已经解码、超分推理成功或GPU纹理已经拼接的证据，页面里NOT_RUN必须保留。

五、为什么要区分“图块通过”和“整图可发布”

把通过图块收集起来以后，还需要一个全局提交点。这里有一个容易犯的错误：每完成一块就改全局resultReady=true，最后只要列表非空就允许“导出整图”。这种状态很难解释六块里究竟有几块属于同一版本，更无法回答用户点停止时哪些块已经完成确认。

我会把过程拆成候选收集、逐块分类、全局决议三个阶段。每块返回一个不可变判定结果；汇总时按固定顺序排序，同时保留id和原因。只有六个记录完整且全部PASS，才能生成下一步的拼接任务。当前四通过两阻断，所以只能生成诊断清单，不能创建拼图生产令牌。

下面的汇总代码不会实际调用图像拼接器。planMosaic只计算是否具备提交资格，避免读者误把它理解成具有像素混合能力的系统接口。项目里将来可在allowMosaic为真且二次检查epoch仍一致时，才交给真正的后台Worker或TaskPool处理。

export function planMosaic(rows: TileEvidence[], epoch: number) {
  const decisions = rows.map((item) => ({
    id: item.id, decision: decideTile(item, epoch)
  }));
  const passed = decisions.filter((item) => item.decision === 'PASS').length;
  const blocked = rows.length - passed;
  const expected = ['T01','T02','T03','T04','T05','T06'];
  const ids = new Set(rows.map((item) => item.id));
  const complete = rows.length === 6 && ids.size === 6 &&
    expected.every((id) => ids.has(id));
  const allowMosaic = complete && blocked === 0;
  return {
    total: rows.length, passed, blocked,
    allowMosaic,
    state: allowMosaic ? 'MOSAIC_READY' : 'SEAM_HOLD',
    decisions
  };
}

allowMosaic=false并不意味着四张通过图块被销毁。调试报告应保留它们的只读元数据，方便与失败样本对照；但展示界面不能把局部合格换算成整图已完成百分比，更不应该创建一个看似正常的4800×3200成品文件。清理策略可以分层：释放不再使用的PixelMap和临时解码缓冲，保留轻量判定记录与任务摘要；至于保留临时图片字节多久，应由隐私、磁盘预算和重试策略共同决定。

要注意提交与释放也可能乱序。假设T05已经被判定异常，紧接着页面退出，后台清理将内存图块释放，而日志写入又发生在清理之后。如果日志对象里持有已释放的像素句柄，就容易引起悬空引用。报告最好只持有id、宽高、差异值、代次与摘要，不直接持有可变或需要释放的图像对象。

六、六个固定样例到底说明了什么

样例表里，T01到T04依次为6、8、10、5，门槛统一12，因此均返回PASS。T05返回SEAM_DELTA，因为17已经高于12。T06返回EPOCH_STALE，因为它来自epoch2，而当前epoch是3；即使它的差异值7小于门槛，也不能推进新轮次的任何结果。最终passed=4、blocked=2，既没有第七个隐藏样例，也没有把一次失败拆成两次统计。

下图的主界面同时放了六个图块预览和一张统计卡。为了避免把图像模型的输出误认成真实照片，这些山湖缩略图是界面插画；图中标明的800×800源图块和1600×1600规划输出仅是几何合同，真正的图像仍未解码、更未放大。尤其不能从漂亮的缩略图推断模型已修复接缝。

图中的蓝色按钮是“查看接缝诊断”，并非“开始正式拼接”。这一点属于产品语义：只有当六块均通过并且用户明确选择生产，才应该进入真实像素拼图阶段。即便此时可见四个绿色PASS，顶部也保持SEAM_HOLD，因为系统展示的是整个任务的业务安全状态，而不是平均得分。

如果以后增加自适应阈值，会面临一个新的审计问题：同一组边缘差异，在策略v1和v2下可能得到不同分类。因此报告至少要保存策略版本、阈值、输入摘要、拼图规划尺寸和当前代次。否则一周后只看到SEAM_DELTA，已经无法确认当时为何阻断，也不能用新的阈值去解释旧报告。

七、调试要从阻断原因反推输入，而不是盯着红字猜

诊断页把时间线设计成07:41:11 LOAD、07:41:12 CHECK、07:41:13 BLOCK T05、07:41:14 BLOCK T06、07:41:15 FINISH。这些时间是预设夹具时钟，不是采集真实设备日志的时间。这样的展示目的，是教会团队把“读取候选”“业务验收”“发布决议”拆成可辨别阶段，而非把每个错误都写成一个模糊的失败消息。

对于T05，首先问它的差异值17是如何得到的、边缘分析口径是否发生改变、邻接图块和色彩空间是否一致。如果真实像素分析器的输入颜色格式不同，差异指标即使看起来稳定也没有跨版本可比性。对于T06，则应优先查任务代次、回调产生时的请求ID、取消与重启动作的顺序，而不是讨论图像锐度。

诊断页用红色突出T05，同时保留T06的旧轮次值。若将来拿到真实输入，建议加两类证据：一类是邻边原始像素统计和处理参数，另一类是与生命周期有关的请求发出时间、回调确认时间、任务代次与主动取消时间。前者用于解释画质，后者用于解释“为什么不允许这块画质正常的图进入当前任务”。

任何“人工强行通过”的操作也要进入审计链。它至少需要记录操作人、原因、策略快照与所承担的风险，并且不能倒写原始门禁结果。今天的目标不是设计人工审批功能，而是提醒：一旦加入例外路径，就必须防止数据层的历史证据被UI状态覆盖。

八、重试不能简单等于再跑一遍全部六块

被拒绝的T05适合进入质量复算或重新推理候选队列；过期的T06却应先丢弃，只有当前epoch下的新任务才有资格重新提交。同样显示为红色的两行，在恢复策略上并不相同。如果一律点“重试全部”，会白白浪费四块已经完成质量验收的中间结果，还可能让旧回调再次混入。

实际产品里我更倾向给重试计划加一个独立attemptId。每一次尝试引用不可变的源图摘要和模型参数，而成功候选不直接绑定“当前显示页面”。新attempt开始时，先决定哪些数据能够安全复用；只允许明确声明与新任务相容的缓存进入待审查队列，然后仍要重新过尺寸、代次和阈值门禁。如此一来，缓存命中不等于直接成功，减少了速度优化对正确性的侵蚀。

对于资源清理，PixelMap与ImageSource的实际所有权要成对记录；跨异步队列传递对象时，在销毁前应确认没有未完成编码或上传持有它。应用在后台、窗口关闭或任务被取消时，必须撤销本任务的提交资格，并安排已启动操作安全收口。仅靠把页面@State清零，并不能保证后台回调不会继续执行。我们这次仅提供业务合同，没有伪造这些系统资源的释放结果。

还有一种常被遗漏的失败路径是图块边缘的方向标记。纵向接缝通常比较左右边，横向接缝通常比较上下边，如果生产者把原始坐标和纹理坐标混用，拿错相邻边也能得到一个看似正常的差异值。当前夹具没有提供逐边坐标，故意不模拟这个计算。真正接入像素分析器后，证据结构应补上邻块ID、接缝方向、采样带宽与是否做过颜色空间转换。统计报告既要能回答“差异是多少”，也要能回答“这道差异究竟比的是哪两条边”。否则阈值调得再细，也只是把错误的测量精确化。

放到验收流程中，还需要一个明确的人工查看入口：业务可以展示局部通过图块和失败原因，但“下载可发布整图”必须是独立的受门禁保护的动作。错误提示应告诉开发者应重测T05还是重新生产T06，不能只是给出两个相同的红色感叹号。质量指标负责判断，产品文案负责解释，彼此不能代替。

九、与早期超分文章的技术边界

此前围绕超分结果已讨论过局部锐度、振铃拒绝、编码中PixelMap租约、ROI选区反算等问题。这一篇不再解决“单张结果是否清晰”、也不关心“选区该裁哪一块”。它关注的是多个独立图块已经分别返回以后，整图拼接前是否拥有一致、可追溯的证据集合，特别是接缝质量和过期图块不能悄悄越过全局提交点。

它与3DGS导出文件的半写摘要校验也不是同一问题：导出半写针对文件字节完整性和摘要一致性，本例检查拼图任务的结果代次与预设接缝指标。即使未来都使用Node.js做业务回放，输入结构、失败语义、决策目标以及资源收口都不一样。这里的差别应该体现在代码与诊断上，而不是仅仅把Demo重新起名。

继续深入最值得做的，是拿真实像素建立逐边重叠带的颜色差异统计，并把不同倍率、不同色彩空间、不同模型版本的阈值一起纳入协议。届时可能还要讨论搭接带融合、纹理接缝、色彩线性化及GPU内存峰值，这些都不能用当前六条夹具替代。我们不把未做的功能写成已做，更不会声称通过真机验收。

十、结论是“暂停组合”，不是“业务失败”

固定规则回放可以得出明确的业务判断：TSM-1011-33在gallery_tiles_06上六检四过两阻断，阈值12，当前epoch3，整体SEAM_HOLD。源图2400×1600、三列两行、两倍输出与4800×3200的拼接规划是一组自洽的设计参数，并不是实际生成的成品证明。

真正的系统验证仍有明确的缺口：尚未运行DevEco Studio编译，未创建真实PixelMap，也未执行超分模型、真实接缝测量、GPU拼图或图像编码。后续可以把这里的模型门禁接到真实数据处理管线上，但要保持“数据生产端”和“发布决议端”职责清晰。只有这样，六张都叫成功的图片，才不会拼成一张不应被交付的作品。

官方参考：华为《使用PixelMap完成图像变换》（2026-09-09）：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/image-transformation ；华为《使用Image_NativeModule完成位图操作》（2026-07-28）：https://developer.huawei.com/consumer/cn/doc/HarmonyOS-Guides/pixelmap-c 。