Python 后端跑进浏览器：这次有点不一样

Simon Willison 这次做的实验，乍看像一句老话：把 Python 跑在浏览器里。

但关键不在 Python。Pyodide 早就能通过 WebAssembly 把 Python 带进浏览器，Datasette Lite 四年前也已经这么干了。真正有意思的是：这次浏览器里的 Python 应用，不再只是生成一点 HTML，而是通过 Service Worker 接住同源请求，再按 ASGI 协议交给 Python Web 应用处理。

换句话说，浏览器不只是前端容器了。它正在被改造成一个有路由、有请求、有后端语义的本地运行时。

这条链路到底在干什么

这次实验的组成并不复杂，但拼法很关键。

Willison 已经做了两个验证：一个基础 FastAPI/ASGI demo，一个运行 Datasette 1.0a31 的 demo。材料证明的是“可行”，不是“生产可用”。静态文件仍然要被托管，浏览器也不等于完整服务器。

这里最容易误读成“后端没了”。不对。更准确的说法是，一部分后端逻辑可以被搬到用户本地，在浏览器安全模型里运行。

这句话的分量比口号大。

为什么比旧版 Datasette Lite 更关键

旧版 Datasette Lite 已经能在浏览器里跑 Datasette。问题在于，它走的是 Web Worker 加导航拦截：用户访问页面时，Python 应用生成 HTML，再把内容塞回来。

这能工作，但有一个很麻烦的副作用：<script> 标签里的 JavaScript 不会正常执行。结果就是 Datasette 的部分功能会坏，很多插件也会跟着坏。

新方案换了入口。Service Worker 拦截 /app/ 下的同源请求，把请求交给浏览器内的 Python ASGI 应用处理。浏览器看到的更像一次正常请求，而不是一次被手工拼回来的页面。

这就把问题从“我能不能生成 HTML”，推进到“我能不能在浏览器里模拟一个像样的 Web 应用运行环境”。

差别不小。

Willison 也没有把话说满。他提到这次是让 Claude Opus 4.8 通过 Claude Code for web 帮忙探索实现，自己还在梳理机制，理解清楚后才计划升级 Datasette Lite。这一点反而让这事更可信：它是研究性 PR，不是 AI 一键发布了一个新平台。

我的判断：本地优先的一小步，不是后端的讣告

我更在意的是它背后的方向。

过去十几年，浏览器不断吞掉客户端能力：存储、离线、图形、音视频、加密、文件系统接口。现在，连后端应用的请求处理模型也开始被浏览器吸收。历史上铁路吃掉驿站，电力吃掉蒸汽机的分散动力，互联网吃掉报纸发行渠道，逻辑都相似：新基础设施先承载旧功能，再改变旧功能的形状。

但类比只能到这里。浏览器不是服务器，它有安全沙箱、性能天花板、资源限制，也受制于不同浏览器实现。更别说数据库持久化、并发、权限、网络访问、插件兼容，这些都不是一个 demo 能结账的。

所以这件事的正确打开方式，不是欢呼“以后不用后端了”。那是把工程问题写成鸡血文。

更现实的影响在本地优先应用：数据分析、小型知识库、可分享 demo、教学环境、离线工具、无需安装的 Python Web 应用。对 Datasette 这种“把数据变成可浏览应用”的工具尤其合适。用户打开一个静态页面，就能在本地跑起一套接近真实 Web 应用的交互，这很有价值。

“天下熙熙，皆为利来。”放在这里，利不是省服务器钱那么简单，而是省部署、减少信任成本、把数据留在本地。对开发者来说，这可能比又一个云端托管服务更诱人。

但刀口也在这里：浏览器给了你分发能力，也拿走了你对运行环境的控制权。模型看起来更自由，约束其实更细。

这次实验真正推开的门，不是通向“无服务器世界”，而是通向一种更轻的应用形态：静态托管负责分发，浏览器负责运行，Python 负责逻辑。门已经开了一条缝，能不能走成路，还要看兼容性、性能和开发体验怎么收尾。