小狐狸与小道士1. 部署前的需求梳理：为什么我选择在飞牛上跑一个“到期提醒”
先说结论：RenewHelper 这类工具解决的是一个特别容易被忽视、但一旦踩中就很疼的问题——你永远不知道自己有多少“数字资产”正在悄悄过期。
玩 NAS 的人多少都有这种经历：域名一年一续，忘记了，结果网站打不开，一查发现被抢注；SSL 证书 90 天有效期，忘记续期，线上服务直接报不安全警告；还有各种订阅服务、云服务器、通配符证书，杂七杂八加起来十几个到期日。靠脑子记不现实，靠手机日历又太散。RenewHelper 的思路很简单：把所有到期时间集中管理，统一通过邮件、飞牛通知、短信、甚至企业微信/钉钉机器人推给你，到期前按天提前预告，到期当天再强调一遍。它的核心价值就是三个字——不遗漏。
为什么跑在 NAS 上？原因很直接：NAS 是 7x24 小时开机的设备，本身就承担着证书续期、域名解析、各类服务托管的工作。飞牛 fnOS 接管了这些场景之后，缺的恰好是一个“到期提醒”的闭环。跑在飞牛上有两个天然优势：一是无需额外买服务器，资源占用极低；二是可以和飞牛现有的 Docker 生态直接打通，后续想挂 Webhook、对接通知中心，都在同一台机器上完成。
适合谁来参考？如果你有一台飞牛 NAS，或者任何一台能跑 Docker 的 Linux 主机，同时你手上有超过 3 个需要在特定日期前处理的事项（证书、域名、订阅、备案等），这篇文章可以直接照着操作。如果你只是听说过“到期提醒”但还没明确需求，看完部署过程，也会对 Docker Compose 的工作方式有更直观的理解。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心设计拆解：RenewHelper 到底是怎么“记住”到期时间的
2.1 数据存储：不依赖数据库，用文件就能搞定的事
RenewHelper 在设计上走的是轻量路线。它没有引入 MySQL、PostgreSQL 这种重型数据库，而是用 SQLite 做本地存储，数据文件就是容器里的一个 .db 文件。这么做的好处非常明显：备份就是拷贝一个文件，迁移就是挂载同一个目录，不需要考虑数据库账号、权限、网络连接这些额外负担。
数据模型也不复杂，核心就一张表，重点字段包括：
- name：条目名称，比如
我的博客域名、阿里云服务器。 - type：条目类型，是证书、域名、还是自定义提醒。
- expire_date：到期日期，精确到天。
- notify_days：提前几天提醒，比如提前 30 天、7 天、1 天各提醒一次。
- remark：备注信息，比如续费链接、账号密码提示等。
这个设计思路很务实。它不追求像 IT 资产管理系统那样面面俱到，而是专注于把“什么时间该干什么事”这一件事做好。对于个人用户来说，复杂度越低，长期使用的意愿就越高。
我补充一个实践细节：如果你的条目数量只有几十个，完全不需要对数据库做任何优化，SQLite 在这种量级下性能绰绰有余。工具的价值不在于管理多少条目，而在于能不能在关键时刻提醒你。
2.2 提醒机制：到期前预告 + 到期日硬提醒，双保险
RenewHelper 的提醒逻辑可以理解为“两次确认”机制。第一轮是到期前预告，比如在到期前 30 天、7 天、3 天分别推送一次；第二轮是到期当天，强制推送一条“今天必须处理”的提醒。
这样做的好处在于，把“紧急感”分成了梯度。提前 30 天的提醒，足够你从容地完成续费流程；提前 7 天的提醒，起到中途加强的作用；到期当天的提醒，则是最后一道防线。
通知渠道方面，RenewHelper 默认支持以下几种：
- 邮件提醒（SMTP）
- 飞牛系统通知（通过 Webhook 接入飞牛 fnOS 的通知中心）
- 钉钉/企业微信/飞书机器人
- Telegram Bot（需要能访问到对应服务）
我自己的使用习惯是：邮件作为主通道，飞牛通知作为保底。因为邮件稳定、不会漏，飞牛通知则能在你打开 NAS 管理界面时直接弹出