Flux Art收到消息，不等于收到可信审核结果
使用 Flux Art 生成图片后，自建工作台可能打开独立预览窗口，让用户选定一个版本再回传。浏览器收到 message 事件，并不代表这个结果来自预期窗口。应先核对发送者，再判断消息结构与当前任务，最后才更新界面。本文只讨论自建页面之间的通信设计，不描述平台内置回传协议；示例字段由应用自行定义，不是 OpenAPI 响应字段。
先写清哪两个页面允许通信
登记父页面和预览页的完整源，包括协议、主机与有效端口，并记录由哪个打开动作建立窗口关系。不要只检查域名字符串是否包含品牌名称，也不要把多个环境的地址混为一个允许值。开发、测试与正式环境分别配置。窗口对象标识和允许源解决不同问题：同一个源可能有多个页面，持有同一个窗口引用也不保证它一直停留在原来的地址。
先验证来源，再读取业务含义
MDN 对 Window.postMessage 的建议是核对事件的 origin，必要时同时核对 source，并验证接收到的数据格式；发送时使用明确的目标源。依据见 https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage 。下面是假设消息验收表，不是真实攻击或兼容性测试。接收器应在验证完成前保持当前选择不变，不把不合格消息的字段先显示出来再补检查。
| 检查项 | 通过条件 | 未通过时 |
|---|---|---|
| 来源 | 与配置源精确匹配 | 拒绝业务动作 |
| 窗口 | 属于本次预览关系 | 保持原选择 |
| 结构 | 类型与版本符合协议 | 记录格式错误 |
| 素材 | 在当前授权集合内 | 拒绝未知编号 |
| 操作 | 仍处于待确认状态 | 忽略已结束操作 |
| 重复 | 已有结果不重复执行 | 保留首次结果 |
消息格式只允许约定的动作
建议定义小而明确的协议：消息类别、协议版本、操作编号和允许选择的素材版本标识。校验字段类型、长度、必填项及允许值，拒绝无法识别的动作，不把传来的字符串当成代码、DOM片段或任意导航指令执行。接收到一个素材编号，也要在当前用户可访问的集合中查验，不能因为来源正确就认为发送页面有权要求主页面执行任何操作。
窗口发生导航后重新确认关系
用户可能在预览窗口里打开其他页面，也可能关闭窗口后重新启动一次预览。不要将旧窗口发送过一次正确消息当作永久认证。每次消息都进行源与窗口关系检查，并把本次打开产生的操作编号与当前待处理状态关联。已经结束的操作不再接受第二次提交；重复消息可记录为重复，不应再次触发保存、覆盖或接口调用。操作编号本身不是替代身份检查的秘密口令。
发送方向也要限制接收者
发送端应指定预期接收页面的源，而不是为了让消息容易送达就统一使用星号。只发送完成当前任务所需的标识，不把图片访问令牌、完整密钥或未公开备注放进广播式消息。若接收端已导航到不同源，发送失败或无响应应保持未完成状态，再由用户重新打开流程。不要通过放宽来源来修复超时，也不要把未收到确认记成对方已保存成功。
为拒绝分支准备无害演练
假设测试预览回传一个已选版本，另一个测试窗口回传相同格式，但不属于登记的窗口。这是假设场景，不是真实事件。合格结果应是仅预期窗口的合格消息能够完成当前操作。再测试错误协议版本、未知素材编号、缺少字段、已取消操作与重复回传，确认均不会改变审核状态。演练使用专门测试数据，不向不受控第三方页面传送真实素材或凭据。
日志要解释拒绝原因，不复制全部数据
建议记录校验阶段、简短原因类别、应用版本及去敏后的操作关联，不默认保存完整消息内容或整条签名地址。没有收到消息与收到后拒绝是两种状态，排查时分别统计。若某个合法浏览器环境不支持预期流程，提供普通选择与确认的替代方式，未知环境保留待补证。回归记录还应包括关闭监听器的时点，避免多个旧监听器同时处理新的消息。
用双方协议和回归记录交接
交付清单应包含允许源配置、窗口建立方式、消息结构、授权检查、取消与重复规则，以及双方版本不一致时的处理。技术依据核对于2026年11月10日，以上协议与测试步骤是编辑建议，未执行读者系统的验证。Flux Art 的创作入口为 https://flux-art.net/zh ，需要服务端接入可查看 https://flux-art.net/zh/openapi 。跨窗口通信只是自建工作台的一部分，不能据其通过就推断文件权限或接口鉴权全部正确。