服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- wrangler dev、Cloudflare Vite plugin、Vitest integration 和 cf dev 默认使用本地 flag store；空 store 会返回调用处提供的默认值。
- 远程 flag 不会自动同步到本地。需要时可显式运行 npx wrangler flagship flags pull <APP_ID>。
- 绑定上的 remote: true 会让本地评估改用远程 app；它与将远程 flag 复制到本地是两种不同操作。
- cf 有自己的默认本地数据目录。用 --persist-to 指向开发服务器正在使用的目录，才能共享同一份本地 flags；cf 本身不能拉取远程 flags。
- 本地 store 需要 Wrangler 4.135.0 或更高版本，或 Cloudflare Vite plugin 1.56.0 或更高版本；Local Explorer 支持需要更高版本。
为什么本地评估只返回默认值？
Cloudflare 在 2026 年 11 月 2 日的更新中说明，wrangler dev、Cloudflare Vite plugin、Vitest integration 和 cf dev 的 Flagship binding 在本地开发时默认读取本地 flag store。 Flag 是决定功能行为的开关；本地 flag store 是开发环境保存这些开关的存储。
新建的本地 store 初始为空。某个 flag 尚未写入本地时，评估结果就是调用该方法时传入的代码默认值。这不表示远程 app 也没有这个 flag，也不表示远程值已经被改写。
本地评估不会自动读取远程 app 的 flags。这样可以在不自动覆盖本地修改的前提下开发；已有本地数据时，也不需要为了启动开发服务器先访问远程服务。
需要远程 flags 时，显式拉取到本地
如果本地开发需要远程 app 中已有的 flags，先确认要使用的 app ID 和开发服务器的数据目录，再显式执行 Wrangler 的 pull 命令：npx wrangler flagship flags pull <APP_ID>。将占位符替换为目标 app ID。
pull 会把远程 flags 复制到默认本地目录 .wrangler/state。它不会自动运行；wrangler dev 也不会每次启动时拉取或覆盖你本地改过的 flags。
如果开发服务器使用另一个目录，给 pull 指定同一个 --persist-to <DIRECTORY> 路径。例如 Cloudflare Vite plugin 2.0 beta 使用 .cloudflare/state；先按实际插件版本确认目录，再让拉取和开发服务器指向同一处。
pull 把远程开关复制到本机开发状态，不会将本地修改部署到远程 app。
本地 flags 与远程评估不是同一回事
要在本地开发时直接对远程 app 进行 Flagship 评估，可在 binding 上设置 remote: true。这会改变 binding 的评估目标；它不会把远程 flags 填入本地 store。
还要区分 binding 评估与命令行管理：Flagship 的 flag 管理命令默认面向远程 app。要管理本地 store，命令需要带 --local；同一命令不能同时使用 --local 和 --remote。
如果目标是可重复的本地开发数据，使用本地 store 并按需显式 pull；如果目标是远程评估，则明确设置 binding。不要把命令默认目标误认为开发服务器的评估模式。
让 cf 和开发服务器共享同一目录
cf dev 也使用本地 Flagship store，但 cf 默认把本地数据保存在自己的目录，Wrangler dev 和 Cloudflare Vite plugin 不会读取那个独立目录。因此，工具之间看起来可能像是 flags 不一致。
Cloudflare 文档给出的本地列表示例是 cf flagship apps flags list --app-id <APP_ID> --local --persist-to .wrangler/state。这里的 .wrangler/state 对应 wrangler dev 和 Vite plugin 1.x 的默认目录。
Cloudflare Vite plugin 2.0 beta 的默认数据目录是 .cloudflare/state。先检查当前开发服务器实际使用的目录，再按文档让 cf 和 Wrangler 的操作共用该路径；不要仅凭工具名称假定它们共享默认目录。
cf 不能从远程 app 复制 flags。需要填充本地 store 时仍用 npx wrangler flagship flags pull <APP_ID>，并在设置了自定义目录时使用同一个 --persist-to 值。
按版本和数据目录逐项核对
本地 store 支持要求 Wrangler v4.135.0 或更高版本，或 @cloudflare/vite-plugin v1.56.0 或更高版本。Local Explorer 中的 Flagship 支持则要求 Wrangler v4.148.0 或更高版本，或 plugin v1.63.0 或更高版本。
排查时依次确认：当前 binding 是否设置了 remote: true；目标 app 是否已显式 pull；pull 与开发服务器是否使用相同数据目录；使用 cf 时是否带了指向该目录的 --persist-to。
本地 flags 只代表本地开发状态，不是生产状态。离线可用只说明无需自动拉取远程 flags，不代表应用的其他依赖都能离线运行；本地编辑或拉取也不会自行部署或改写远程 app。
资料来源
常见问题
pull 会删除只存在于本地的 flags 吗？
不会。当前配置文档说明，仅存在于本地 store 的 flags 会保留。这不表示所有本地值都会与远程值相同；仍应核对实际开关和数据目录。
所有 cf Flagship 命令都支持 --local 吗？
不是。文档只为列明的命令提供本地支持。例如 cf flagship apps get、cf flagship apps definitions get 和 cf flagship apps flags changelog 没有本地对应操作，会返回 This command has no local equivalent。先核对命令支持范围；去掉 --local 会改为访问远程 app。