先把T+1、D0、D1按清算口径拆开

T+1里的T是交易日，不是付款那一刻。+1表示下一个工作日到账。这个规则来自银行清算系统，跟平台无关。例如周五下午的交易，T可能落在周五，+1就是下周一；如果周一正好是法定节假日，再顺延到周二。很多人在这里把自然日和工作日混在一起。

D0是交易日当天进入清算批次。D1是次日进入清算批次。两者都只是清算归属不同，不代表资金实时划入银行账户。银行通常会安排多个清算场次，比如上午一场、下午一场、夜间一场。D0的交易可能进入当天最后一场，实际到账时间仍然是晚上。

这里最容易错。自然日就是日历翻一天，工作日要剔除周末和节假日。银行清算系统按工作日运行，所以T+1不是明天，是下一个工作日。遇到国庆、春节这类长假，周五的T+1可能要等到节后第二个工作日。后台显示预计到账日期时，日历表必须准。如果日历表错了，后面所有计算都会跟着错。

D0和D1看起来像是快慢，实际上只是这笔交易被归到哪个清算批次。D0归入当天批次，D1归入次日批次。支付通道会按自己的批次表跑清算，不是每一笔D0都一个时间点入账。银行账单上的清算批次号能看出来差别。

D1最麻烦的地方是口径不统一。有些银行账单把D1写成自然日次日，有些按下一个结算日。商户对账时如果只看D1这个符号，不等银行账单出来，很容易算错预期。之前我在一个网银回单里看到D1交易的实际入账日期是次日下午，但不是节假日，只是刚好落在下午批次。

一次周五交易为什么多等两天

上个月排查一个到账时间问题。商户后台设置的是T+1，周五16:20有一笔交易，按规则应下周一入账。结果银行账户周三才看到钱。商户以为支付通道出问题，其实查下来是日历表错了。

这里试了两种方法。第一种直接看后台的清算日历，显示周一正常工作日，没问题。第二种把央行支付系统工作日历导出来比对，发现那个周一被标成调休上班日，但后台日历用的是一份旧表，仍然把周一当节假日。于是多顺延了一天，又叠加了其他批次，最后变成周三。

如果你也遇到类似问题，先查后台日历表，再看央行支付系统工作日历，多半是日历没更新。

后来把后台的calendar.json拉出来看了一眼，里面workday字段确实写着false。

{
  "2026-08-24": { "workday": false }
}

这个日期是周一。按央行发布的那一年支付系统工作日历，那天是调休上班，应该算工作日。把workday改成true，重新计算后，同一笔交易的理论到账日变成周一，跟银行账单对上了。这个参数错了一个，整个批次的预期日期都偏了。

在后台改结算周期之前，我会先确认三点：银行账户支持哪些清算批次，对账单里有没有独立的清算日期字段，后台的日历文件是不是当年的。第三点最容易漏。年份一切换，旧日历文件里的节假日和调休安排就全错了。

尤其是对账文件里如果没有独立清算日期，只有交易日期，那T+1和D0的差异会混在一起，很难分开。这时候要回到银行账单里找批次号或者清算日期，不能用交易时间硬推。

后台的结算周期参数一般长这样：

settlement_cycle: "T1"
clearing_calendar: "cncb_2026.json"

这个参数只是给商户看规则，不会改变银行清算系统本身的运行时间。T1、D0、D1的区别最终落在清算批次号上，银行账单里通常会带这个批次号。对账的时候不要只看金额，批次号才是关键。

验证不用猜。第一步，导出一段交易明细，把后台的清算日期字段和银行账单的入账日期放在一起比对。第二步，只看同一批次号下的交易笔数，如果大部分入账时间一致，个别不一致，多半是跨行或账户类型差异。

awk -F, '{print $5}' settlement.csv | sort | uniq -c

这个命令就是统计每个清算日期的交易笔数。当时跑完就发现，问题交易落在一个单独日期，其他交易都在预期日期。这个方法比人工翻快不少。

银行清算系统有小额支付系统和大额支付系统。小额支付系统基本7×24运行，但清算批次仍然分场次。大额支付系统只工作日运行。商户问到账时间，先要看这笔交易走哪个通道、哪个批次。平台公示的到账时效只能当参考。

工作日历和自然日的差异在跨年时最明显，12月31日的T+1可能落在1月2日甚至更晚。很多商户年底对账会卡在这个点。

这也能解释支付成功后钱多久到账 T+1 D0 D1 的区别：D0是当天某个批次，T+1是下一个工作日，D1是次日批次。实际上，银行账单上的入账时间可能比理论日期晚几小时，这不是异常，是批次处理时间。之前写支付退款原路退回多久到账：一次部分退款引发的排查时也碰到类似问题，退款时效和交易日历强相关。

如果你的后台版本较新，注意它会自动读取新的日历源，旧配置里写失败的calendar文件可能失效。这个问题后面可能还会变。