Vercel Flags跨项目共享新方案：无需SDK密钥

Vercel 近期为 Flags 功能引入了 Project Connections，允许同一团队下的不同项目直接读取其他项目定义的 feature flag，而无需手动复制和传递 SDK key。这一变化解决了一个长期存在的痛点：过去跨项目共享 flag 需要将 server SDK key 写入环境变量并人工维护，既繁琐又存在密钥扩散风险。

从密钥共享到身份认证

传统做法中，若项目 B 想使用项目 A 定义的 flag，开发者需要从 A 项目拿到 SDK key，配置到 B 项目的环境变量里。这种方式在团队规模扩大、项目数量增多后，密钥管理成本会迅速上升，一旦密钥泄露还可能波及其他项目。

Project Connections 将认证方式改为基于部署身份。连接后的项目使用其部署的 identity 进行鉴权，本地开发时则通过 vercel env pull 拉取项目的 OIDC token。据 Vercel 官方说明，这意味着不再需要手动管理密钥，访问权限也可以在不重新部署的情况下被撤销。

OIDC 与部署身份

OIDC（OpenID Connect）是构建在 OAuth 2.0 之上的身份认证协议，核心是让一方能够验证另一方签发的身份令牌（ID Token）的真实性。Vercel 的 Project Connections 正是借助这一机制：每次部署都会获得一个由平台签发、带有工作负载属性的身份，消费方项目在请求源项目 flag 时出示该身份而非静态密钥。与传统 API key 相比，OIDC token 通常具有较短的有效期并由平台自动轮换，因此即便泄露，攻击窗口也有限；同时令牌中携带的项目、团队、环境等声明，让源项目可以据此精确判断请求来源。本地开发环境没有部署身份，需要通过 vercel env pull 把项目关联的 OIDC token 同步到本地 .env 文件，从而在开发机上复现与线上一致的鉴权路径，避免开发者绕过权限模型私自使用长期密钥。

配置方式：控制台与CLI均可操作

团队可以在项目 Flags 区域的 Connections 页面查看连接关系：哪些项目有权限读取本项目的 flag，以及本项目从哪些项目读取 flag。页面提供了添加和移除连接的控制入口。

也可以在命令行中通过 vercel flags connections 管理连接。不过需要注意版本门槛：使用 Project Connections 要求 @flags-sdk/vercel 1.6.0 或更高版本，若直接使用核心库则需要 @vercel/flags-core 1.11.0 或更高版本；CLI 管理连接则要求 Vercel CLI 63.0.0 或更高版本。

在消费端项目中如何调用

连接建立后，消费方项目需要创建一个携带源项目 ID 的 adapter，然后用它来求值 flag。官方示例中，先通过 createVercelAdapter 传入源项目的 projectId，再在 flag 定义里指定该 adapter 即可。这样定义的 flag 在消费端项目中就像本地 flag 一样使用。

一个值得留意的设计细节是：连接授予的是跨所有环境的只读权限，而具体求值哪个环境的 flag，由消费方的部署环境决定——生产部署会求值生产环境的 flag。这种设计减少了配置项，但也意味着消费方需要理解自身部署环境与源项目环境之间的对应关系。

Adapter 与 flag 求值分离

在 Flags SDK 的抽象里，flag 的"定义"（名称、类型、默认值、求值逻辑）与"数据来源"是解耦的，adapter 就是连接两者的桥梁。createVercelAdapter 负责封装与 Vercel Flags 服务通信的细节——包括携带哪个源项目 ID、如何附上部署身份凭证、请求哪个环境的配置。把 adapter 注入到 flag 定义后，业务代码调用 flag 时无需感知它来自本地还是远端项目。这种模式的好处是，同一个 flag 定义可以在测试中替换为内存 adapter、在本地替换为静态 adapter、在生产中替换为跨项目 adapter，而不改动调用方代码。理解这一点，就能明白为什么连接建立后消费端仍必须显式创建 adapter：连接只是授权层面的许可，adapter 才是运行时实际发起求值请求的组件，两者缺一不可。

权限模型与限制

Connections 的权限边界比较清晰：只读，且覆盖所有环境。访问权可以被撤销，且撤销后无需重新部署消费方项目即可生效，这对安全事件响应来说是实用的特性。

从适用范围看，Project Connections 面向所有套餐开放，并非仅限企业版。这一点降低了中小团队使用跨项目 flag 共享的门槛。

只读权限与最小权限原则

只读（read-only）是 Project Connections 权限模型的核心约束，它体现了安全设计中的最小权限原则：消费方只需要"读取 flag 当前取值"这一种能力，就被严格限制在这一范围内，无法通过任何 API 修改源项目的 flag 定义、开启或关闭某个 flag、调整规则或删除 flag。这样做有两层考虑。其一是爆炸半径控制——如果某个消费方项目被入侵或出现 bug，攻击者也无法借道篡改上游 flag，进而影响源项目及其所有其他消费方的行为。其二是责任边界清晰——flag 的归属权始终留在定义它的团队手中，避免多个项目对同一 flag 产生冲突的写操作。需要变更 flag 时，仍必须回到源项目的控制台或通过源项目的凭证调用写入接口，这天然形成了变更审计的单一入口。

对多项目架构的意义

对于采用 monorepo 拆分或多服务架构的团队，feature flag 往往需要横跨多个应用统一控制。过去要么在各项目中重复定义 flag，要么维护一套自建共享机制。Project Connections 把这件事收归到平台层，配合部署身份认证，在便利性和安全性之间提供了一个折中方案。

不过它也有明确的边界：连接限定在同一团队内，跨团队的 flag 共享并未覆盖；消费方拿到的是只读权限，无法回写源项目的 flag 定义。对于需要双向同步或跨组织协作的场景，可能仍需额外方案。