一个上午,AI 把整个 Python 后端塞进了浏览器

溜得很 发自 AI观察室

2026 年 5 月 30 日，独立开发者 Simon Willison 在博客里甩出一个项目，一整套 Python ASGI Web 应用，整个跑在浏览器里。

没有后端 HTTP 服务器。除了几个静态引导文件，一台服务器都不要。

更离谱的是这东西不是他自己写的。他原话是「This morning I set Claude Opus 4.8 the task」，一个上午，Claude Opus 4.8 在 Claude Code for web 里把它捣鼓出来了。对应 GitHub 上的 PR #112，据 PR 记录是当天下午推送，6 个 commit，27 个测试全绿。

▲ Pyodide 官方文档

你敢信，这活儿干完合并删分支，前后就一天。

浏览器里跑 Python，到底卡在哪

▲ Pyodide 官方仓库

先说清楚一件事，浏览器跑 Python 早就不是新闻。

干这事的家伙叫 Pyodide，2018 年由 Mozilla 的 Michael Droettboom 搞出来的，把整个 CPython 解释器编译成了 WebAssembly。2021 年 Mozilla 把它转成了独立社区项目，到现在已经是浏览器跑 Python 的主力。

所以「在浏览器里执行 Python」这步，四年前就通了。

真正的坎在另一头。一个完整的 Web 应用，光能执行代码不够。它还得能接住 HTTP 请求，得有人把浏览器地址栏里那个 /app/users 翻译成应用能听懂的话。这活儿平时是服务器干的，Nginx、Uvicorn 这些。

现在服务器没了。谁来接请求？

Willison 其实四年前就撞过这堵墙。2022 年 5 月他做过 Datasette Lite，同样用 Pyodide 在浏览器跑，但当时走的是 Web Worker 加拦截导航的路子，大概 300 行 JavaScript。问题是返回的 HTML 里 PROTECT_0000 标签的 JS 不会被执行，一堆 Datasette 插件直接废掉。

他当年其实想用 Service Worker，掂量了一下还是选了 Web Worker。这回 AI 帮他把当年那条没走的路走通了。

Service Worker，那个一直被你忽略的家伙

关键先生是 Service Worker。

这玩意你天天用，但基本没人注意它。它平时干的是缓存、离线、推送通知那些脏活累活，最大的本事是能拦截页面发出的每一个网络请求。

新方案的思路就一句话，让 Service Worker 把所有 /app/ 下面的同源请求全拦下来，按 ASGI 协议喂给跑在 Pyodide 里的 Python 应用，再把应用吐出来的响应包成一个真实的 Response 还回去。

跟旧方案差在哪？差在「真实」两个字。

浏览器拿到的是货真价实的 HTTP 响应，所以返回 HTML 里的内联脚本会正常执行，303 重定向会正常跟随。旧方案里那些断掉的插件，这下全活了。

这里还得提一句 ASGI。它是 Python 异步服务器网关接口，3.0 版本 2019 年发布，主要由 Andrew Godwin 主导写的，就是定义服务器和 Python 应用之间怎么对话的一套规矩。

新方案聪明就聪明在，它没去改应用，而是让 Service Worker 假装成一台符合 ASGI 规范的服务器。应用根本不知道自己已经不在服务器上了。

不止 FastAPI，连 Datasette 整个搬进来了

光有 demo 还不够说服人。

项目里塞了两个演示。第一个是 FastAPI 的小应用，0.136 版本，能点链接导航、能提交表单、能走 303 重定向、能调 JSON API、还能在页面里直接 fetch。这个还算预期之内。

真正让人「卧槽」的是第二个。

他们把完整的 Datasette 1.0a31 整个搬了进去。数据库导航、表格浏览、跑 SQL、写入、.json API，全都在浏览器里跑。连带 sqlite-utils、asyncinject 这一串十几个纯 Python wheel，一个不落塞进浏览器。

README 里写得很直白，「proving the mechanism isn't FastAPI-specific」。意思是只要是标准 ASGI 应用，理论上都能这么搬进浏览器，跟用什么框架没关系。这才是这个项目真正的分量，它证明的不是某个 demo，是一整套通用机制。

还有个细节挺戳人。所有 Pyodide 运行时和 wheel 都能下载到本地，整个 demo 能完全离线跑。Willison 当年做 Datasette Lite 的初衷就一句话，「I want as many people as possible to be able to use my software」，任何能跑 WebAssembly 的浏览器都能用，不装 Python 环境也行。

别急着吹，这里面的坑还真不少

冷静一下。这东西离「随便就能用」还差得远。

最常被骂的是体积和加载。Pyodide 官方自己都承认，核心包好几个 MB，带上科学库能到几十 MB。Willison 2022 年就吐槽过，在很多按流量计费的地区，10MB 下载量已经太多了。

有人在 Pyodide 的 GitHub issue 里撂过一句狠话，说只要首次加载还要 5 秒，浏览器里的 Python 就威胁不到 JavaScript。这话挺扎心，不过也就是一种声音，当然也有人觉得，能离线、能免装环境，这个体积值。

性能也天生比原生慢，WebAssembly 和浏览器的限制摆在那儿，绕不开。

项目自己也老实列了一堆局限。只支持 HTTP 和 lifespan，没有 WebSocket。请求和响应都不是流式的，请求体一次性投递，响应先缓冲再返回。单 Pyodide worker、单线程，并发请求只能在事件循环上交错排队，没为高并发调过优。

为了让 Datasette 真跑通，还得打一堆补丁。Datasette 的 base.html 硬编码了个 /-/jump 端点会逃出 /app/ 作用域，README 直接标注「Genuinely a Datasette bug」。写入页发的 X-Frame-Options: DENY 会挡 iframe，得在 Service Worker 里主动把这些 frame-busting 头剥掉。Service Worker 还读不到 Cookie 头，cookie session 穿不过去，只能靠直接注入 root actor 来认证。

补丁堆这么高，其实都指向同一个前提，应用得对每个 URL 都老老实实尊重 base_url。而这个前提，并不总成立。

那这事到底算啥

把吐槽放一边，我的态度很明确，这是个真东西。

它没发明新轮子。Pyodide 是现成的，Service Worker 是现成的，ASGI 是现成的。它干的是把三个本来不挨着的东西拼到一起，拼出了一个四年前没人走通的方案。Willison 自己都说了，做完打算据此升级 Datasette Lite 本体。

那它到底适合谁用？有一说一，场景挺清楚。交互式文档、教学 demo、纯前端就能托管的轻应用，这套东西是真香，不用配服务器，浏览器点开就跑。但要是你想拿它扛高并发、要 WebSocket、对加载速度还特别敏感，那就别想了，它现在压根不是干这个的。先想清楚自己在哪一档，再决定要不要碰。

有一说一，真正让我后背发凉的不是技术本身。

是这活儿的完成方式。一个资深开发者四年前绕开了的那条路，今年一个上午，他干脆把任务丢给 Claude Opus 4.8。AI 用红绿 TDD 写了 6 个 commit，27 个测试全绿，自己跑通了。他干的事更像是审稿和拍板。

说到底，差的可能不是能力。Willison 四年前不是攻不下这条路，是当年没工夫、也没必要专门花一个上午把它重做一遍。今年这个上午的成本，AI 帮他扛了。

中间隔着的，到底是四年的技术积累，还是一个肯花一个上午、还不喊累的模型？

你会愿意用一个加载要等十几秒、但完全不用服务器的浏览器版 Python 应用吗？

⭐ 关注溜得狠·设为星标 ⭐

AI 行业的事，我帮你盯着

📚 参考来源