Cloudflare Rust Workers 遇到 panic 还会把后续请求一起拖死吗？我做了个最小复现

如果你现在评估 Cloudflare Rust Workers panic recovery，先说结论：按我这轮用 workers-rs 最新模板、worker-build --panic-unwind 和 wrangler dev 做的最小复现，单次 /panic 和 /abort 请求都会失败并返回 500，但后续新的 / 请求还能继续返回 200 ok。这说明 Cloudflare 最近这轮 Rust Worker 恢复改进，至少已经把“一个请求炸掉后把后续请求一起拖死”这个老风险明显收紧了。

但这不等于 Rust Worker 从此“出了 panic 也没事”。它更准确的含义是：当前请求仍然会失败，只是失败不该再顺手把实例一起毒死。 如果你在看 Cloudflare 这条平台线最近的能力边界，可以先对照 TG Hubs 的 infra 主题页、前面的 Cloudflare 内部 AI 工程栈拆解，以及那篇讲上线前拦截链路的 GitHub eBPF 借鉴清单。这篇只回答一个更窄的问题：Cloudflare Rust Workers 的 panic recovery 现在到底值不值得你重新测一轮。

适合谁看，谁先别急

适合谁：

• 你已经在 Cloudflare Workers 上跑 JS/TS，现在想评估 Rust 是否能进关键路径
• 你关心的不是语法喜好，而是 panic / abort 会不会把同实例后续请求一起带崩
• 你准备给团队补一轮最小可靠性回归，而不是只看官方博客标题

先别急：

• 你现在连 Wrangler、本地回放、上线前验收链路都还没搭好
• 你想从这篇里得到“Rust Workers 已经对所有异常零风险”的大结论
• 你要验证的是线上多并发、Durable Objects、队列或绑定交互，而不是最小 HTTP 请求恢复

我这轮怎么测 Cloudflare Rust Workers panic recovery

我没有只看 Cloudflare 官方博文，而是按官方 Rust Worker 路线自己起了一个最小项目，专门做 3 个路径：

• /：正常返回 ok
• /panic：显式 panic!("intentional panic for recovery test")
• /abort：显式 std::process::abort()

我用到的环境是：

• rustc 1.95.0
• cargo 1.95.0
• wrangler 4.87.0
• compatibility_date = "2026-04-30"
• worker-build --release --panic-unwind

最小核心代码就是下面这样：

#[event(fetch)]
async fn fetch(req: Request, _env: Env, _ctx: Context) -> Result<Response> {
    let path = req.path();
    if path == "/panic" {
        panic!("intentional panic for recovery test");
    }
    if path == "/abort" {
        std::process::abort();
    }
    Response::ok("ok")
}

启动命令：

rustup target add wasm32-unknown-unknown
npx wrangler dev --port 8791

然后按这个顺序打请求：

curl -i http://127.0.0.1:8791/
curl -i http://127.0.0.1:8791/panic
curl -i http://127.0.0.1:8791/
curl -i http://127.0.0.1:8791/abort
curl -i http://127.0.0.1:8791/

我实际看到的结果

这轮最关键的 5 个结果是：

• 第 1 次 /：200 ok
• /panic：500，响应里带 intentional panic for recovery test
• 第 2 次 /：还是 200 ok
• /abort：500，Wrangler 报的是运行时取消了这次不会再产生响应的请求
• 第 3 次 /：依然 200 ok

也就是说，当前请求失败 这件事没有变，但 后续新请求还能继续成功。如果你要验证这轮 Cloudflare Rust Workers panic recovery 有没有真正碰到点，最直接的验收信号不是“/panic 变成 200”，而是：

1. 出错请求自己失败
2. 下一个正常请求还能活着回来
3. /abort 之后实例没有继续卡死

这和 Cloudflare 官方博客里说的方向是一致的：他们要解决的不是“panic 不再报错”，而是 panic / abort 不该再把后续请求一起污染。

这对生产判断意味着什么

如果你之前把 Rust Workers 排除在外，核心原因就是“一个 panic 可能把同实例后续请求也一起带崩”，那现在 Cloudflare Rust Workers panic recovery 已经值得重新进一轮测试名单。至少在我这次最小本地复现里，旧的“毒化后续请求”风险没有再出现。

但边界也要讲清楚：

• 这只是 wrangler dev 下的最小 HTTP 复现，不是全球边缘真实流量压测
• 我测到的是“恢复边界”，不是“业务逻辑不出错”
• 如果你的 Worker 里还接了 KV、D1、Queues、Durable Objects 或第三方 API，真正的失败链路会更复杂

所以更合理的动作不是“马上把关键路径全改成 Rust”，而是：把 Rust Workers 从“因为可靠性疑虑直接不看”改成“值得做一轮带验收条件的小范围验证”。

这轮最容易踩的 3 个坑

1）你没开 --panic-unwind

Cloudflare 官方这轮恢复能力，本来就和 panic=unwind / abort recovery 这条新链路绑定得很紧。你如果还是旧构建参数，测出来的东西就不代表这轮改进本身。

2）你把未来 compatibility date 直接填进去

我这轮第一次启动就撞到一个很实际的坑：compatibility_date = "2026-05-01" 会直接报 “Compatibility date is in the future and unsupported”。如果你抄模板时日期写到未来，连本地复现都起不来。

3）你把本地通过误读成线上完全等价

wrangler dev 能证明最小恢复路径已经比以前健康，但它不能替代真实上线环境里的并发、绑定、回退和日志验证。对上线前检查这件事，还是得把它放回你自己的发布前闸门里。

一份最小验收清单

如果你今天就要判断 Cloudflare Rust Workers panic recovery 值不值得纳入团队回归，我建议至少过这 4 条：

• 正常路径 / 能稳定返回 200
• /panic 失败后，下一次 / 仍然返回 200
• /abort 失败后，下一次 / 仍然返回 200
• 日志里能把“当前请求失败”和“实例后续仍可服务”分开看，而不是只盯一个 500

这 4 条都过了，才能说你至少验证了“单请求失败不再自动升级成实例级持续故障”。

FAQ

Cloudflare Rust Workers 现在默认就有 panic recovery 吗？

不能这么偷懒理解。Cloudflare 官方这轮改进是围绕新的恢复语义和 panic=unwind / abort recovery 路线展开的。你最好显式检查项目模板、构建命令和依赖版本，而不是假设“只要是 Rust Workers 就自动一样”。

std::process::abort() 现在也不会把后续请求拖死了吗？

按我这次最小复现，/abort 当前请求仍然会 500，但后续新的 / 请求还能恢复成 200 ok。所以更准确的说法是：abort 仍然是失败，但没有继续把后续请求一起拖死。

wrangler dev 测过了，线上就一定一样吗？

不一定。本地结果更适合回答“恢复边界有没有改进”，不适合直接替代生产结论。真正上线前，还是要补你自己的绑定、并发、日志和回退验证。

我什么时候还不该把关键路径改成 Rust Workers？

如果你的团队现在缺的是上线前验收、异常观测、或故障回退，而不是语言层可靠性，那么先补工程闸门，比先换到 Rust 更重要。Rust Workers 的恢复能力变强，不等于你的发布链路自动变强。

结论

如果你问的是 Cloudflare Rust Workers panic recovery 现在值不值得重新测，我的答案是：值得。 因为这次最小复现已经说明，panic 和 abort 仍会让当前请求失败，但不再自然演化成“后续请求一起挂掉”的老问题。

但如果你问的是 Cloudflare Rust Workers 现在能不能直接当成零风险关键路径默认项，答案还是不能。更稳妥的做法，是把它当成一个已经明显进步、值得重新纳入评估名单的运行时选项，而不是一句官方博客标题就能替你做完生产判断。

来源

• Cloudflare Blog: Making Rust Workers reliable: panic and abort recovery in wasm-bindgen
• Cloudflare Docs: Rust language support for Workers
• Cloudflare GitHub: workers-rs README