先把当时的情况摆出来。DeepSeek 的错峰优惠是北京时间 00:30 到 08:30，批处理脚本用 datetime.utcnow() 判断窗口，国内凌晨一点跑的任务按原价计费，一个月多花了两百多。
排查方向其实有限，先把可能性排一排。UTC 与北京时间差 8 小时，窗口判断整体偏移。也可能是容器默认时区是 UTC，脚本没显式指定。
还有一种情况，优惠按请求完成时间算，长任务跨窗就按结束时刻。另外，批量任务一次性提交，实际执行时间不可控。
上来先打印容器当前时区
python -c "import time;print(time.tzname,time.timezone)"然后用 zoneinfo 显式换算北京时间
python -c "from zoneinfo import ZoneInfo;from datetime import datetime;print(datetime.now(ZoneInfo('Asia/Shanghai')))"接着把调度时间改到窗口内并留出余量
python -c "print('schedule 01:00 Asia/Shanghai')"末了核对账单里的计费时段字段
python -c "import json;print(json.load(open('bill.json')).get('period'))"别只看报错消失，验证要多做一步。任务在北京时间 01:10 提交，账单里这批请求按优惠价计费，单价是原价的五折，当月费用回到预算内。
提醒一点。任何按时间窗口计费的优惠都要显式带时区，utcnow 加上容器默认时区，是最常见的错峰踩坑组合。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。