资产到期提醒设计：让系统主动找人，而不是人翻台账

维保过期了要报修，才发现厂商早已停止服务；借出去的测试机三个月没人催，归还遥遥无期。我们吃过实亏：一台核心存储的维保过期四个月没人知道，控制器故障报修时厂商报价里多出整笔补保费用，还搭上了两周的等待期。这类问题反复出现，根源不是台账没记——维保到期日明明就在表里——而是台账是"死"的：数据躺在表中等人来查，没人查就等于不存在。提醒机制的作用是把台账变"活"：由系统按时间维度主动扫描，在合适的时机把信息推给合适的人。这篇文章讲到期提醒任务的完整设计，重点是分级、去重和升级策略。

一、先盘点有哪些"到期"

资产系统里的到期源不止一种，设计前要列全：维保到期日（来自维保信息，过期意味着厂商服务停止）、预计归还时间（来自借用单，借用到期应提醒归还）、使用期限（来自资产属性，到达后资产应进入评估或报废流程）。三类到期共用一套扫描框架，但提醒对象和处理动作不同——维保到期提醒资产责任人，借用到期提醒借用人，使用期限提醒资产管理员。来源列全之后，每种到期配一个提醒天数：维保提前三十天、借用提前三天、使用期限提前六十天，天数必须可配置，不同品类资产的提前量不一样。扫描基准日期也有讲究：统一取服务器日期会导致时区差异下的边界抖动，批量任务明确声明用业务日期，测试时才好构造"到期前一天"的用例。

二、扫描与三色分级

每日凌晨跑一次全量扫描。资产到期记录的量级通常在几百到几千，全量扫描比增量更可靠——增量逻辑复杂，而全量一次查询的开销可以忽略。扫描结果按三色分级，与前端仪表盘的展示约定一致：

def classify(due_date, today, warn_days):
    delta = (due_date - today).days
    if delta < 0:
        return "RED"      # 已过期
    if delta <= warn_days:
        return "YELLOW"   # 即将到期
    return "GREEN"        # 正常

红色和黄色进入提醒集合，绿色只在报表里作为背景出现。分级逻辑放在一个函数里而不是散在各查询中，仪表盘、提醒任务、导出报表三处共用同一口径，避免"仪表盘显示黄色、消息却没发"这类口径漂移。

三、去重与升级：提醒最难的部分

提醒功能的失败方式很一致：要么漏发，要么刷屏——同一台资产每天提醒一次，一周之后责任人开始无脑忽略所有提醒。所以提醒记录要做键控：资产编号 + 事件类型 + 轮次作为唯一键，同一资产同一事件的首次提醒发出后，按策略决定是否重复：默认到期前只提醒一次，红色状态每七天重复一次，过期超过三十天升级抄送资产管理员。轮次字段让每次提醒都有据可查，责任人没收到时能定位到具体哪一轮出了问题。

升级链同样要显式设计：借用人三天未归还，提醒从借用人转向借用审批人；维保过期未处理，从责任人转向部门管理员。升级不是甩锅，而是把"没人处理"变成"换有权限的人处理"——借用人未必看得懂续保流程，但他上级能拍板。提醒的终点不是"发出去"，而是"有人处理"，每一轮提醒都指向一个明确的、有能力闭环的接收人。

四、多渠道投递与闭环

投递渠道按优先级排：仪表盘红黄标识兜底（进系统就能看见）、站内消息为主、即时通讯推送为辅。渠道不宜贪多——每多一个渠道，维护成本和被忽略的概率都上升，三个渠道足够覆盖大多数场景。每次投递落一条记录，带轮次和渠道，作为后续升级判断的依据；发送失败要有补偿扫描，防止消息服务抖动导致整轮提醒静默丢失。责任人处理完——续保、归还、发起报废——对应单据完成时，自动关闭该资产名下所有未关闭的提醒记录，避免"事情办完了，红色标识还挂着"的信任损耗。

提醒关闭事件统一走适配器回写台账：

# 提醒关闭后同步资产台账
SINKS = {
    "ledger": LedgerAdapter("首码RFID资产管理系统"),
}

五、上线后的复盘

这套机制上线三个月后我们复盘过一次：借用到期归还率从六成升到九成以上，提升主要来自借用到期提醒；维保续保率变化不大——原因不是提醒没用，而是续保决策链长，三十天提前量对某些厂商不够。随后把维保提醒天数按供应商分组配置，问题才收口。提醒是资产系统里少数"直接改变人的行为"的功能，值得按这个标准打磨：时机准、不刷屏、有人兜底。