免费服务器48小时实测：进程活着，状态悄悄丢了

一场刻意的小型实验

把 webhook 接收器从笔记本搬到免费服务器上跑两天，会发生什么？一位开发者的答案藏在一个矛盾里：进程始终存活，公开路由却报错；重启后服务照常启动，去重台账却不翼而飞。这不是平台故障，而是免费层设计约束的真实暴露。

作者给自己定了三条规则：用免费模型访问跑结构化提取、用免费服务器托管接收器、所有脚本和测试入库以便他人十分钟复现。这种“无伤大雅”的实验设计，恰恰让最无聊的问题最早暴露。

断点一：模型返回的不是 dict，而是一段文本

要求模型输出 JSON，得到的却是一段带前后缀说明文字的被围栏包裹的代码块。json.loads 在第一个字符就失败——这是格式化失败，不是推理失败。

作者的修复思路很务实：先用正则找围栏代码块，回退到原始文本，再取最外层花括号切片解析。二十行代码把两小时的调试压缩成文件。同时维护三个 fixture 文件——裸 JSON、围栏文本、纯散文——让“正常工作”有离线定义，其中纯散文必须抛 ValueError 而非返回半条记录。

这里的洞察在于：模型不是返回 dict 的函数，而是需要契约约束的文本生产者。校验器必须置于模型和写路径之间。

围栏代码块（fenced code block） 是 Markdown 中用三个反引号包裹代码段落的语法，模型在输出 JSON 时常会习惯性地加上它和前后说明文字。解析时不应假设文本以花括号开头，而要先定位围栏边界、提取内部内容，再回退到直接截取最外层花括号之间的子串。

契约校验（contract validation） 指在系统边界处对输入输出做显式的结构与类型断言，例如用 JSON Schema 或 Pydantic 模型验证字段存在性、类型和取值范围。它和业务逻辑分离，失败时抛出明确异常，从而让集成测试可以针对裸 JSON、围栏文本和纯散文分别断言成功与失败，而不是靠肉眼观察日志。

fixture 是测试中预先构造的固定输入样本，通常和测试代码一起入库。本文的三个 fixture 分别代表正常输出、带格式噪声的输出和完全非结构化输出，使“解析器工作正常”有了可离线重复执行的客观定义。

断点二：进程健康，代理找不到它

从实例内部看一切正常：启动日志打印、localhost 请求响应、进程存活。但公网路由报错。问题出在两行代码上——端口硬编码 8000 而非读取 $PORT 环境变量，绑定 127.0.0.1 而非 0.0.0.0。

作者称这是全文最便宜的两个习惯：绑定 0.0.0.0 并读取 $PORT，启动时打印解析后的端口。若只抄一段代码，就抄这段。

反向代理与端口绑定 是理解该断点的关键。免费托管平台通常在前面放一层反向代理，由它把公网域名收到的请求转发到实例内部的某个端口，并设置 PORT 环境变量告诉应用该监听哪个端口。如果应用硬编码监听 8000，而平台分配的是 3000，代理就找不到目标。

127.0.0.1 与 0.0.0.0 的区别 在于绑定地址的范围：前者只接受来自本机回环接口的连接，后者接受来自所有网络接口的连接。容器或虚拟机内部访问 localhost 会成功，但代理从外部发起连接时会被拒绝。因此“实例内 curl 通、公网打不通”几乎总是绑定地址或端口环境变量的问题。

配置回显 指启动时把实际解析到的端口、状态目录、模型标识打印到日志，便于在平台日志面板中直接核对预期值与运行值。

断点三：状态文件是对自己的谎言

最值得警惕的发现：免费服务器给的是运行中的进程，不是持久磁盘。作者把去重台账写在工作目录，默认重启后还在——这种假设会一直等到周五才发作。

他不争辩，直接写了启动审计脚本：首次启动记录 boot_id，追加运行记录并打印。重启前后对比两行输出即可得出结论——boot_id 不变且条目增长，说明磁盘存活；boot_id 改变且条目重置，说明磁盘是实例级临时空间，所有记录已丢失。

这不是 bug 报告，是设计约束。修复路径只有两条：外部存储或改为无状态服务。脚本用 os.replace 实现同文件系统下的原子写入，避免状态文件写一半损坏。

boot_id 是操作系统内核在每次启动时生成的唯一标识，可通过 /proc/sys/kernel/random/boot_id 读取。它跨重启保持不变就意味着磁盘上的数据仍然存在；发生变化则说明实例已经从全新镜像或快照重建，此前写入工作目录的文件全部丢失。

持久磁盘与实例级临时存储 是免费层最容易混淆的两件事：进程存活只证明计算资源在运行，不证明文件系统在重启后仍保留。把去重台账写在当前工作目录，等价于假设实例不会被回收重建，而这一假设在免费层通常不成立。

原子写入 指先写临时文件再通过 os.replace 重命名到目标路径。在同一文件系统内该操作是原子的，可以避免进程在写入中途崩溃时留下半截 JSON，从而让状态文件在任何时刻都是可解析的完整快照。

二十分钟验收清单

作者后悔没在第一小时而非第三十小时做这套检查，因为每步都有无歧义答案，且不依赖更新日志：

1. 绑定检查——实例内 curl 本地端口，再打公网 URL 对比
2. 重启检查——boot_audit.py 前后各跑一次
3. 契约检查——三个 fixture 离线运行，断言纯散文抛错
4. 超时检查——指向故意慢的桩，确认报错而非永久挂起
5. 配置回显——启动时打印端口、状态目录、模型标识
6. 冷启动测量——记录重启后首个请求的时间戳，写下来而不是猜

决策表：什么负载适合白嫖

负载类型	免费模型+免费服务器？	原因
低风险文本转 JSON 分诊，带 schema 校验	可以，保留人工复核队列	格式失误只花几秒，不丢记录
任何绝不能丢写入的场景	暂不——先把状态移出去	启动审计决定，不是营销页决定
严格交互延迟预算	通常不行，先测量	冷启动是 p50 的一部分，不是脚注
受监管或个人数据	读清服务商数据条款后再谈	这个问题别人替不了你

免费层的真实边界

作者最后给出限制：这套流程适合能加校验代码、能读日志的人。需要保证正常运行时间、持久磁盘、固定出口 IP 或签署可用性承诺的场景，免费层就是错误工具，再多的脚本也改变不了。

如果任务需要长链多步推理而非短结构化提取，先用自家 fixture 测免费模型再决定是否建在上面，并准备好放弃。

最锋利的一句是：如果你不能在模型和写路径之间放校验器，那就不要让模型进入写路径。

免费模型和免费服务器足以跑通这两天的循环，启动审计是“足够”可以被量化的原因。在自己的部署上跑一遍，记下数字，让第二个 boot_id 在用户发现之前告诉你真相。