Simon Willison 在 2026 年 6 月 23 日发布了一个名为 OPFS + Pyodide test harness 的测试工具，用来验证浏览器内运行的 Python 应用，能否通过 OPFS 编辑并持久保存 SQLite 文件。

这件事的看点不在“又多了一个小工具”。它真正指向的是 Datasette Lite 的下一步可能性：这个完全运行在浏览器里的 Python Datasette 应用，依赖 Pyodide 和 WebAssembly。如果 OPFS 在更多浏览器中表现稳定，Datasette Lite 才有机会从“查看和查询数据”进一步走向“编辑用户本地 SQLite 数据”。

OPFS + Pyodide test harness 是一个验证场，不是正式功能发布

Willison 的原始说明很短：他一直在思考 Datasette Lite 是否能编辑并持久保存用户电脑上的 SQLite 文件，而 OPFS，也就是 Origin Private File System，正是浏览器为源私有存储提供的一套文件系统能力。于是他用 Claude Code for web 辅助生成了这个 playground UI，用于在不同浏览器中试验。

这里要分清三件事：

项目现在发生了什么对开发者的意义
OPFS + Pyodide test harness一个跨浏览器测试界面验证 Pyodide 是否能可靠操作持久化文件
Datasette Lite浏览器内运行的 Python Datasette未来可能获得本地 SQLite 编辑能力
OPFS浏览器源私有文件系统不是任意读写用户磁盘路径的普通文件权限

这个边界很关键。OPFS 的“私有”指向浏览器源隔离下的存储空间，不等同于传统桌面应用拿到文件系统完整访问权。对用户来说，这降低了网页随意碰本地文件的风险；对开发者来说，也意味着导入、导出、同步、备份等流程仍要另行设计。

浏览器端 Python 应用缺的不是运行能力，而是可靠存储

Pyodide 和 WebAssembly 已经让 Python 应用进入浏览器成为现实。Datasette Lite 就是一个典型案例：用户不用安装服务器，也能在网页里运行 Datasette，查看 SQLite 数据。问题在于，浏览器应用过去更擅长“临时处理”，一旦涉及持久化编辑，体验就容易断在存储层。

这和传统 Electron 桌面应用形成对照。Electron 可以打包 Chromium 和 Node.js，较容易接触本地文件，但代价是安装包、更新、安全边界和资源占用。纯浏览器路线更轻，分享和启动成本低，却要服从浏览器沙箱。OPFS 如果可用，正是在这两条路线之间补一块短板。

受影响最直接的是做数据工具、内部分析工具和科研小应用的开发者。他们常面对一种尴尬场景：SQLite 文件很轻，Python 生态很好，但把工具交给非工程用户时，安装环境、权限配置、数据持久化都会变成支持成本。一个能在浏览器里稳定编辑 SQLite 的 Datasette Lite，会让这类工具更接近“打开网页即可使用”。

下一步最该看浏览器差异，而不是功能想象

原文没有给出兼容性结论，也没有宣布 Datasette Lite 的产品发布时间。OPFS + Pyodide test harness 的价值，恰恰在于把不确定性暴露出来：同样的文件持久化逻辑，在 Chrome、Firefox、Safari 等浏览器中是否一致，异常恢复是否可靠，刷新、关闭标签页、浏览器清理存储后数据如何处理，都需要实测。

这也是读者单看工具发布不容易意识到的限制。SQLite 的吸引力在于单文件、轻部署、跨语言，但浏览器内的“文件”不等于桌面系统里的文件。开发者如果现在就押注这条路线，现实动作应是把它当成原型验证：先测目标浏览器，再设计导入导出，再告知用户数据保存边界。

所以，这条新闻目前能支撑的判断是：OPFS 正在成为浏览器端 Python/WebAssembly 应用处理持久化 SQLite 数据的候选基础，但还没到可以放心当产品承诺的阶段。它已经跨过了“能不能试”的门槛，尚未跨过“能不能交付”的门槛。