月底续月为什么会漂移：用Python保住日期计算的原始锚点

比较订阅或续费方案时，金额算对了，还要核对新的到期日期。上一次写零现金报价比较器时，我要求输入实际增加的天数，而不是把一个月固定当成30天。接下来就有一个具体问题：如果需要先做本地日历预估，怎样避免连续加月时丢失原始日期？

这次实验只处理合成日期，不连接云平台，不读取账号或订单，不代表任何云服务的计费实现。程序定义的是一种明确的“固定原始日号，目标月份不存在该日时取当月最后一天”策略。真实续费仍应以平台条款、结算页面和支付后读回的实际到期日为准。

1. 同一个起点，分两次算可能差三天

先选一个容易暴露问题的日期：2027年1月31日。按照上述策略，加一个月只能得到2月28日。如果把这个临时结果直接当作下一次的基准，再加一个月就成了3月28日。可是从原始1月31日直接计算两个月后，3月存在31日，结果应为3月31日。

这两个结果都可能来自没有语法错误的代码，区别在于第二步还记不记得最初的31日。第一次截断到28日时，原始日号的信息已经不能从结果中完整恢复。只存“上次计算的日期”，不足以表达“每月尽量在原始31日”的业务意图。

因此问题不宜简单描述成“日期库算错了”。链式计算采用的是逐次截断策略；固定锚点采用的是从原始日期累计偏移策略。两者可以各自合理，但必须在需求、数据结构和测试里保持一致。本文选择后者，不把它说成所有订阅系统都必须采用的规则。

2. 先写出输入和输出的约定

函数接收两个参数：原始锚点anchor，以及从锚点累计向后移动的月份offset。offset=0应返回原始日期。offset=2始终表示原始锚点之后两个月，不能把它理解成“在任意上次结果上再前进两个月”。

本例刻意只接收普通datetime.date，不接收datetime.datetime，也不自动解析字符串。这样可以防止上层把带时区的精确时刻传进来后，程序悄悄丢掉小时、时区或夏令时信息。这里的输出是日历上的日期，不是某个地区的23:59:59，也不是承诺能够精确覆盖多少秒。

月份要求是非负整数，同时拒绝True和False。Python里bool是int的子类，如果只写isinstance(offset, int)，True可能被当作一个月。用于人工录入、JSON解析或表格转换的边界代码，应明确这种输入是否有意义，而不是默默接受。

最后，datetime.date的年份上限是9999。遇到超出范围的目标年份，本例直接抛出ValueError，不把它钳制回9999年，也不返回一个看似有效但含义错误的日期。

3. 把年份和月份映射为连续的月份编号

实现不需要第三方依赖。先把原始年份和月份映射为从公元1年1月开始的零基月份编号，加上累计偏移，再用divmod恢复目标年月。最后通过calendar.monthrange取得目标月份的天数，日号取原始日号与目标月最后一天中较小的值。

from datetime import date
from calendar import monthrange


def month_date(anchor: date, offset: int) -> date:
    if type(anchor) is not date:
        raise ValueError('anchor must be a plain date')
    if type(offset) is not int or offset < 0:
        raise ValueError('offset must be a nonnegative integer')
    month_index = (anchor.year - 1) * 12 + anchor.month - 1 + offset
    year_index, month_index = divmod(month_index, 12)
    year, month = year_index + 1, month_index + 1
    if year > 9999:
        raise ValueError('target year exceeds9999')
    last_day = monthrange(year, month)[1]
    return date(year, month, min(anchor.day, last_day))

这里没有采用“原始日期是月底，之后就永远取月底”的另一个常见策略。例如2027年4月30日向后一个月，本函数返回5月30日，而不是5月31日。因为本例保存的是原始日号30，保存的不是“月底”这个独立业务标记。若产品需要保持月底，应增加明确的策略字段和另一组预期结果，不能从一次偶然落在月底的输出反推意图。

4. 用同一份代码运行对照

anchor = date(2027, 1, 31)
fixed = month_date(anchor, 2)
chained = month_date(month_date(anchor, 1), 1)
print('fixed:', fixed)
print('chained:', chained)
print('difference_days:', (fixed - chained).days)
print('schedule:', [month_date(anchor, i).isoformat() for i in range(1, 4)])

本机Python 3.14.7的实际输出为：

fixed: 2027-03-31
chained: 2027-03-28
difference_days: 3
schedule: ['2027-02-28', '2027-03-31', '2027-04-30']

生成每月日期列表时，循环中的anchor保持不变，只让累计偏移i变化。这个细节比函数名字更重要：即使函数本身实现正确，如果调用方每次把结果赋回anchor，仍然会变回链式截断。建议将原始锚点、累计月份和最终展示日期分开存储，展示日期只是计算结果，不承担保存业务意图的职责。

5. 12项测试要验证边界，而不只验证示例

我先用返回None的最小占位函数运行普通年2月的断言，观察到预期失败，再实现函数并运行完整12项测试。完整检查包括普通年2月、闰年2月、保持原始31日、链式计算的三天差异、30日并非永远月底、跨年、零偏移、30天不等于一个日历月、非法月份、拒绝datetime和字符串、9999年边界，以及固定锚点的连续月份列表。12项均通过。

其中一条测试尤其值得保留：2027年1月31日加30天得到3月2日，而按照本例加一个日历月得到2月28日，相差的不是浮点误差，而是“固定时长”和“日历月份”这两种不同概念。2028年的2月有29天，同一个一月末起点又会得到另一种天数差，所以不能为了方便把所有月份统一换算成30天。

非法输入的测试也不能只写一个负数。这里分别检查-1、True、False、1.0、字符串和None；日期类型则检查datetime、日期字符串和None。目标是让调用者在边界处就收到清楚错误，不在生成报表或比较报价时才发现日期列混入无效结果。

6. 把本地预估接回真实业务时，还缺哪些证据

日历函数只能验证自己声明的策略，无法证明供应商采用同一规则。真实业务还可能受统一到期日、按天补齐、已有账期、最长续期、时区和产品特殊约定影响。因此，我会把本地输出标成“策略预估”，并单独保留平台给出的旧到期日、新到期日、结算周期和订单结果。两者不一致时先解释差异，而不是用本地日期覆盖平台数据。

需要计算实际延长天数时，日期差可以回答跨了多少个日历日；若需要计算准确持续时间，则必须使用已明确时区和边界的时刻。不要把只有年月日的date擅自补成某个地区的午夜，再声称那就是实际生效时间。本例没有调用支付接口、创建订单，也没有执行任何续费操作。

这个实验最终保留下来的规则很小：先明确要保存的是原始日号还是月底属性，保留原始锚点，用累计偏移计算展示日期，再用跨月和闰年的独立预期验证它。程序可以帮助发现日期漂移，但业务规则和实际到期结果仍需要各自的证据。

参考资料：Python官方datetime文档中的date、timedelta与类型关系说明；Python官方calendar文档中的monthrange说明。本文代码和所有日期均为本地合成实验。