自托管经期追踪这件事我前后折腾了小半年。起因很简单我把过去两年的周期记录从某个手机应用里导出时发现导出的 CSV 少了三列我当初填得很认真的症状标签而且客服给的回复是历史字段已下线。那一刻我才意识到健康数据放在别人服务器上能不能取回、能取回多少决定权不在我手里。后来我搭了一套跑在自己机器上的经期追踪服务项目代号叫 Ovumcy思路就一句话数据不上云完全自主掌控。这套东西能干什么记录每日的身体状态和经期起止、按历史数据推算下次周期和易孕窗口、用日历视图回看趋势、随时把全量数据导成明文文件。它解决的不是功能比商业应用更强的问题——恰恰相反功能上它朴素得多——它解决的是数据归属问题谁拥有这些记录、谁能看、能存多久、什么时候删。适合看这篇的人大概分两类一类是有基本运维能力、愿意花一个周末把服务跑起来的人另一类是暂时不打算自己搭但想搞清楚自托管健康数据到底意味着什么代价的人。1. 为什么我把周期记录搬回自家机器1.1 云端健康数据的三个真实顾虑第一个顾虑是数据的生命周期不可控。你在应用里点删除账号通常只删掉了主库里的行备份快照、日志、分析仓库里的副本往往还在什么时候清、清到什么程度用户看不到也验证不了。健康类数据尤其麻烦它不像购物记录删了顶多推荐不准它的敏感度决定了残留本身就是风险。第二个顾虑是用途边界会漂移。任何一款应用的用户协议都不是一成不变的版本更新时大多数人点同意就过去了。今天它只做记录明天可能接入了广告归因、健康分析合作方或者把聚合数据卖给研究机构。这些变化在协议里写得清清楚楚但没人会逐版对比。自托管的好处在于这个边界由你自己划而且没有第三方能单方面改动它。第三个顾虑是单点故障。账号被盗、服务商跑路、区域服务下线这些事概率不高但一旦发生你损失的不是钱是几年积累的连续记录——而周期数据恰恰是连续才有价值的典型断三个月预测精度直接崩。所以我要的不只是能存,而是我能把它拷走、能自己恢复。1.2 自托管换来的三样东西和失去的三样东西很多人写自托管只讲好处我觉得不实在。先把取舍摊开说。维度自托管得到自托管失去数据主权数据文件在自己磁盘上随时可导出、可销毁没有厂商帮你做异地多活可审计代码、依赖、网络请求全部可见可查需要你自己判断依赖是否可信定制自由想加字段就加字段想改算法就改算法没有产品团队替你打磨交互可用性不依赖任何第三方服务状态停电、硬盘坏、误删都得自己扛跨端体验浏览器访问任何设备都能开没有原生小组件、没有系统级提醒维护成本一次性投入为主定期打补丁、做备份、看日志我自己的结论是如果你只想随手记一下商业应用更省事如果你把这份记录当成需要保管五到十年的个人档案那自托管的账算得过来。因为它本质上不是应用是你自己的数据库加一个薄薄的界面。1.3 一个够用就好的功能边界我在设计时做过一次很克制的裁剪明确列出不做的清单不做社交分享不做社区内容不做消息推送营销不做多租户 SaaS不做第三方数据上报不做埋点统计。这些砍掉之后整个服务的复杂度掉了一个数量级——没有消息队列没有缓存集群没有对象存储一个容器加一个数据目录就完事了。保留的核心只有四块日历视图看周期分布、每日记录流量、症状、体温、备注、预测引擎下次经期、易孕窗口、置信度、导入导出CSV 与全量备份。这四块里真正有技术含量的是预测引擎和备份恢复其余都是常规增删改查。所以后面几章我会把重点放在算法参数、数据建模、部署与恢复演练上界面部分不展开。2. 架构与选型把复杂度压到最低2.1 单机单容器为什么不做微服务这套服务的真实负载是什么量级一个用户一天最多写三条记录一年一千条上下读取集中在早上和晚上各几分钟。峰值并发是 1不是 1000。在这种量级下引入微服务、消息队列、服务发现属于典型的负资产——它不会提升任何指标只会增加故障面和维护时间。所以我选的是单进程单体一个应用容器内含 HTTP 服务、模板渲染、定时任务每日数据校验与备份触发一个持久化目录挂载到宿主机前面放一层轻量网关做 TLS 终止和请求转发。整个部署就是一条启动命令加一个配置文件。这里有个容易被忽略的细节单体不等于没有分层。我在代码里仍然分了四层——路由层、业务层、存储层、算法层只是它们跑在同一个进程里。好处是将来真要多用户把存储层换掉、把会话改掉就能横向扩坏处是边界靠自觉维持容易写着写着就耦合。我的做法是强制算法层纯函数化输入一个周期数组输出预测结果不碰数据库、不碰时间以外的全局状态。这样算法可以单独跑测试也方便你按自己的理解替换。2.2 数据存在哪、怎么存存储选型上我对比过两类方案结论对个人规模非常明确。对比项单文件嵌入式数据库独立数据库服务部署复杂度随应用启动零额外进程需单独容器、端口、账号、初始化备份方式单文件快照或在线导出语句需逻辑备份工具或物理备份事务能力单写者读多写少场景足够强支持高并发写数据量上限几 GB 级别无压力本例一年不到 1MB无实际上限迁移成本拷文件即迁移需导数据、改连接串主要风险误删、磁盘损坏、并发写锁配置错误、版本升级不兼容我选单文件方案核心理由是备份即复制。这句话听起来朴素但它决定了灾难恢复的可行性你半夜出事最不想面对的就是先装一个数据库服务、再想办法把 dump 导进去这种流程。单文件的话把备份文件放回目录、改个权限、重启容器五分钟能恢复。代价也要说清楚单写者模型下长时间写事务会阻塞其他写请求所以我把所有写操作控制在毫秒级批量导入用事务包装但限制单批条数另外开启预写日志模式让读写不互相阻塞同时接受断电可能丢最后一条未落盘记录这个微小风险——对日记类数据完全可接受。2.3 加密边界划在哪里这是自托管健康数据最值得想清楚的一节。加密不是全都加就好加错位置会让系统变得既不好用也不更安全。我把它分成三层来看传输层。外部访问一律走 TLS禁止明文端口对外。内部如果只有单机通信不必再加一层加密那是自我安慰。静态存储层。我用的是宿主机全盘加密加备份文件加密。全盘加密解决硬盘被物理拿走这个场景成本几乎为零收益很实在。备份文件用对称加密AES-256-GCM 这类密码单独记在你脑子或离线密码本里不放在同一台机器上——否则备份和钥匙一起丢等于没加密。应用层字段加密。这个要慎重。把备注、症状这些字段在入库前单独加密好处是即使数据库文件泄露也读不到明文坏处有三个一是搜索和排序彻底失效你没法按关键词查找所有记录二是密钥管理水平瞬间提高密钥丢失等于数据永久报废三是迁移和调试成本陡增。我的判断是单用户、单机、已经全盘加密的前提下应用层字段加密的边际收益不高反而显著抬高运维门槛。所以默认关闭。如果你确实要开我建议只加密两个字段自由文本备注、体温之外的隐私标签。结构化字段日期、流量等级保持明文这样统计和预测还能跑。这是一条经验加密的粒度应该跟着使用方式走不是跟着敏感程度走。所有字段都加密的系统最后往往因为不能查询而被用户放弃。2.4 技术栈对照表选型上我没有追求时髦原则是五年后我还能看懂并修得动。位置选择选择的理由被否决的方案后端语言主流服务端语言单二进制或成熟运行时生态全、容器体积可控、调试工具成熟小众语言五年后可能找不到维护者模板渲染服务端渲染无前端构建链改一行刷新即见效单页应用构建链路维护成本高前端交互少量原生脚本页面只有日历和表单无需框架重型前端框架引入打包与版本升级负担存储单文件嵌入式数据库备份即复制独立数据库服务运维成本不匹配规模对外入口轻量网关做 TLS 与转发证书管理集中应用不碰证书应用直接监听公网端口证书自动签发与续期避免忘记续期导致中断手动上传证书文件备份定时导出加密快照可离线验证直接拷贝运行中数据文件这套组合的总体积可以压到几十 MB内存占用几十 MB 量级一台最低配的云主机或家里的旧笔记本都能跑。3. 核心周期预测怎么算才不瞎猜3.1 加权平均周期别用简单平均大部分简易实现用的是所有历史周期长度的算术平均。这个做法有个明显缺陷三年前一段不规律时期的数据会持续拉偏预测而最近几个月的变化反而被稀释。人的周期会随年龄、作息、体重、季节变化而缓慢漂移越近的数据权重应该越高。我用的是指数衰减加权平均。设最近 N 次完整周期从一次经期开始日到下一次开始日的天数为 c₁, c₂, …, c_N按时间从远到近排列权重定义为wᵢ λ^(N−i)其中 λ 取 0.8预测周期长度L̂ Σ(wᵢ · cᵢ) / Σ(wᵢ)拿一组具体数字算一遍。假设最近 6 次周期依次是 30、28、31、27、29、26 天从远到近。λ0.8 时权重依次为0.8⁵ 0.32770.8⁴ 0.40960.8³ 0.51200.8² 0.64000.8¹ 0.80000.8⁰ 1.0000权重和 3.6893。加权和 30×0.3277 28×0.4096 31×0.5120 27×0.6400 29×0.8000 26×1.0000 9.831 11.469 15.872 17.280 23.200 26.000 103.652。L̂ ≈ 28.1 天。简单平均是多少(302831272926)/6 28.5 天。差了 0.4 天——看着不大但这是在没有明显趋势的情况下。如果最近三个月周期从 30 天缩到 26 天简单平均会给出 28 天以上而加权平均会明显往 26 靠。预测日差一天对提前准备这件事的实际体验影响是很大的。λ 的取值是一个可调参数λ 越小对近期变化越敏感但也越容易被偶发的异常周期带偏我的默认值是 0.8等于把最近一次周期的权重设为最远一次的三倍左右。如果你记录得很规律可以调到 0.9 让曲线更平滑如果你正处于周期波动期产后、停药后调到 0.7 会更贴合。3.2 黄体期恒定假设与易孕窗口估算预测下次经期开始日很简单最近一次经期开始日 L̂四舍五入到天。排卵窗口的估算要复杂一些业界通用的是一个简化模型假设黄体期长度相对恒定约 14 天个体差异通常在 12–16 天之间那么排卵日约等于下次经期预计开始日 − 14。围绕排卵日往前推 5 天、往后推 1 天得到所谓易孕窗口共 7 天。这个模型的局限必须讲明白否则会误导人黄体期恒定只是近似。同一个体不同周期之间也有一两天波动用固定 14 天会引入误差。它只能给出统计意义上的窗口不能用于避孕决策。这是我在界面上专门加了一行提示的原因——算法预测和医学判断是两件事。周期不规律时窗口会失去意义。如果历史周期标准差超过 4 天窗口宽度可能要拉到 10 天以上这时候窗口这个词本身就是误导。所以我在实现里做了一件事把窗口宽度和置信度绑定。窗口不是固定的 ±5/1而是随标准差扩张标准差 1.5 天窗口 排卵日 −5 到 1标准差 1.5–3 天窗口 排卵日 −6 到 2标准差 3–4 天窗口 排卵日 −7 到 3标准差 4 天不显示窗口只显示数据波动较大暂不给出窗口估算3.3 置信度分级什么时候该拒绝预测这是我认为比算法本身更重要的一节。一个不负责任的追踪工具会在只有两条记录时也给你一个斩钉截铁的预测日。我的原则是数据不足就不预测波动过大就降级提示。先算标准差。用加权平均算出的 L̂再算加权标准差 σσ sqrt( Σ(wᵢ · (cᵢ − L̂)²) / Σ(wᵢ) )分级规则我用一张表固定下来避免每次凭感觉条件置信度界面表现完整周期数 2不预测提示至少需要 2 个完整周期完整周期数 2–3 且 σ ≤ 2低显示预测区间而非单日完整周期数 ≥ 4 且 σ ≤ 1.5高显示预测日 窗口完整周期数 ≥ 4 且 1.5 σ ≤ 4中显示预测区间±σ 取整σ 4不预测提示波动较大建议补录数据距上次开始日超过 90 天不预测提示数据可能中断需确认还有两个特殊场景要处理剔除异常值和处理中断。异常值方面如果有一次周期长度超过 L̂ 的 2 倍或短于一半多半是漏记导致的把两次经期记成了一次或中间补录错位我会把它标记为可疑并在计算中降权而不是静默使用。中断方面如果相邻两次记录间隔超过 90 天中间那段大概率是没记我直接断开这个周期不参与平均——否则会算出一个 100 多天的周期把后续预测全带偏。3.4 数据表结构与索引设计数据模型我改过三版最终落成四张表。核心思路是周期是派生数据日志是原始数据。不要手动维护周期表让它由日志推导出来否则两者一定打架。-- 用户表单用户场景也保留方便将来加家庭成员 CREATE TABLE users ( id INTEGER PRIMARY KEY, username TEXT NOT NULL UNIQUE, password_hash TEXT NOT NULL, -- 强哈希含盐 created_at TEXT NOT NULL, tz TEXT NOT NULL DEFAULT Asia/Shanghai ); -- 每日日志一天一条date 用本地日期字符串不用时间戳 CREATE TABLE daily_logs ( user_id INTEGER NOT NULL, log_date TEXT NOT NULL, -- 格式 YYYY-MM-DD flow INTEGER DEFAULT 0, -- 0 无 / 1 点滴 / 2 少 / 3 中 / 4 多 is_start INTEGER DEFAULT 0, -- 是否经期首日人工确认 symptoms TEXT, -- JSON 数组标签集合 temperature REAL, -- 基础体温摄氏度 note TEXT, -- 自由文本 updated_at TEXT NOT NULL, PRIMARY KEY (user_id, log_date) ); -- 派生周期表可随时由 daily_logs 重建 CREATE TABLE cycles ( user_id INTEGER NOT NULL, start_date TEXT NOT NULL, end_date TEXT, length INTEGER, -- 到下一次 start 的天数 excluded INTEGER DEFAULT 0, -- 标记异常不参与计算 PRIMARY KEY (user_id, start_date) ); CREATE INDEX idx_logs_date ON daily_logs (user_id, log_date DESC); CREATE INDEX idx_cycles_start ON cycles (user_id, start_date DESC);几个关键决策值得解释。日期用文本存 YYYY-MM-DD不用时间戳。这是踩过坑之后改的早期我用时间戳结果服务器在 UTC、用户在 UTC8晚上 11 点记的今天存进去变成昨天日历视图整体错位一天。改成用户本地日历日的文本之后这个问题从根上消失了。代价是不能直接做跨时区的时刻运算——但周期记录根本不需要时刻只需要哪一天。is_start 由人工确认不靠算法猜。最开始我尝试用流量值自动判断经期首日比如流量从 0 变正数即为首日结果点滴出血、非经期出血、漏记都会造成误判。后来改成算法给一个建议起点用户点一下确认。多一次点击换来的是整条数据链可靠。cycles 表是缓存不是真相。任何一次日志修改都会触发该用户从最近三个月开始重算周期然后覆盖 cycles 表。这样即使手工改错了删掉 cycles 表数据再重算就能修回来。4. 部署实操从零把服务跑起来4.1 主机与环境准备主机要求不高1 核 1G 足够磁盘留 10G 给数据和备份。系统选长期支持版本别追新。真正需要注意的是三件事。第一磁盘加密。云主机多数支持在创建时开启全盘加密家里的小机器则建议用系统自带的加密卷功能。这一步在创建时做事后补做很麻烦。第二时间同步。预测依赖日期日期依赖时钟。如果时钟漂移日志日期会错。开系统自带的时间同步服务即可但要确认它真的在跑——我见过容器里时钟偏移十几分钟导致备份文件名重复覆盖的情况。第三用户与权限。不要用管理员账号跑服务。新建一个专用系统用户数据目录归它所有权限设成 700。容器里也指定非 root 用户运行映射宿主机的 UID避免挂载目录出现属主错乱。4.2 配置项逐条解析配置文件我用了 YAML 加环境变量覆盖的方式敏感项只从环境变量读。server: listen: 0.0.0.0:8080 base_url: https://your-domain.example session_timeout_minutes: 480 max_login_attempts: 5 lockout_minutes: 30 storage: data_dir: /app/data db_file: ovumcy.db wal_mode: true busy_timeout_ms: 5000 prediction: lambda: 0.8 min_cycles_for_prediction: 2 luteal_phase_days: 14 max_gap_days: 90 outlier_ratio: 2.0 backup: enabled: true schedule: 0 3 * * * keep_daily: 7 keep_weekly: 4 target_dir: /app/data/backups encrypt: true privacy: log_level: warn log_request_body: false anonymize_client_ip: true逐条说几个容易被忽略的。base_url必须填对外真实地址。登录跳转、导出链接都依赖它填错会导致登录后被踢回登录页——这个坑我蹲了半小时才反应过来因为日志里一切正常。busy_timeout_ms是单文件数据库的关键参数。写冲突时如果立刻报错用户体验就是点击保存没反应。设成 5000 毫秒冲突时排队而不是失败。太小会报错太大则会挂起5 秒是个合理值。max_gap_days: 90决定什么时候断开周期链。数值越大越宽容但会把长期未记录导致的虚假周期算进去。90 天覆盖了绝大多数正常周期波动又不至于把半年的空窗当成一个周期。log_request_body: false和anonymize_client_ip: true属于隐私项。默认关闭请求体日志因为表单里可能有备注文本落进日志就等于明文存了一份。客户端 IP 做截断或哈希方便排查异常登录又不留完整地址。密钥这样生成和注入不要把密钥写进配置文件# 生成 32 字节随机密钥输出 base64 head -c 32 /dev/urandom | base64 # 写入仅当前用户可读的环境文件 umask 077 cat /etc/period-tracker.env EOF APP_SECRET_KEY上一步的输出 BACKUP_ENCRYPT_KEY另一个独立生成的密钥 EOF这里有一条硬规矩应用密钥和备份加密密钥必须是两个不同的值。共用一把钥匙意味着备份文件泄露的同时应用也被攻破分开之后至少还有一道门槛。两个密钥都要在离线介质上留一份我用的是一张纸加一个离线密码本听起来很原始但它不会因为硬盘坏而消失。启动命令大致长这样容器运行时 run -d \ --name period-tracker \ --restart unless-stopped \ --user 1000:1000 \ -p 127.0.0.1:8080:8080 \ --env-file /etc/period-tracker.env \ -v /srv/period-tracker/data:/app/data \ 你的镜像地址注意-p 127.0.0.1:8080:8080前面的那个127.0.0.1。这是一个安全细节只把端口绑在回环地址上外网无法直连必须经过前置网关。很多人写-p 8080:8080等于把应用裸奔在公网上后面的 TLS 和认证全白做。4.3 对外入口与证书对外只开两个端口80 用于跳转和证书验证443 用于正式服务。前置网关负责三件事TLS 终止、请求转发到本机 8080、加几个安全响应头。# 前置网关的站点配置片段字段名按你用的组件调整 server: listen: 443 ssl http2 server_name: your-domain.example ssl_certificate: /etc/certs/fullchain.pem ssl_certificate_key: /etc/certs/privkey.pem ssl_protocols: TLSv1.2 TLSv1.3 add_header Strict-Transport-Security max-age31536000 always; add_header X-Content-Type-Options nosniff always; add_header X-Frame-Options DENY always; add_header Referrer-Policy no-referrer always; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 8m; }X-Frame-Options: DENY防的是点击劫持Referrer-Policy: no-referrer防的是从外部链接跳进来时把路径泄露出去——路径里可能有记录 ID这也算隐私。证书用自动签发与续期别手动传。手动传的证书一定会忘忘了一定会过期过期那天你正好想记录。续期任务要验证真的能跑通我习惯在部署完立刻手动触发一次续期演练确认流程通畅。4.4 首次启动验证与冒烟测试容器起来不代表服务可用我固定跑一套五分钟的检查。第一步看日志有没有报错第二步访问健康检查端点第三步走完整注册登录第四步写一条今天的记录并刷新页面确保持久化第五步导出一次数据看文件能否打开。这五步里最容易出问题的是第四步——写进去了但刷新就没了通常是数据目录权限不对容器写的其实是临时层重启即丢。# 检查数据是否真的落在宿主机上 ls -l /srv/period-tracker/data/ # 应该看到数据库文件与 -wal / -shm 附属文件 # 检查容器内的写入用户 容器运行时 exec period-tracker id # 健康检查 curl -sS -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/healthz还有一个细节-wal和-shm文件存在是正常的说明预写日志模式在工作。备份的时候不能只拷主库文件否则可能丢最近的事务。正确做法是用数据库自带的在线导出语句或者先做一次检查点再复制。4.5 备份与恢复演练备份不做恢复演练等于没备份。我的策略是每天凌晨全量加密快照保留 7 份日备、4 份周备且每周把一份快照同步到另一台机器或外部介质上。# 在线导出生成一致性快照不锁库 容器运行时 exec period-tracker sh -c \ db-cli $DATA_DIR/ovumcy.db VACUUM INTO \/app/data/backups/snap-$(date %F).db\ # 加密压缩 tar -czf - -C /srv/period-tracker/data/backups snap-$(date %F).db \ | openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt \ -pass file:/etc/backup-pass \ -out /srv/backups/period-$(date %F).tar.gz.enc # 校验能否解密并解包关键一步别省 openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 \ -pass file:/etc/backup-pass \ -in /srv/backups/period-$(date %F).tar.gz.enc \ | tar -tzf - /dev/null echo 备份可解密可解包恢复流程要写下来贴在旁边因为真出事的时候人是慌的停容器、把当前数据目录改名留档、解出备份文件放进数据目录、修正属主、启容器、登录核对最近七天的记录条数和日期。核对条数这一步别偷懒我就遇到过一次备份文件是空的——定时任务跑在一个没有正确挂载数据目录的临时容器里导出的快照只有表结构没有数据直到两个月后演练才发现。5. 安全加固清单自托管最容易漏的几处5.1 暴露面收敛自托管服务被攻破九成不是因为代码有漏洞而是因为暴露了不该暴露的东西。所以第一件事是数清楚你到底开了几个端口。必要的只有 443 和 80。SSH 只允许密钥登录、禁用密码、限制来源地址或改到非默认端口。数据库端口绝不对外容器网络内部通信即可。管理后台如果有独立端口也不对外。再进一步如果你的访问来源相对固定比如只在自己家和公司网络用可以在防火墙上做来源白名单。这条能挡掉绝大部分自动化扫描。移动场景下网络会变那就退一步至少把登录失败锁定、双因素认证打开。加固项做法不做会怎样端口收敛仅 443/80 对外应用端口绑回环应用被直接访问绕过网关与证书SSH密钥登录、禁用密码、限制来源被暴力破解获得系统权限数据库不对外、仅本机套接字数据被直接拖走管理路径改默认路径或加来源限制被扫描器命中登录防护失败锁定 双因素弱密码被撞库依赖更新每月检查一次安全公告已知漏洞长期暴露5.2 认证与会话单用户场景很容易把认证做得敷衍比如一个写死的密码、一个永不过期的会话。这在公网环境里等于没有认证。我的做法是密码用强哈希加盐存储内存开销参数调到能接受的程度会话用随机生成的令牌存服务端有效期 8 小时滚动续期但设绝对上限登出时服务端删除会话不只是删客户端 cookie。登录失败计数按用户名加来源 IP 组合统计连续 5 次锁定 30 分钟——锁定时长别设太长否则自己输错三次就被关在门外我吃过这个亏。双因素认证如果实现务必提供一次性恢复码并且恢复码要能离线保存。否则手机丢了等于账号永久锁死这时候你只能去改数据库而改数据库又是另一个风险点。5.3 日志的隐私边界日志是隐私泄露的重灾区。默认配置下网关会记录完整请求路径、来源地址、User-Agent。路径里可能带记录 ID来源地址能定位到人这些都不该长期保留。我的配置是日志级别设 warn不记请求体来源地址做截断或哈希保留期 7 天超期自动清理错误日志里如果带了用户输入脱敏后再写。另外应用自身的业务日志不要记录任何具体的健康数据——用户 1 更新了 2024-06-01 的记录这种可以流量4症状腹痛这种不行。再补一条容易被忘的容器标准输出也是日志。如果你用容器日志收集记得给容器设日志轮转上限否则一年后一个几十 GB 的日志文件躺在磁盘上里面还可能有敏感片段。6. 常见问题与排查实录6.1 容器起来就退出日志里只有一行最典型的三种原因。第一数据目录权限不对应用无法创建数据库文件启动即失败。表现为日志里出现unable to open database file之类。解决确认宿主机目录属主与容器内运行用户 UID 一致。第二环境变量缺失。密钥没注入或者变量名拼错应用在启动时校验失败直接退出。这类问题日志通常会明确指出缺哪个变量但如果你把日志级别调得太低可能什么都看不到——排查时临时把级别调到 info。第三端口冲突。宿主机上已经有别的服务占了 8080。这时候容器可能不会退出而是启动失败重试--restart unless-stopped会导致它反复重启看起来像起来了又挂了。排查顺序我固定为看日志 → 看退出码 → 看挂载 → 看端口。退出码 1 一般是配置或权限137 是被强制终止多半内存不足143 是正常收到终止信号。6.2 时区与跨日边界导致的记录错位症状是晚上十一点半记的今天第二天看日历标在了前一天。原因前面提过——用了时间戳并做了时区转换。修复分两步。第一步把日期字段改成本地日历日文本写入时由前端或服务端按用户配置的时区直接算出 YYYY-MM-DD不做 UTC 转换。第二步历史数据迁移时按原记录的时区重新计算日期别直接截取 UTC 日期的前 10 位——那样会把一批记录整体前移或后移一天。迁移脚本要先在副本上跑比对迁移前后的记录条数和日期分布。我当时的做法是导出两份 CSV用 diff 比对确认差异全部落在预期的边界时段内才敢在正式库上执行。6.3 预测结果和手机应用差一天差一天非常常见原因通常有三个按概率排序。一是算法不同。商业应用多用简单平均或固定周期我这边是加权平均最近几次周期的权重更高如果最近周期偏短预测就会提前一天。这不代表谁错了只是模型不同。二是从哪天开始算的定义不同。有的应用把经期首日定义为流量达到某个等级的第一天有的定义为用户手动标记的那天。我这边是人工确认所以如果你的实际首日和标记日差一天整条链都会差一天。三是取整方式不同。加权平均算出 28.4 天向下取整是 28四舍五入是 28但四舍五入 28.6 就变 29。我用的是四舍五入到最近整数然后加在最近一次首日上。如果你想对齐可以在配置里把取整方式改成固定值代价是长期看会有累积偏差。6.4 备份能恢复但数据不对这个坑最阴险因为能恢复会给你虚假的安全感。我遇到过三种情况。第一种备份的是表结构不是数据。原因是用了一个空的临时容器执行导出挂载路径没对上。检查方法解开备份后直接查记录数不要只看文件大小。第二种恢复了旧版本但没做数据迁移。应用启动时如果版本号高于数据库版本会执行迁移如果跳过了迁移直接读字段缺失会导致部分数据被默认值填充。解决恢复后必须用同版本启动让它跑完迁移。第三种只恢复了主库文件没恢复预写日志。这种情况下最近几条事务丢失。所以恢复一定要用完整快照而不是直接拷运行中的主库文件。6.5 常见问题速查表现象最可能原因快速处置容器反复重启端口冲突或权限错误看退出码检查挂载目录属主页面能开但登录后跳回登录页base_url 配错改成对外真实地址保存后刷新数据消失数据目录没挂载到宿主机检查挂载路径与写权限日历整体偏移一天时区处理错误日期改存本地日历日预测一直提示数据不足周期未被识别为完整周期检查 is_start 标记与间隔备份文件很小导出时库为空或路径错解开后查记录数验证证书到期告警自动续期未生效手动触发续期并查日志磁盘持续增长日志无轮转设置容器日志上限与清理策略记录写入偶发失败数据库写锁等待超时调大 busy_timeout缩短事务导出 CSV 中文乱码编码不是 UTF-8导出时指定 UTF-8 并加 BOM7. 尾声几条只有跑过一段时间才明白的经验第一自托管的真正成本不在搭建在维护。搭一次一个周末维护是每月半小时乘以好几年。如果你算不清这笔账不如先用商业应用等哪天真的觉得数据需要自己保管了再动手。第二备份的价值在恢复演练不在备份本身。我建议每季度挑一个周末真的把备份恢复到另一台机器上登录进去翻一翻最近的记录。演练过三次之后你会对自己的方案有完全不同的信心。第三功能越少活得越久。我最初还想过加图表分析、加多设备同步、加提醒推送全部砍掉之后这套东西反而一直在跑。一个人维护的项目最大的敌人不是需求不够是需求太多。第四别把预测当结论。算法给的是基于历史数据的统计估计它不知道你这个月出差熬夜、也不知道你换了药。界面上那句仅供参考不是免责声明是实话。如果后面还要扩展我会优先做两件小事一是把导出格式做成通用的日历事件格式方便导入其他工具二是加一个数据健康度面板直观告诉你哪些月份记录缺失、哪些周期被标记为异常。这两个功能都不增加隐私风险但实实在在提升长期可用性。至于多用户、移动端原生应用这些等真有人需要再说。