发布小型 Go、React 与 SQLite 服务，并验证它能恢复

语言： English | 简体中文

发布日期：2026-10-08

我把 Go API 和 React 工作台打包为同一 Docker 服务，随后完善备份、恢复和浏览器请求边界，把开发应用推进成有 readiness 和明确失败行为的个人使用版本。

工程重点：发布工程、恢复与服务边界。

个人服务的价值，取决于它能否稳定启动，以及数据能否从错误中恢复。这部分工作的重点是从多个方向检查发布行为是否符合文档。

一个进程，一个 origin

Go 服务通过 -web-dir 直接提供已构建的 React：/ 和 /assets/ 是前端，/api/... 去掉前缀后进入 API，已有根路径接口仍供脚本和 CLI 使用。

多阶段 Dockerfile 从按 digest 固定的基础镜像构建前端和静态 Go binary，并使用 allowlist 限制 build context。Compose 只发布到 127.0.0.1，固定容器内端口和数据库路径，只转发明确列出的 provider 配置。

/healthz 不碰数据库，只表达进程存活；/readyz 在两秒内 ping SQLite，并驱动容器健康检查。服务的运行范围是本机或可信网络。

从不同方向验证同一版本

FLH-001，10 月 7 日：隔离副本中的检查发现，server build 失败可能被验证 recipe 掩盖。
FLH-011，10 月 7 日：构建镜像、等待健康、联用工作台/API、替换容器、确认 capture 幂等，并在独立项目恢复备份。
FLH-012，10 月 7 日：headless Chrome 的 27 项检查通过，同时记录一项既有 CSS 缺陷。
FLH-013，10 月 7 日：由打包实现会话进行的自审发现八个问题；报告没有将其包装成独立审查。

恢复流程中的实际缺陷

文档中的 restore 在下一次普通 docker compose up 后会回到旧数据库；daily migration 复制整个 data/，夹带无关数据库；启动错误实际导致重启循环，而非文档写的 unhealthy；备份依赖的 sqlite3 与 sha256sum 没有列为前提。

另有两个早于打包的浏览器边界问题：外站页面可以用 text/plain POST 写入数据，服务也接受任意 Host，存在 DNS rebinding 风险。

把恢复做成持久行为

FLH-016 的修正保持同一配置路径：先复制备份到 staging 并验证 checksum，要求 SQLite integrity check 精确返回 ok，再把旧目录保留为备份并将 staging 改名到位。

备份和日常迁移只复制数据库及 WAL/SHM sidecar。验证 recipe 对任意构建失败立即退出。测试 harness 直接运行文档 shell 段，并注入来源缺失、数据库损坏、伪 SQLite 退出 0 却输出错误内容、checksum 被改等故障。

收紧浏览器请求边界

FLH-017 调查复现了八次跨站写入，包括 provider 抽取和伪造 INVALID 判断，也证明仅检查 Content-Type 不够，因为部分 mutation 没有 body。

FLH-019 加入 Host allowlist、Origin / Fetch Metadata 检查和 Go 标准 cross-origin protection；浏览器 mutation 需要 JSON body type，并可显式信任 Vite 或 TLS reverse proxy 的 origin。这是浏览器请求保护，不是账户认证。

只在开发模式出现的失败

React StrictMode 会重放 effect。三个组件 cleanup 清除了 mounted 标志，却没有在重放时恢复，结果响应被忽略、按钮一直 pending。FLH-021 修复了这一生命周期问题；回归测试先在旧代码失败，再在修复后通过。

记录仍需处理的事项

当时没有报告确认 allowlist 目录中疑似 secret 文件进入 build stage 的问题已修复。数据库文件仍为 644，通过私有目录权限限制访问。Migration 只前进，旧 binary 也不会拒绝新数据库，因此升级前备份仍是操作要求。

实现结合 AI 编码工具，由我负责方向、任务与审查。验证结果来自以下项目报告。