Simon Willison 发布了 datasette 1.0a32。按发布说明，这是一次 minor bugfix release，修的不是大功能，而是两个边角：/db/-/execute-write 端点里的 INSERT ... RETURNING 查询问题，以及多项 base_url 相关问题。

这类版本容易被忽略，也容易被误读。它不是 Datasette 1.0 正式版，也没有证据表明带来性能提升、安全修复或离线能力。它更像 1.0 前的一次补缝：把新写入端点和复杂部署路径里的问题先清掉。

对普通浏览公开数据页面的人，影响可能不明显。对用 Datasette 做内部数据工具、写插件、接 API 的开发者，这次更新更具体：少一个写入流程里的坑，少一类部署路径错位。

1.0a32 修了什么：写入返回值和 URL 前缀

这次更新可以压成两条。

一条在写入端点。新的 /db/-/execute-write 端点中，INSERT ... RETURNING 查询存在 bug。INSERT ... RETURNING 的用途很直接：插入一行后，马上拿回生成的字段，比如新记录 ID 或默认值。

另一条在部署路径。Willison 说，前一天实验 Service Workers 时，暴露出一批 base_url 问题。这里的重点不是 Service Workers 本身，而是它把 URL、资源路径、缓存和路由前缀的问题照了出来。

修复项影响场景谁最该关心现实动作
/db/-/execute-write 中的 INSERT ... RETURNING bug写入后立刻取回新记录、默认值或 ID试用写入端点的开发者、插件作者测试现有写入流程，减少额外查询或规避代码
多项 base_url 问题子路径部署、反向代理、非根路径站点把 Datasette 放在代理后或内部路径下的团队在测试环境验证链接、静态资源、API 路由是否正常

我更在意的是第一条。因为写入 API 一旦进入工作流，就不只是“查得到查不到”的问题。它会影响表单提交、脚本导入、插件逻辑，以及后续数据是否能被正确接上。

这也是 1.0 前版本该做的事。少一点新花样，把已经放出来的能力修到可预期。

base_url 为什么会在 Service Workers 实验里冒出来

base_url 是很多 Web 应用的老麻烦。

应用跑在域名根路径时，问题常被盖住。比如 https://example.com/ 下，一切链接都从根开始，开发时也容易顺手写死路径。

但真实部署经常不是这样。Datasette 可能被放在 /tools/datasette/ 这样的子路径下，也可能在 Nginx、Cloudflare 或企业网关后面。此时页面链接、静态资源、API 路由，只要有一处没处理好前缀，就会错位。

Service Workers 会放大这类问题。它涉及资源拦截、缓存、请求作用域和路径匹配。路径一乱，问题会比普通页面跳转更早暴露。

但边界要说清楚：这次发布不能被理解成 Datasette 已经正式支持离线运行。原始信息只说明，Willison 在实验 Service Workers 时发现了 base_url 问题，并在 1.0a32 中修复了多项相关问题。

这个限制很重要。开发者可以把它看作部署稳定性的修补，不该把它当成离线架构承诺。

谁该升级，谁可以先观望

如果你只是用 Datasette 展示只读数据，且站点部署在根路径，没有使用新写入端点，这次更新不一定需要立刻打断工作流。可以跟随常规维护节奏处理。

如果你符合下面两类情况，就更应该安排测试和升级：

  • 已经在用 /db/-/execute-write，尤其依赖 INSERT ... RETURNING 拿回写入结果；
  • Datasette 部署在子路径、反向代理之后，或需要依赖 base_url 保证链接和 API 路径正确。

动作不需要复杂。先在测试环境跑一遍写入流程，再检查页面链接、静态资源、API 路由。插件开发者还要看一眼自己有没有为 INSERT ... RETURNING 写过绕路逻辑；如果有，升级后可以评估是否删掉。

这里也有现实约束。1.0a32 仍是 1.0 前的 alpha 版本，不是正式稳定版。对生产环境来说，正确姿势不是看见版本号就直接上，而是把它当成一次针对边界问题的修复，按自己的风险等级验证。

接下来要看的不是有没有更响亮的新功能，而是三件事：写入端点语义是否继续稳定，base_url 在代理和子路径部署下是否少出回归，Service Workers 相关实验是否有明确边界。现在能确定的，只有这次补丁已经把两个具体坑往前推了一步。

小版本见真章。1.0 前真正有价值的工作，往往不是把旗子插得更远，而是把脚下的坑填平。