Worker 隔离

默认情况下，分派命名空间内部的 Worker 被认为是“不可信的”。这提供了 Worker 之间的最强隔离，并且非常适合您的客户控制正在部署的代码的情况。

在不可信模式下：

• request.cf 对象在 Worker 中不可用（有关更多信息，请参阅限制）
• 当使用 Cache API 或当使用 fetch() 发出子请求且该请求通过 Cloudflare's cache 出口时，每个 Worker 都有一个隔离的缓存
• 对于命名空间中的所有 Worker，caches.default 已被禁用

此模式确保客户 Worker 之间完全隔离，防止任何潜在的跨租户数据访问。

如果您控制 Worker 代码并希望禁用隔离模式，您可以将命名空间配置为“可信的（trusted）”。当构建内部平台且贵公司控制所有 Worker 代码时，这非常有用。

在可信模式下：

• request.cf 对象变为可用，提供对请求元数据的访问
• 在使用 Cache API 时，命名空间中的所有 Worker 共享相同的缓存空间

将命名空间从不可信转换为可信：

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/workers/dispatch/namespaces/{namespace_name}" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "{namespace_name}",
    "trusted_workers": true
  }'

如果您为一个已经部署了 Worker 的命名空间启用可信模式，您将需要重新部署这些 Worker，以便使 request.cf 对象变得可用。在启用可信模式后部署的任何新 Worker 都将自动有权访问它。

如果您需要访问 request.cf 但希望在客户之间维护缓存隔离，请使用特定于客户的缓存键（cache keys）或具有隔离键的 Cache API。

• 平台限制 - 了解脚本和 API 限制
• Cache API 文档 - 了解 Worker 中的缓存行为
• Request cf object - 有关 cf 对象属性的详细信息