Flux Art图片正常，名字异常，先不要重新生成
下载完成后图片能够打开，但中文文件名变成乱码，或两个不同响应给出同一个名称，先检查下载命名环节，不要立刻重新生成图片。Flux Art 是多模型 AI 视觉创作与生产平台；本文处理通用 HTTP 下载接收流程，不声明平台一定返回某种响应头。成图内容、远端建议名和本地资产身份是三件事，名字不好看不等于图片数据已经损坏。
把三个名字放到同一份记录中
保存去敏响应标识、解析得到的建议名、业务资产标识和实际保存名，必要的原响应头放在受控诊断记录中。任务与输出序号的对应关系应来自已有业务台账，不靠建议名猜测 SKU 或客户项目。若两个结果名称一样，先确认它们是不是不同资产；不能因为名字重复就覆盖前一个文件，也不能仅凭名称不同认定它们一定是不同内容。
响应头提供建议，不决定写入路径
Content-Disposition 可以携带 filename 或 filename* 参数，但 RFC 6266 明确把名称视为建议。接收程序仍负责选择被授权的保存位置和合适的本地名称。下表把协议解析、资产关联和实际保存拆开，避免一个字符串从网络直接变成文件系统路径。没有这个响应头也不自动代表下载失败，仍可在验证产物后按内部资产规则保存。
| 检查对象 | 建议保留 | 不能直接推断 |
|---|---|---|
| 响应标识 | 去敏请求或任务关联 | 名字相同不等于同一任务 |
| 原始命名信息 | 受控响应头与解析状态 | 不能直接作为写入路径 |
| 解析后的建议名 | 采用或忽略的原因 | 不是业务资产主键 |
| 资产标识 | 任务、输出与版本映射 | 不靠文件名猜SKU |
| 实际保存名 | 批准目录与已验证格式 | 后缀不证明内容类型 |
| 异常记录 | 冲突、损坏或未知行为 | 不自动覆盖既有文件 |
中文名先检查扩展参数的编码
filename* 使用扩展参数表示法，可以携带字符编码、可选语言及编码后的值；语言可空，字符编码信息不能直接省略。两种参数有效且同时存在时，应按规范优先采用扩展形式，而不是随意选先出现的一项。不要把普通 filename 的百分号文本反复当作 URL 解码，也不要将 HTTP 响应头的规则直接搬到 multipart 上传字段；它们的使用范围不同。
不要用分号和等号简单拆字符串
参数值可能采用带引号的形式，因此遇到分号就切开、遇到等号就取后一段的手写方法容易误判。应使用适合该协议的成熟解析器，并为无效输入制定明确政策。重复同名参数会使该字段无效；编码损坏时可忽略建议名或转入人工核对，但不要猜一个“看起来像中文”的值后覆盖已有资产。解析异常属于命名信息问题，是否继续保存仍要结合内容验证和本地存储政策判断。
一个假设重名场景说明资产名的作用
假设两个不同任务都建议保存为 image.png，而业务上它们属于不同商品的不同输出。这个假设不是真实服务响应测试。建议名可以作为展示信息保留，本地则用受控资产标识和已验证格式确定保存名，并记录映射。这样即使远端名字缺失或重复，也不会丢掉任务对应关系。显示名称需要修改时，可以更新展示字段，不必同时重写资产身份或把文件挪到陌生路径。
路径和后缀还要服从本地存储规则
不能信任远端名称中的目录部分，也不能靠声明后缀判断内容类型。实际写入应限定在批准目录，防止同名覆盖，并处理文件系统中的特殊名称、链接等风险；仅取 basename 并不等于完整安全实现。建议名中的格式与实际产物不一致时，记录异常并按内容验证结果处理，不通过改后缀把未验证数据变成合格图片。本文不提供自动执行下载文件或批量移动真实素材的指令。
用小型测试矩阵检查自己的接收器
在隔离测试环境准备普通英文名、有效扩展中文名、缺少头、引号内分号、重复参数、损坏编码、目录分隔符以及两响应同名等情况。逐项记录解析结果、是否采用建议名和最终保存位置，确认拒绝或降级分支没有覆盖其他文件。这里给出的是待执行的测试清单，没有声称某个完整解析器已经通过。未验证的客户端或系统行为标未知，不把浏览器一次另存为结果外推到全部脚本。
依据与素材入库分工
HTTP 建议名规则参考 https://www.rfc-editor.org/rfc/rfc6266.html ，扩展参数编码参考 https://www.rfc-editor.org/rfc/rfc8187.html 。本文聚焦单个响应的命名信息，不替代图片解码、下载完整性或归档权限检查。平台入口为 https://flux-art.net/zh ；视觉制作与自建下载接收器分别验收。对客户素材保留去敏任务关联，不在普通日志中输出下载签名、API 密钥或完整私有链接。