产品介绍页已经写成HTML，想发一个能访问的网址，可以直接用Cloudflare Workers的Static Assets。关键在于让文件由静态资源系统提供：这类请求免费且不限量；首页每次访问都执行脚本，则要计算Worker调用。官方计费页明确区分了两者。

纯静态站点要准备哪些文件？

这里采用最小项目：一个首页、一张图片和一个关于页面，没有登录、数据库或服务端渲染。电脑需有可用的Node.js与npm，并准备Cloudflare账户。下面是依官方文档整理的命令与配置，未在本次研究中实际部署。

公开目录只放浏览器应该拿到的文件。把HTML、CSS、图片放进去即可；环境变量文件、服务端源码和私有资料不要混入。已有框架项目应先完成静态构建，再选输出目录，不能把源码文件夹改名成静态网站。

用五步发布一个HTML站点

第一步：创建项目。 在终端执行官方静态站点入门给出的创建命令：

npm create cloudflare@latest -- my-static-site

依次选择Hello World example、Static site、TypeScript；Git版本管理选Yes，立即部署选No。然后进入新目录：

cd my-static-site

第二步：放入成品文件。 将首页保存为public/index.html，另放public/about.html和public/logo.png。检查生成的Wrangler配置；这个纯静态示例可使用如下wrangler.jsonc内容，名称可改成该账户内另一个项目名：

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "my-static-site",
  "compatibility_date": "2026-09-15",
  "assets": {
    "directory": "./public"
  }
}

assets.directory决定上传哪一批文件。此例不用main入口，也不需要为了返回HTML而写一个fetch处理器。配置依据见资源目录与绑定文档。

第三步：本地预览。 启动Wrangler，打开终端提供的本地地址：

npx wrangler dev

检查首页中的图片能否出现，关于页面链接能否打开。给首页标题加上“发布示例”之类的明显标记，便于稍后判断线上是否为这次内容。

第四步：部署。 在预览终端按Ctrl+C停止本地服务，再在项目目录运行下列命令，按提示登录并授权正确的Cloudflare账户：

npx wrangler deploy

打开输出中的workers.dev地址。首页标记、图片、关于页面都应与本地一致。以后更新文件，仍需重新部署；只修改本地文件不会改变线上版本。

不要只验收首页截图。直接复制关于页面地址到新标签打开，确认它脱离首页导航也能访问；再打开图片地址，确认文件本身已上传。如果标题已更新而图片缺失，就回到成品目录检查图片文件名和HTML引用是否一致。

第五步：看请求。 进入Cloudflare的Workers & Pages，在Overview里选择刚才的Worker，查看Metrics请求图。具体入口由官方指标文档提供；它用来观察运行时请求，并不能直接当成网站访客数。

免费额度到底分成哪几项？

截至2026年9月15日核验，以下三项最影响纯静态站点的发布。文件数量与大小取自Workers平台限制。

资源或动作Workers Free当前口径发布前对应检查
直接返回静态资源请求免费且不限量，资源存储无额外费用确认没有让全部请求先跑脚本
调用Worker脚本账户每日100,000次请求合计同一账户其他Worker的调用
静态资源文件每个Worker版本20,000个，单个最大25 MiB查看成品目录中的文件总数和最大文件

十万次按UTC零点重置，即北京时间上午八点。这里限制的是请求，不是十万名访客。一个页面加载多种资源，或前端反复调用接口，都会使两种数字分离。

资源请求不限量也不等于文件大小不限。示例站若要放一个30 MiB下载包，就已超过单文件上限；降低首页访问次数不会解决上传问题，应另选适合大文件的存储方案。

加接口之后，哪些访问开始占额度？

默认情况下，匹配静态文件的请求直接返回资源。配置run_worker_first: true则让请求无条件先调用Worker脚本。若只是纯展示页，保留默认行为更简单；需要在读文件前验证登录状态时，才有理由改变顺序。

配置文档也支持用路径数组选择性运行脚本。假设以后增加一个询价接口，可以围绕接口路径设计路由，而不必让每张公开图片也执行同一段逻辑。鉴权页面不能为了省额度改成公开直出。

举个计算示例：一天有八万次静态文件请求和三千次接口脚本调用，在静态请求未先经过脚本的前提下，后者才进入脚本额度；这是说明计数方式的假设数字。按静态资源计费说明，免费版启用脚本优先并耗尽额度后，匹配该规则的请求会返回429，不会自动退回静态资源服务。

上线后怎样判断数字是否看错？

这个没有脚本入口的纯静态示例，不能靠Worker运行时请求图确认页面有人访问；应直接打开线上文件验收。以后Metrics里看见脚本调用，再结合配置查它来自接口、服务端渲染，还是全站脚本优先。查看当天时要注意UTC计数周期；最近几分钟的图表可能有聚合延迟，不适合拿连续刷新后的即时差值结算。

若目标是知道访问者从哪里来、哪个按钮有人点，应另做Umami事件与UTM统计。部署选择尚未确定，可对照GitHub Pages域名设置了解另一条静态发布路线；后续工具选择收在出海工具栈。这篇没有评测各地区打开速度，也不覆盖SSR框架适配；先让这个小站的页面、图片和子链接正确上线，再接入业务功能。