管理一个网站，常常要在几个地方来回切换：终端里部署 Worker，浏览器里改 DNS，再去控制台找存储桶和访问策略。命令行工具不少，能管到哪里却各不相同。Cloudflare 在 2026 年 9 月 28 日发布的 cf，想把这些操作收进一个入口。
第一次使用前，需要弄清它能否接进自己现有的工作方式：要不要重新登录？旧项目还认不认？只管域名的人能不能用？下面按第一次安装的顺序说明。
它比 Wrangler 多管了什么
Wrangler 长期围绕 Workers 开发。cf 则覆盖 Cloudflare 公共 API，包括域名、DNS、存储和安全设置，也提供 Workers 的开发、构建和发布命令。官方文档当前写的是超过 2,900 个命令；发布文章用接近 3,000 项 API 操作来介绍覆盖面。计数口径不同，不必把它理解成三千种全新产品。
对普通站长，这意味着不用为了列出 DNS 记录临时拼一条 curl 请求。对写脚本的人，它省下的是认证、参数组织和输出解析的重复劳动。对编程助手，它提供了一套可以搜索、可以查询参数的命令目录。
但 cf 仍是 Beta。配置格式和命令都可能调整，旧的部署流程没有必要为了追新立即换掉。Cloudflare CLI 官方文档、发布公告
先检查 Node，别从安装报错开始
官方要求 Node.js 22.18 或更新版本。虽然 npm 包的 engines 写的是大版本 22 起，实际加载 TypeScript 配置还需要满足更具体的要求。Bun 运行时目前不能加载 cloudflare.config.ts，不要因为文档里列了多个包管理器，就认为运行时支持情况也一样。
node --version
npm install --global cf
cf --version
资料核对时，npm 发布版本为 1.0.0-beta.6。版本号只是截至 2026 年 9 月 30 日的快照，后续安装应看当时的文档与发布记录。若机器上已有另一个 cf，这个包同时提供 cloudflare 命令，两者进入同一工具。
全局安装方便临时查资源；要写进项目和 CI，最好把版本放进项目依赖及锁文件。否则今天电脑上跑通的命令，下周自动化环境可能已经拿到另一个 Beta。
不登录，也能先试试命令搜索
第一次使用不必急着把账号交给它。先搜索一项熟悉的操作：
cf cli search "create a DNS record"
cf schema dns records create
cf dns records create --help
第一条会返回最多五个匹配命令，第二条描述生成式 API 命令对应的请求，第三条查看实际参数。搜索在本地运行，不需要凭据。描述任务时要加引号，否则多个单词会被当成分开的命令参数。
DNS 记录相关命令的搜索结果。
这一步也能看出“搜索”与“执行”的区别。搜索结果中可能同时出现创建、修改、覆盖和删除，它只是帮你找到入口，没有替你判断应该选哪一个。先看摘要，再看帮助，比照着第一个结果执行可靠。
登录的是 cf，不是 Wrangler
cf auth login
cf auth whoami
cf zones list
登录会打开浏览器，并提供一次性代码；确认授权之后，再用 whoami 检查当前身份。远程服务器没有桌面浏览器时，可运行 cf auth login --no-browser，在自己的电脑上打开它给出的链接完成授权。
这里有一个容易忽略的变化：cf 保存自己的凭据，不会复用 wrangler login 的登录状态。机器上的 Wrangler 已经可用，并不代表新工具已经登录。反过来，登录成功也不代表账号或 Token 对所有资源都有权限。
如果列表结果不对，先确认账号，再确认域名是否在该账号里；如果资源命令报权限错误，就查对应操作需要的权限。不要把这两类情况统统归为“CLI 不稳定”。安装与认证说明
用一条只读命令建立信心
找到自己管理的域名后，列出解析记录：
cf zones list --name example.com
cf dns records list --zone example.com --type A
示例域名应替换为自己的。域名所在区域称为 zone，其 ID 与账号 ID 是两回事。按名称指定 zone 很方便，但在多个账号环境中，还需要保证选中了正确的账号。
列表只返回一页，记录多时要继续分页，不能把第一页当完整备份。保存输出也很直接：
cf dns records list --zone example.com > dns-records.json
标准输出主要是 JSON，提示和错误写到标准错误。这样保存的文件适合进一步处理，但仍需检查命令是否成功、页数是否完整，以及其中是否包含不想公开的源站信息。
改动之前，先把请求打印出来
创建 DNS 记录支持 --dry-run。以下命令只预览请求：
cf dns records create \
--zone 00000000000000000000000000000000 \
--body '{"type":"A","name":"test","content":"192.0.2.1","proxied":false}' \
--dry-run
全零 zone ID 是演示占位符，192.0.2.1 是文档示例地址。这条命令不需要登录，也不会创建解析记录。正式使用时必须换成真实 ID 和实际地址，并检查记录类型、名称及代理开关。
预览时使用 ID，不要用域名名称代替。dry run 不查询域名对应的 zone，名字会直接出现在请求路径里。预览成功只说明请求能够被组织出来，不证明账号有权限，也不证明目标服务器可用。
对于网站迁移，DNS 请求正确只是其中一步。改完以后还要查权威解析、证书、HTTP 返回和页面资源；如果从代理切换到直接解析，源站也必须允许访客直接连接。CLI 能提交变更，不能替你完成这些验收。资源管理教程
现有站点不必为了 cf 改架构
一个跑在 VPS 上的博客，可以只用 cf 管 Cloudflare 里的域名和资源。它不会把服务器上的 Caddy、数据库或 Docker 自动改成 Workers，也不会因为安装了 CLI 就让访问变快。
同样，域名的 DNS 不在 Cloudflare 时，这个工具也不能直接替第三方 DNS 服务改记录。你仍可以用它管理账号里的其他 Cloudflare 产品，但要把“工具安装在哪里”和“资源由谁管理”分开看。
已有 Wrangler 项目也可以并行使用资源命令，开发部署继续用旧工具。只有准备迁移项目配置时，才进入 cf migrate 的流程。官方提醒：未迁移项目中直接运行 cf dev、cf build 或 cf deploy，可能触发不符合原项目的自动配置。给 Wrangler 用户的说明
第一天做到这里就够了
确认版本、理解认证、列出正确账号的资源、预览一条请求，这四件事比马上发布一个新 Worker 更有助于判断工具是否适合自己。之后再挑一个重复性高的任务，例如导出解析记录或查询存储桶，把它做成脚本。
后续使用 Beta 时，遇到参数差异先查当前版本的 --help，别急着拿旧教程里的参数硬套。