永远不会死掉的 CDN 链接

最尴尬的隐私故障有时并不是被入侵。而是一个 URL。

用户从你的应用中删除了一张图片。仪表盘不再显示它。数据库记录被移除了，或被标记为已删除，或戴上你 ORM 偏好的那种小墓碑标记。大家开心了大约四秒。

然后有人打开旧的 CDN 链接，图片仍然加载。

这是因为“产品删除”和“资源删除”是不同的工作。UI 可以把对象从用户的视野中移除，但存储桶、CDN 边缘缓存、缩略图服务、队列重试文件夹，或备份路径里可能仍然保留着副本。从用户的角度，删除意味着“不要再有它了”。从系统的角度，删除意味着“不要再渲染正常页面了”。

AI 图片产品尤其容易中招，因为生成的输出往往会以文件形式提供。它们可能为了性能而被缓存。它们可能有缩略图。它们可能存放在可预测或长期存在的路径下。它们可能还会被复制到审核、分析或支持工具中。一个直连链接可能会像一份被诅咒的小纪念品一样，比界面更长寿。

修复从措辞开始。不要承诺“删除”，但承诺只覆盖应用视图。要先说清楚实际会发生什么，然后让实现跟上承诺。如果删除会使 CDN 缓存失效、删除源文件、移除衍生物，并使带签名的 URL 过期，那就很好。如果备份会在固定期限内保留数据，也要明确说明。

从技术上更安全的路径是：避免为私有输出提供公开且永久的 URL。使用短时效的签名 URL。让对象键不可猜测。跟踪衍生物。构建删除路径时要覆盖源、输出、缩略图、缓存以及队列残留。并像用户那样测试删除：在删除之前先复制 URL，删除图片，然后再尝试访问该 URL。

这不是很“酷”的工程。没有人会把“缓存失效实际上会尊重隐私承诺”写到发布横幅上，尽管说实话，我会尊重这种自信。但这些才是信任的组成部分。

当用户删除一张 AI 生成的图片时，产品不应该让他们去和基础设施的残留物玩“躲猫猫”。链接应该随着承诺一起消亡。

延伸阅读：为什么“删除我的上传”需要可验证，为什么没有托管画廊不是产品功能，以及 Unexposed 数据存储。