VirtualCardxCloudflare Workers 免费版做 API：额度与安全做法
做虚拟卡相关的小工具，很容易先想到做一个 API：查 BIN 信息、把公开的费用表整理成 JSON，或者给内部运营页提供只读数据。Cloudflare Workers 很适合把这类轻量接口放到边缘运行，但“免费”不是“没有边界”。如果先把限制算明白，后面少很多返工。
本文只讨论 Workers 免费计划如何承载小型、低风险 API。它不是支付处理方案，也不该接收完整卡号、CVV、私钥或身份材料。涉及开户、充值、交易和个人数据时，应使用合规服务商提供的受控接口，并让安全与法务先审一遍数据流。
先看清免费计划实际给了什么
截至 2026 年 8 月 19 日，Cloudflare 的 Workers Pricing 页面写明：Workers Free 每天有 100,000 次请求，每次调用最多 10 ms CPU time。Limits 文档的账户计划表也列出了 100,000 requests/day。
这两个数字经常被误读。它们不是“每月十万次”，也不是说一次请求可以在后台随便跑十秒。请求量是按天计，CPU 时间则是 Worker 实际执行 JavaScript 的时间。等待网络响应不等于一直占用 CPU，但把大段数据循环处理、做复杂加密或在请求里跑重型解析，仍然可能很快撞上每次调用的 CPU 上限。
对一个返回几十行 JSON 的 BIN 说明接口，10 ms 往往够用。对“收到请求后去抓多个第三方网站、清洗 HTML、再调用模型总结”的接口，它就不合适。别把后者硬塞进免费 Worker，失败时用户只会看到 5xx，不会在乎你的架构有多新。
适合放在 Workers 上的虚拟卡周边功能
我会优先选择数据量小、结果可缓存、输入可控的功能。例如根据前六到八位返回发卡组织和国家的说明；根据平台代号返回人工维护的公开规则；把站内已经审核过的“充值前检查清单”作为 JSON 返回。这些都是信息服务，不碰资金指令。
一个实用原则：接口要能在没有数据库、没有外部请求的情况下给出基本答案。把常用的静态映射放在 Worker 代码或经过审核的绑定数据里，缓存命中时直接返回。需要实时核验的任务另开队列或后端服务，不要让访问者的一次点击承担所有工作。
一个够小的返回格式
{
"prefix": "123456",
"result": "请以发卡行和实际授权结果为准",
"updatedAt": "2026-08-19"
}刻意保留“以实际授权结果为准”并不是推脱。BIN 数据会变，卡头也不能单独证明某张卡一定可用、属于某个用户，或能通过某个商户。我们在免费 BIN 查询怎么用：卡头核验与安全边界里已经解释过这点。API 的文案也该保持同样的边界。
从最小 Worker 开始
先写一个只有一个路由的 Worker：校验请求方法，读取一个短参数，返回固定 JSON，再给响应加上缓存和安全头。上线前用 curl 连续请求几次，确认错误输入不会泄露堆栈，也不会让响应体突然变成一大段 HTML。
路由越少，观察问题越容易。等访问量和数据来源都稳定，再增加版本号，例如 /v1/bin/123456。版本化不是为了显得专业，而是为了你修改字段时不会把已经接入的页面或脚本一起弄坏。
密钥别进仓库，也别下发给浏览器
不少泄露事故的开端很朴素：有人把第三方 API token 写进 Worker 源码，随后代码进了 Git 仓库或被前端请求看到。Cloudflare 的 Secrets 文档建议把敏感值作为 secret 保存，再通过运行环境读取。这个习惯应当从第一个测试项目就开始。
更重要的是区分两类密钥。服务端密钥可以由 Worker 使用，但绝不能原样返回。浏览器端确实需要的公开标识与可调用的服务端凭据不是一回事。若一个 token 泄露后能扣费、读取客户资料或创建卡，它就不该出现在 HTML、JavaScript bundle、日志或截图里。
日志也要克制。记录请求 ID、路由、状态码和耗时通常够排障；不要完整记录 Authorization 头、查询字符串里的个人信息，或上游服务原样返回的敏感字段。出问题时，日志系统往往比生产数据库更容易被多人访问。
限流、缓存和输入检查要一起做
100,000 次日请求听起来不少，可一段被复制到群里的脚本就能在几分钟内消耗掉。免费额度适合验证需求，不适合默认接受任何来源的高频调用。至少要检查方法、路径和参数长度；对公开接口限制单个 IP 的频率；对后台接口要求身份验证。具体可选方案要按你的 Cloudflare 产品与套餐复核，别把网上旧教程的配额当成当前规则。
缓存是另一个常被低估的工具。对不随秒变化的 BIN 说明、公开帮助文本或站内分类数据，给出合理的缓存时间可以减少 Worker 执行次数，也让用户更快拿到结果。反过来，余额、订单和卡状态不能因为“省请求”就缓存给下一个访问者。这里的错误不是性能问题，是数据泄露。
输入验证同样别省。BIN 查询只接受数字和合理长度；平台代号采用白名单；未知输入返回明确的 400 或 404。不要把用户提供的 URL 直接拿去 fetch，也不要允许任意 origin 调用带管理权限的接口。这两种“方便”很快会变成 SSRF 或滥用入口。
上线前做一次小而严肃的检查
- 确认接口不接收完整卡号、CVV、助记词或身份证件。
- 确认所有 token 都来自 Secret，仓库、浏览器和日志里都找不到它们。
- 用正常输入、空输入、超长输入和错误方法各测一次。
- 检查缓存响应不会包含用户专属数据。
- 记录 Workers 文档的核验日期；计划价格和限制会调整。
如果你的目标是把站点部署在 Workers 上而非写 API，可以继续看Cloudflare 中 Astro 启用 IndexNow 方法。两件事的共同点是：先让请求路径清楚、可验证，再谈自动化。
FAQ
Workers 免费版能直接处理虚拟卡充值吗？
不建议。充值和支付涉及资金指令、身份、风控与服务商协议。Worker 可以做经过设计的前端网关或状态展示，但不能因为部署简单就绕开支付服务商、权限控制和合规要求。
100,000 次请求够不够？
取决于访问模式。内部工具或缓存良好的公开说明接口可能够用；被脚本反复调用的开放 API 未必。用真实日志统计每日请求、错误率和缓存命中，再决定是否升级或拆分服务。
10 ms CPU 是否等于接口只能运行 10 ms？
不是简单的墙钟时间。它是 Worker 执行 CPU 的限制。仍应把处理逻辑保持短小，并用官方限制文档核对你使用的产品和套餐。
结语
Workers 免费版值得拿来做一个边界清楚的原型：少量路由、短响应、明确输入、没有敏感支付数据。真正需要花心思的地方不是把代码部署上去，而是决定哪些数据绝不该经过这个接口。这个判断做对了，额度才有意义。