摘要
只活在我浏览器里的待办 App，怎么变成一个能发给别人的链接？这篇实测上线全流程：一句话、一分钟、免域名免备案、自带 https。也诚实交代局限——数据存在各自设备的浏览器里，不跨设备同步，以及导出导入的迁移方案。
话题标签：#WorkBuddy #免费部署 #个人网站 #效率工具
一个拖了 11 篇的矛盾，今天正面解决
第 04 篇写需求卡的时候，我留过一对矛盾，当时被我记在"模糊区"里：
- 数据不上云——运维的职业病，我信不过我看不见的存储
- 手机也能看——我老婆要在她手机上用
这俩当时是冲突的：不上云=数据只在我设备上；手机也能看=数据得到处都有。
现在可以宣布解法了，因为这个解法在运维世界几乎是条件反射级的：把页面和存储分开看。
页面是静态文件，随便放云上——这就跟我托管一个静态官网没有任何区别，nginx 一挂谁都能访问，但 nginx 上没有你的业务数据。数据呢？数据从来不上云，它存在于每台打开这个页面的设备的浏览器里。我电脑上打开，数据库在我电脑；我老婆手机上打开，数据库在她手机。两份数据，互不相干，各自独立。
这个架构有个学名我不用背，用运维的话说就是：前端静态托管 + 客户端存储。零后端、零服务器、零数据库托管费用。
"数据不上云"保住了（数据只在自己设备），"手机也能看"也保住了（页面人人可访问）。矛盾不是被消灭的，是被架构化解的。
上线过程：一句话，一分钟
解法通了，实操简单到让我怀疑人生。
我对 WorkBuddy 说：
把这个待办应用发布上线，我要一个能发给别人点开的链接。
它确认了一次发布方式，然后开始处理。前后大概一分钟，它给了我一个链接：
https://my-todo-list-12359.app.workbuddy.host/
我检查了三件事，全是运维本能：
- 是 https——证书是自动配的，不用买、不用续、不用碰 acme
- 免域名免备案——用的是它提供的托管域名，我连 DNS 都没碰
- 无服务器概念——我没有租任何主机，它就是把这个静态文件放到了它的托管上
我用电脑浏览器打开这个链接——应用跑起来了，SQLite 引擎加载，9 条内置示例数据躺在里面。手机也试了，竖屏自适应，观感良好：
给没用过的人翻译一下这个体验：你没有任何基础设施，但你有了一个 https 的公网地址。搁五年前，这事儿的前置条件是：买域名、备案、租服务器、配 nginx、申请证书、配自动续期——一整套下来没有一个周末下不来。
上线前必须想清楚的两件事（都是实测的坑）
第一件：新访客打开链接，看到的不是空白，是 9 条示例数据。
这是我实测时发现的最有趣的坑。发布后我用另一个浏览器（模拟新访客）打开链接——列表里躺着 9 条示例待办，"审一下今晚的发布窗口"什么的赫然在列。
第一反应是诡异："我的数据怎么跑别人浏览器里去了？"第二反应才是真相：这是应用内置的示例数据，任何新设备首次打开都会看到。它们不在任何人的数据库里，是页面上代码兜底显示的。
这个坑的杀伤力在于误会：我老婆第一次打开的时候问我的第一句话就是"这些事是你要我帮忙办的？"——乌龙。
处理方式也很简单：要么让 AI 把示例数据改成更明显的"示例"样式，要么在引导语里写一句"首次打开看到的几条是示例，点右上角清掉即可"。
第二件：数据不跨设备同步。这是特性，不是 bug——但你必须知道怎么验证它。
我特意做了个实验，并且第一次差点把自己骗了：
- 第一次验证：我在设备 A 添加了一条待办，然后开一个全新浏览器（模拟设备 B）打开链接，看列表条数——条数一样！我心里咯噔一下：难道同步了？
- 冷静 10 秒后意识到问题：两边显示的条数一致，很可能是因为内置示例就是 9 条，我在 A 加的那条如果被 B 看到，条数应该是 10。
- 第二次验证（正确姿势）：在设备 A 添加了一条绝无可能重复的标记待办（"线上验证-8842-只在设备A存在"），设备 B 打开链接搜这个标记——搜不到。实锤：不同步。
这个方法论坑值得单独立牌坊：验证"数据有没有同步"，永远用独一无二的标记文本，不要用条数、不要用常见词。前者排除了示例数据的干扰，后者只能带来虚惊。
跨设备迁移：官方答案就是导出/导入
既然不同步，"换设备"怎么办？答案第 06 篇就埋好了：
- 旧设备：导出
.sqlite - 把这个文件发到新设备（微信传文件、网盘、随便）
- 新设备：打开同一个链接，点"导入还原"，选这个文件
整个过程一分钟，数据完整迁移。换设备是低频操作，一分钟的手动迁移完全可接受——省下的是"数据上云+账号系统+同步逻辑"三座大山，那是要把积分烧穿、还要牺牲"数据不上云"底线的方案。
页面上还自带一行小字声明："数据保存在这台电脑的浏览器里"——它把这个架构的边界，对每个使用者都交代了。这种诚实是加分项。
一个运维的最后审视
上线完，我用老习惯把这个架构从头到尾审了一遍，结论放在这，给同行的读者做个对照：
| 审视项 | 结论 |
|---|---|
| 可用性 | 单静态文件，没有服务端进程，不存在进程崩溃这种故障模式 |
| 数据安全 | 数据在客户端，云端被拖库也拖不到我的待办 |
| 扩展性 | 托管静态文件，访问量大了它比我还扛得住（CDN 在前面） |
| 局限 | 不跨设备同步（已知，可迁移）；浏览器清数据=丢库（所以每周导出备份） |
| 成本 | 0 元。域名 0、服务器 0、证书 0、数据库 0 |
这个架构不高级，但它诚实。每个边界都被明说过，没有隐藏的惊喜。做了八年运维，我对一个系统的最高评价之一就是：没有隐藏的惊喜。
下一篇预告
系列最后一篇，结账。
12 篇的积分总账：总共花了多少免费额度、赚回多少、净额多少。还有让我卡住的 5 个坑、如果重来一次我会改的 3 个决定，以及这个 App 还能往哪长——包括那个我馋了很久但忍住没上，准备留给下一个系列的方向：服务端 SQLite，真正多设备同步。
