AI 图片存储的关键是权限与生命周期

AI 生图应用把图片存进私有桶，离可靠上线还差几道关：缩略图能不能代替原图，撤回后的素材能否继续导出，清理任务凭什么认定一个文件可以删除？这些问题靠目录命名和签名链接解决不了。

原文给出的主张很明确：原图、缩略图、变体和导出文件，都要有可追溯的归属与状态；先把数据库记录、授权和状态流转管清楚，再谈吞吐与自动清理。它没有性能跑分，但给出了一套值得后端和全栈团队检查的存储设计方法。

图片归谁管，不能靠对象路径回答

作者建议，每张需要持久保存的图片，在用户可见之前都应建立数据库记录。最低限度包括租户 ID、素材 ID、对象键、内容类型、字节数、尺寸、生成状态、校验和与保留类别。提示词、模型、目录状态和创建者，则作为可搜索的元数据保存。

这份记录就是素材台账（asset ledger）：系统用它回答「图片属于谁、处于什么状态、为什么还留着」。对象存储负责保存字节，数据库负责解释字节。

对象键是地址，不是权限。

即使原图、缩略图、变体、导出文件共用一个私有桶，也要区分对象类别。缩略图通常可以重新生成，原图可能是下一次模型运行的唯一输入，工作文件则属于某次任务尝试。它们的恢复价值与删除条件不同，不能套用同一条到期规则。

状态也必须明确。原文列举了 uploaded、generated、approved、withdrawn、exporting、complete、expired，但没有给出完整的状态转换表。团队需要自己定义哪些转换合法，而不是让生命周期规则根据文件年龄猜测业务含义。

浏览器拿到签名 URL 之前，应用应检查租户成员关系、素材可见性和链接有效期策略。链接只能指向一个对象或一个已完成的导出文件，不能开放任意前缀。签名链接是授权检查之后的交付手段，不能替代授权模型。

迁移成功，不等于图片和归属都正确

迁移最容易产生一种错觉：复制接口返回成功，事情就结束了。

作者指出，更危险的情况是图片字节完整，数据库记录却关联了错误租户。另一个容易漏掉的窗口是缩略图在盘点后重新生成：迁移任务若读取可变的「latest」引用，新台账可能指向从未属于原素材状态的文件。

因此，迁移前应先运行只出报告的核对程序，对比素材台账与对象清单，统计文件缺失、无归属对象、类别错误、重复校验和，以及导出快照引用了已撤回素材等问题。每项候选操作还要说明租户、对象类别、年龄、可用的校验和、数据库引用、导出引用和执行理由。归属不明就是停止信号。

正确的写入顺序是：冻结源引用，按稳定素材 ID 复制，核验校验和与元数据，写入新台账引用，最后把旧对象标记为待清理。验证记录应包含源校验和、目标校验和与状态版本；记录存在后，应用才能切换读取位置。

下面这段 Go 代码展示调用方与存储适配器之间的边界，并对传入引用做最低限度的检查：

package main

import (
    "context"
    "fmt"
    "io"
)

type ObjectRef struct {
    TenantID string
    Key      string
}

type ObjectStore interface {
    Open(ctx context.Context, tenantID, key string) (io.ReadCloser, error)
    }

type ObjectWriter interface {
    Put(ctx context.Context, tenantID, key string, src io.Reader) error
}

func migrateObject(ctx context.Context, store ObjectStore, writer ObjectWriter, ref ObjectRef) error {
    if ref.TenantID == "" || ref.Key == "" {
        return fmt.Errorf("invalid object reference")
    }

    body, err := store.Open(ctx, ref.TenantID, ref.Key)
    if err != nil {
        return fmt.Errorf("open %s: %w", ref.Key, err)
    }
    defer body.Close()

    if err := writer.Put(ctx, ref.TenantID, ref.Key, body); err != nil {
        return fmt.Errorf("write %s: %w", ref.Key, err)
    }
    return nil
}

要看清 writer.Put 这一行的局限：示例只返回错误，并未实现校验和验证，也没有证明租户隔离。作者要求生产版本写入迁移专用目标，并返回经过验证的大小和校验和；适配器仍须验证每个引用，不能把调用方过滤当作隔离保障。

台账更新还必须幂等。同一个稳定素材 ID 重试，应收敛到同一目标，不能因为 worker 重启就多出一张用户可见的素材。

导出和清理，都要先证明状态成立

私有桶并不决定一个用户在 6 小时后是否仍有权查看图片。创建签名链接时，要记录申请者、选中的对象版本和过期时间；包含凭证或授权材料的完整 URL 不应进入日志。

导出需要独立记录，包括租户 ID、稳定导出 ID、快照边界、选中的字节内容、状态和过期时间。任务从快照选择原图或已批准变体，流式写入暂存对象。归档关闭成功、元数据落库之后，才发布最终文件。失败留下的半成品只能属于该任务，不能对用户开放。

大文件字节流应交给后台 worker 处理。

worker 要施加背压、限制并发读取，避免把完整原图放进内存。并发量需要结合出口带宽、平均对象大小、归档 CPU 开销和最大导出时长估算，还要为生图与普通读取预留资源。导出排队可以变慢，但不能拖垮交互式图片生成。

监控也不能只数请求。10 张缩略图和 10 张原始分辨率图片，负载差别很大。作者列出的导出 SLO 观察项包括队列年龄、首字节时间、完成延迟、读写字节数、重试次数、worker 内存和授权失败。具体延迟目标没有给出，因为还缺流量形态与客户承诺。

清理则应从完整观察周期的 dry-run 开始，先删除过期工作文件，观察删除数量与保留字节数，再逐类扩大范围。桶生命周期策略承担兜底职责，业务清理程序负责判断文件是否满足删除条件。

回滚能停止后续破坏、暂停相关生产任务、保留核对报告，并恢复迁移前的读取引用。它无法恢复已经永久删除的字节，所以恢复方案和还原测试必须提前设计。

我的判断

这篇最有价值的地方，是把存储可靠性落实到了可检查的记录与顺序。相比「按目录存文件，定时清旧文件」，素材台账能解释归属、导出来源与删除理由；对多租户且有撤回、审核、导出流程的应用，这些信息很有用。

但它是一份设计建议，不是效果验证报告。作者没有提供实测吞吐、故障率或迁移前后的对照数据，也没有展示完整授权实现。Go 示例只是接口骨架，不能直接当成生产迁移器。

签名链接还有一个边界需要补清：原文没有说明，素材撤回后如何处理已经签发的链接。禁止申请新链接，与让旧链接立即失效，是两件事；已经下载到用户本地的导出文件，也无法靠服务端状态撤回。

存储选型同样有前提。原文明确承认：文件足够小时，数据库存储可能更适合需要原子一致性的场景；如果要求不可变保留、跨区域恢复或特定合规控制，就要选择能提供这些保证的系统，或补上外部恢复与保留层。不能因为场景叫 healthtech，就认定私有桶已经满足所有要求。

能拿来做什么

• 给现有生图应用补一份素材台账，先检查租户、对象版本、状态和校验和能否串起来，再决定是否调整桶目录。
• 在 Node 导出服务中，把归档交给后台任务，通过流式读取和有界并发控制内存，并以稳定导出 ID 防止重试产生重复结果。
• 上线清理规则前，先生成可审查的候选删除报告；如果解释不了某个对象的归属或状态来源，就暂停该类别的删除。
• 用 AI 编程助手补测试时，明确要求覆盖跨租户读取、撤回后申请链接、重复导出 ID、原图缺失、缩略图替换、任务取消、对象超过 worker 内存预算，以及目标已存在时的迁移重试；断言要检查状态和校验和，不能只看 HTTP 成功。