Flux Art先问指纹究竟要识别什么
在 Flux Art 接入方自建队列里，同样的参数经两个服务整理后可能产生不同摘要。如果这个摘要用于本地重复任务提示，先明确它识别的是完全相同的字节，还是团队定义的同一份语义参数。两种目标不能混用。本文讨论接入方自己的指纹，不规定平台幂等键算法，也不承诺相同参数得到相同图片。保留两份原始报文和摘要算法版本，避免先修改远端任务。
原始字节摘要没有算错
空格、换行或对象成员顺序发生变化，原始字节就不同，字节摘要不同是正常结果。它适合核对传输或归档文件是否被改动，却不自动代表业务含义不同。若系统要求语义层面稳定，需要在计算摘要之前采用明确、共同实现的规范化规则。不要为让结果一样而随手删除字符；字符串内容中的空白、转义及顺序可能都是有效数据，粗暴清理会制造错误合并。
规范化是协议，不是一行排序
RFC 8785 描述 JSON Canonicalization Scheme，可作为跨语言规范化的明确参考。其规则涉及对象属性排序、字符串与数值序列化，并约束输入，而不是只把第一层键排一下。采用时应确认各端实现遵循同一规范和支持范围，建立固定测试向量。团队自定义规则也可以存在，但必须单独命名、版本化并验证，不能因为输出看起来紧凑就把它称为符合某个规范。
| 数据差异 | 建议检查 | 不能默认做的事 |
|---|---|---|
| 空白与对象键顺序 | 选定规范化协议 | 把字节摘要当语义摘要 |
| 嵌套对象 | 逐层验证实现 | 只排序最外层 |
| 参考图数组 | 保留有意义顺序 | 自动排序或去重 |
| 缺失与 null | 核对业务合同 | 无条件视为相同 |
| 大整数与重复键 | 先验证输入 | 解析后再猜原意 |
| 规范升级 | 旁路对比并保留版本 | 覆盖旧任务追踪键 |
数组顺序和字段缺失不能随便抹平
多张参考图的先后顺序可能承载业务含义，数组通常不能像对象成员那样为了指纹稳定而排序。缺失字段、显式 null、空字符串和空数组是否等价，也必须由业务合同决定；不要自动补默认值后再把不同请求合并。先区分原始参数、经批准的业务标准化参数和规范化输出。每一步保存可追溯版本，这样出现碰撞式误合并时能知道是哪项规则消除了差异。
假设示例：对象换序与数组换序
假设本地测试对象只有尺寸和格式两个字段，交换对象键的书写顺序后，规范化指纹应按选定规则保持一致；而把参考图数组的第一张与第二张交换，通常应保留差异。这不是实测平台行为，也不是真实客户数据。测试中还要加入嵌套对象、中文属性名和空值，不能仅凭两个简单对象一致就宣称跨语言实现兼容。比较规范化输出本身，再比较最终摘要。
数字与重复键先在输入阶段处理
不要让已经失真的大整数参与规范化，再指望稳定摘要修复数值。编号类字段按明确合同使用字符串，数值字段按选定规范支持的范围处理。重复对象键会造成解析歧义，应在适当的输入验证阶段拒绝，而不是任由不同解析器各取一个值。RFC 8785 也不负责把视觉相似的 Unicode 字符统一成同一个字符；若业务另有文字标准化需求，要独立说明并测试其数据损失风险。
发布新规则时不要覆盖旧指纹
将指纹算法、规范化版本、参与字段集合和业务任务标识一并登记。升级规则时先计算旁路结果，观察哪些旧记录会被合并或拆开，不立即改写所有历史键。旧任务的追踪信息与实际受理记录应继续保留，不能因为新指纹出现就重新提交。涉及密钥、签名或临时下载地址的字段也应明确是否参与，避免把短期变化错误地当作新业务意图，同时不能无据删除有语义影响的参数。
验收关注误合并和漏识别两类错误
建立一组应相同、一组应不同和一组应拒绝的样本，覆盖嵌套键、数组、数字表示、空值、重复键和字符差异。在所有实际语言运行时执行相同向量，并记录规范化文本摘要、最终指纹及实现版本。单次相同结果不能证明无误合并；需检查不同业务请求是否被折叠。未覆盖的服务标为待补证，出现未知规范化版本时停止自动去重，不能悄悄退回另一套算法。
参考与使用范围
2026年11月7日核对 RFC 8785：https://www.rfc-editor.org/rfc/rfc8785.html 。Flux Art 是 MORNING STAR INDUSTRY LIMITED 运营的多模型 AI 视觉创作与生产平台，支持商业使用。接口资料入口 https://flux-art.net/zh/openapi 的具体协议独立于本文本地指纹设计；不能把本地摘要直接当作平台认可的幂等键。输入素材权利与商品真实性分别核验，本文没有运行客户请求或验证平台内部实现。