不是把券用光就最好：用Python比较零现金续费报价

在做云服务器续费规划时，我遇到一个很具体的约束：只允许使用已经确认适用的代金券，不补现金，并尽量延长现有套餐的使用时间。这里有两个不同的问题。第一，某张券能否用于某个产品、区域和订购类型；第二，在确实能用的报价里，哪个方案增加的实际天数最多。把它们混在一起，很容易得到一个算术正确、却无法付款的答案。

这篇文章记录一个本地Python比较器的实现与验收。它不登录云平台、不读取账号、不创建订单，也不会检查或修改云资源。下文价格、天数、券余额全部是合成测试输入，不是任何产品的当前报价，不代表当前代金券支持哪些续费方式。

1. 先缩小为一个可核验的问题

比较器每次只处理同一资源、同一起始到期时间、同一币种、同一张券的一组单笔报价。输入中的days必须来自官方结算页面所示的新旧到期时间差，不能简单把“一个月”固定换成30天。每条报价还必须已经人工核清：产品和区域适用、续费订购类型符合、计费周期符合、消费门槛满足、没有产品例外或折扣冲突、券没有过期。

程序不假装能够自行验证这些条件。我用verified字段记录外部核验结果，只有明确为True才进入候选集。False表示不适用，None表示尚未查清，两者都不能参与推荐。给这个字段写True本身不构成平台的适用证明，使用者仍要保留条款和结算凭据。

为什么不直接按价格最高排序？因为目标是延长时间，而不是消耗面值。合成方案A花90元增加30天，方案B花80元增加60天；余额100元时，应选B。假如方案C增加90天但要100.01元，即使只差一分钱，也不符合零现金限制。方案D只要50元却未确认适用，同样不能推荐。

2. 金额从字符串进入Decimal

Python官方文档说明，Decimal可以精确表示十进制数，而从二进制浮点值构造Decimal会保留那个浮点值的实际表示。因此这个小工具要求金额以字符串传入，例如"100.00"，拒绝直接传入float。它还拒绝负数、NaN、Infinity和不足一分的金额，不把这些异常静默舍入成可支付的价格。

对于每一条报价，我先校验天数和金额，再按适用状态、余额进行过滤。候选按实际天数降序排列；天数相同则选价格更低的，保留更多券余额。这是一个单笔报价比较器，不把不同报价拼接成多单计划，也不假设第二单仍有同样价格。

from decimal import Decimal, InvalidOperation


def money(value):
    if not isinstance(value, str):
        raise ValueError("amount must be a decimal string")
    try:
        amount = Decimal(value)
        if (not amount.is_finite() or amount < 0
                or amount != amount.quantize(Decimal("0.01"))):
            raise ValueError("amount must be nonnegative whole cents")
        return amount
    except InvalidOperation as exc:
        raise ValueError("invalid decimal amount") from exc


def choose_quote(quotes, voucher):
    budget = money(voucher)
    candidates = []
    for row in quotes:
        days = row["days"]
        if type(days) is not int or days <= 0:
            raise ValueError("days must be a positive integer")
        price = money(row["price"])
        if row.get("verified") is True and price <= budget:
            candidates.append((row, price))
    if not candidates:
        return None
    row, price = min(candidates, key=lambda item: (-item[0]["days"], item[1]))
    return {"id": row["id"], "days": row["days"],
            "price": f"{price:.2f}", "remaining": f"{budget-price:.2f}"}


quotes = [
    dict(id="A", days=30, price="90.00", verified=True),
    dict(id="B", days=60, price="80.00", verified=True),
    dict(id="C", days=90, price="100.01", verified=True),
    dict(id="D", days=120, price="50.00", verified=None),
]
print(choose_quote(quotes, "100.00"))

本机实际运行结果为：

{'id': 'B', 'days': 60, 'price': '80.00', 'remaining': '20.00'}

这20元只是合成输入下的账面剩余，不是现金收益，也不保证一定存在能够继续使用它的续费周期。如果实际最短周期超过余额，应保留余券，而不是为了清零另买无用途资源。

3. 11项测试针对哪些错误

我先用无实现的测试替身观察失败，再实现真实比较器，移除替身后重新运行了11项unittest测试。最长天数、最高消费额和最低价格是三个不同目标，第一项测试专门防止把“最大化使用时间”写成“最大化花券金额”。一分钱超额测试则防止把price <= budget误写成允许微小补差。

其余测试覆盖：未知或不适用的报价必须排除；同天数选择较低价格；0.30元恰好覆盖后余0.00元；float输入拒绝；1.001这种不足一分的输入拒绝；非有限数、负数和无法解析的字符串拒绝；0、负数、布尔值或小数天数拒绝；所有方案超出余额时返回None；空报价集合返回None。期望值来自手工可核算的固定样例，没有让比较器自己生成期望结果。

这些测试验证的是本地排序与边界处理，不是平台结算测试。它们没有证明某张券有库存，没有证明某个服务器可续，也没有发起真实支付。尤其是多张券叠加、分单续费、统一到期日、赠送时长和活动折扣，仍须逐单读取平台实际结果。

4. 把计算结果放回实际流程

实际使用时，我会先读当前资源身份和到期日，再逐个记录可用周期的报价与到期日。每条报价经过条款核验后才能标为True。比较器只负责给出候选；真正提交前还要核对现金应付为0、没有开启自动续费、没有配置升级或其他附带收费。

完成一笔后，应重新读取订单成功状态、实际券抵扣、剩余券额和资源新到期日，再为下一单采集报价。不能把旧报价直接重复播放，也不能从一次HTTP成功或按钮点击推断续费成功。这样做的价值，是让“尽量延长时间”变成可以审阅和回读的决策过程，而不是只看券面额的直觉判断。

参考：Python decimal官方文档。本文代码与全部示例均在本机运行；没有披露账号标识、真实资源信息、密钥或其他业务资料。