Gemini Developer API 怎么做零数据留存：Interactions、File API 与缓存边界核对

团队打算把 Gemini Developer API 接入内部文档问答场景时，最容易忽略的从来不是API Key配置，而是发完请求之后相关数据到底会存在哪里。把 store=false 加到单次 Interactions 请求里，只能处理这一类交互记录；后续上传到 File API 的PDF文件、显式上下文缓存、还有Live API的会话续接能力，各自都有独立的数据保留规则。

先把“零数据留存”覆盖的四类资源拆清楚

Google官方的ZDR说明文档里，把经常被大家混为一谈的几个状态做了拆分：Interactions 的对话记录、File API 的上传文件、显式上下文缓存，以及 Live API 的会话恢复句柄。这四类资源的删除入口不一样，默认保留时长也完全不同。

Interactions 请求先关掉服务器端的状态存储

如果你的服务只需要单次请求对应单次响应，完全可以直接把 store 设为 false。这么做的代价就是没法靠 previous_interaction_id 自动续接历史对话；需要做多轮对话场景的时候，得在客户端侧自行判断要不要保留、脱敏、重建上下文内容。

from google import genai

client = genai.Client()
response = client.interactions.create(
    model="gemini-3.5-flash",
    input="从这段公开资料中提取三个关键词",
    store=False,
)
print(response.output_text)

这里需要校验的不是接口返回的文本内容，而是整个请求体和后续链路：业务日志里不要落完整的输入内容，错误追踪系统不要自动采集返回的响应内容，代理层也别把原始请求body直接写入调试存储文件。store=false 这个配置只约束 Gemini 侧的 Interaction 存储逻辑，不会自动替你修改业务应用自身的日志采集策略。

File API：上传文件必须做删除闭环

做大文档问答场景的时候，一般都会先调用 File API 上传PDF或者纯文本文件。上传成功之后，接口返回的文件资源名应该直接归入一次性任务的清理清单里。不管任务执行成功、失败还是超时，都要触发删除逻辑；如果打算依赖平台自带的过期机制，也应该把过期时间和异常补偿逻辑同步写进任务记录里。

uploaded = client.files.upload(file="handbook.pdf")
try:
    result = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=[uploaded, "只回答文档中的部署要求"]
    )
finally:
    client.files.delete(name=uploaded.name)

文件删除失败的异常不能直接吞掉。生产环境至少要记录对应的资源名、删除接口返回结果和重试次数，但绝对不要把PDF内容或者用户的原始问题一并写入日志。如果业务规则要求必须留存这份文件，要单独把它从“零数据留存”的范围里标注出来，不能默认还按照一次性任务的规则处理。

显式缓存和隐式缓存是两套完全不同的机制

Interactions API 支持的是隐式缓存：平台会根据相似请求前缀和内部模型规则自动处理缓存命中，应用侧不需要创建一个可以单独管理的 cached content 对象。如果需要明确指定TTL时长、重复复用同一份长文档、并且支持主动销毁的话，要改用 generateContent 对应的显式上下文缓存接口。

实际开发里可以按照需求直接选型：

• 单次处理、内容敏感的短请求：Interactions 配合 store=false 配置，应用侧本身也不留存原始文本。
• 需要重复读取同一份大文档的场景：改用显式缓存，但是必须给缓存设置明确的过期时间，并且保留主动删除的逻辑。
• 需要保留多轮对话状态但是不允许持久化：客户端侧自行维护经过最小化脱敏处理的历史内容，不要把原始文件直接塞进每一轮请求的日志里。

Live API 要单独校验会话恢复相关配置

实时音视频场景下的 SessionResumptionConfig 走的是完全独立的链路。它的作用是支持断线重连和会话恢复，保存的是 Live API 专属的会话上下文，不能因为普通 Interactions 请求配置了 store=false 就想当然认为实时会话也没有留存状态。

如果产品本身不需要断线续接对话的能力，最简单的方案就是不要启用会话恢复配置；如果确实需要续接能力，就要把会话句柄的生命周期、失效时间和用户侧的删除入口都同步写进服务协议里，并且在会话结束之后及时清理本地保存的句柄内容。别把恢复句柄当成普通的短期 access token，它本身就是定位会话状态的核心线索。

上线前可以用一张验收清单核对

可以用下面四个问题作为发布前的门禁校验项：

1. Interactions 请求是不是都显式写明了 store=false 配置，而不是依赖SDK自带的默认值？
2. 每个通过 File API 上传的资源，是不是都配置了成功、失败、超时三条删除路径？
3. 当前项目里有没有混用显式缓存，如果混用的话，缓存名称和过期策略是不是支持可审计？
4. Live API 是不是真的需要开启 SessionResumptionConfig，不需要的场景下是不是已经完全关闭了这个配置？

最后还要再核对一遍业务自身的链路：反向代理、请求日志、异常监控平台、任务队列和备份系统都有可能自动复制原始请求内容。云端的各类资源清理完成，只能证明Gemini平台侧的对应数据已经处理，不能直接证明业务系统这边没有留下相关副本。

常见问题

只设置 store=false，还需要手动删除 File API 上传的文件吗？

需要。Interactions 状态和 File API 文件属于独立的两类资源，上传的文件仍然要按照任务的生命周期主动删除，或者配置明确的过期策略。

通过 Interactions 能不能直接创建显式缓存对象？

不能把两者当成同一个接口使用。Interactions 只支持隐式缓存；需要使用可单独管控的显式缓存对象的时候，应该调用 generateContent 对应的缓存能力。

配置了 store=false 之后会自动清理业务应用自己的日志吗？

不会。这个配置只会影响 Gemini 侧 Interaction 的服务器端存储逻辑，网关、业务日志、链路追踪和备份系统里的相关内容，仍然需要单独做脱敏或者禁止采集的配置。

实时对话场景必须开启会话恢复功能吗？

不必须。只有明确需要断线之后还能续接上下文的场景才需要启用；不需要续接的场景下，关闭 SessionResumptionConfig 可以直接缩小需要管控的状态范围。

结语

实现零数据留存的核心不是找一个统一的“总开关”，而是把 Interaction、上传文件、缓存和实时会话这四类资源逐项列出来，再给每一类资源分别指定关闭、过期或者主动删除的对应动作。全部处理完之后，相关配置才是真正可测试、可复查的。