以下是使用 Cloudflare Workers 时需要了解的一些已知 bug 和问题。
- 定义路由优先级时，模式中的尾部
/*可能不会按预期生效。
考虑在同一 zone 上部署的两个不同 Worker。Worker A 被分配 example.com/images/* 路由，Worker B 被分配 example.com/images* 路由模式。在此配置下，以下 URL 的解析方式如下：
// (A) example.com/images/*
// (B) example.com/images*
"example.com/images"
// -> B
"example.com/images123"
// -> B
"example.com/images/hello"
// -> B你会注意到所有示例都触发了 Worker B，包括最后一个示例，这体现了意外行为。
在子域上添加通配符时，以下 URL 的解析方式如下：
// (A) *.example.com/a
// (B) a.example.com/*
"a.example.com/a"
// -> B- 运行
wrangler dev --remote时，所有出站请求都会携带cf-workers-preview-token请求头，Cloudflare 会将其识别为预览请求。这适用于整个 Cloudflare 网络，因此出于安全原因，向其他 Cloudflare zone 发起的 HTTP 请求目前会被丢弃。要启用变通方案，请在 Worker 脚本中插入以下代码：
const request = new Request(url, incomingRequest);
request.headers.delete('cf-workers-preview-token');
return await fetch(request);当 Worker 使用 fetch() 发起子请求时，会使用 Cloudflare DNS 解析器。当 zone 使用部分（CNAME）设置时，Worker 需要能够解析的所有主机名都必须在 Cloudflare DNS 设置中有专用 DNS 记录。否则 Fetch API 调用将失败，返回状态码 530 (1016)。
Cloudflare DNS 中缺少 DNS 记录的设置
// Zone in partial setup: example.com
// DNS records at Authoritative DNS: sub1.example.com, sub2.example.com, ...
// DNS records at Cloudflare DNS: sub1.example.com
"sub1.example.com/"
// -> Can be resolved by Fetch API
"sub2.example.com/"
// -> Cannot be resolved by Fetch API, will lead to 530 status code在 Cloudflare DNS 中添加 sub2.example.com 后
// Zone in partial setup: example.com
// DNS records at Authoritative DNS: sub1.example.com, sub2.example.com, ...
// DNS records at Cloudflare DNS: sub1.example.com, sub2.example.com
"sub1.example.com/"
// -> Can be resolved by Fetch API
"sub2.example.com/"
// -> Can be resolved by Fetch API对于 Workers 子请求，只能向 URL 发起请求，不能直接向 IP 地址发起请求。要克服此限制，在你的 zone 中添加 A 或 AAAA 名称记录，然后 fetch 该资源。
例如，在 zone example.com 中创建类型为 A、名称为 server、值为 192.0.2.1 的记录，然后使用：
await fetch('http://server.example.com')不要使用：
await fetch('http://192.0.2.1')