在卡号和校验位之外，卡片上还有一处小小的印刷信息：月份两位、斜杠、年份两位。它就是信用卡有效期格式的全部内容，看上去是整张卡上最容易理解的一处。但正因为它简单，几乎所有支付团队都在它上面栽过一次跟头——栽的不是读法，而是最后那一天的归属。
读完这篇，你会知道为什么「有效到当月月底」这一条会衍生出一连串差一错误，也会知道表单上那两个小输入框为什么值得单独测一遍。
卡面上印的是什么
卡面通常印四位数字加一个分隔符，前两位是月份，后两位是年份。少数卡片只印月份和年份的后两位而不带分隔符，读法相同。
需要留意的是年份只有两位所带来的歧义。这四位组合在系统内部如何解释，取决于各方的约定，而不是卡面本身。也就是说，卡面显示的内容和系统存储的内容未必长得一样——这一点在后文还会再出现一次。
月份一律用两位表示，一位数月份前面补零。这条规则很关键：如果界面把一月显示成单独的一个数字，用户在核对时很容易把它当成另一位数字的一部分。
有效到当月月底还是月初？
这是本文最想强调的一条规则：卡在印刷的那个月的最后一天之前都有效，而不是到那个月的第一天。
换句话说，一张印着九月到期的卡，在九月三十日仍然可用，直到十月一日才失效。这一个字的差别制造了两类经典错误。
第一类是判断方向写反。把「有效期小于当前月」当成失效条件，会让整月的卡提前作废；把「小于等于」当成失效条件，又会让刚过期的卡继续被接受。两种写法都能通过肉眼检查，因为它们只差一个符号。
第二类是分界点的比较方式。如果日期被简化成「年份加月份」这种六位数字来比较，很多实现会忘记月份的取值范围是 1 到 12，导致跨年时的比较结果异常。稳妥的做法是先把有效期换算成「该月的最后一天」，再与当前日期比较。
填写时最常见的几个坑
按出现频率排列，实际遇到的麻烦大致是这些：
- 年份的世纪归属：用户看到年份两位，系统把它解释成十九几几年，于是所有有效期都成了过期。
- 月份不补零：有人填九，有人填零九，两种输入都应该被接受，但归一化没做就会只认其中一种。
- 粘贴整串日期：用户把带分隔符的整串字符粘进月份框，输入框只接受数字时内容会被吞掉。
- 过期与否提示时机：在用户还没填完年份时就报「已过期」，会让人以为自己写错了。
- 时区边界：服务端按协调世界时判断，用户本地时间已经进入下个月，于是月底最后几个小时的判断出现分歧。
- 测试数据太远景：预先造好的测试卡用了很多年后的年份，几年后翻出来用时依然有效，掩盖了边界逻辑的问题。
最后一条尤其值得注意，因为它影响的不是线上，而是你的测试是否还有效。
有效期和卡号、安全码怎么分工？
三者各管一件事，混在一起想就容易把校验写乱：
| 字段 | 回答什么问题 | 是否可以保存 |
|---|---|---|
| 卡号 | 这是哪个账户 | 可以，需要保护 |
| 有效期 | 此刻这张卡还能不能用 | 通常需要保存 |
| 安全码 | 卡是否在持卡人手上 | 授权后禁止保存 |
这张表也解释了为什么有效期常被拿来做「卡是否还活着」的快速过滤，而安全码不行——一个可以留下来做后续判断，一个必须当场丢掉。安全码的具体规则见CVV 是什么。
显示格式和存储格式不是一回事
在界面上，有效期写作月份加年份；在系统之间传输时，它常常被压成一个紧凑的数值，比如用四位表示年月，年份占前两位、月份占后两位，或者干脆由各处自行约定。
对开发者来说，结论只有一句话：不要假设你在界面上看到的形式，等于它在报文里的形式。每次跨越边界——从前端到后端，从你的系统到支付服务商——都要明确换算一次，并且把换算写成单独的一处，而不是散落在多个分支里。
这个原则听起来抽象，但它在测试里非常具体：只要有一处换算方向写反，表现就是所有卡都提前一个月过期，或者残留一个月仍然有效。
另有一层容易被忽略的语义差别：卡片本身在标注月份的最后一刻仍然有效，但部分支付服务商会把「本月到期」的卡视作即将失效，在风控上收紧它的可接受范围。于是同一张卡在一家商户能通过、在另一家被拒绝，就成了一个真实存在的边界情形。它不是谁的错，而是规则不同层的自然结果，因此文档里最好写明本系统采用哪一种口径。
在本站生成测试卡号时的有效期
用信用卡号生成器生成号码时，结果会附带一个有效期。它的用途是让整张表单能被一次填完，方便复制到联调页面或测试脚本里。
请把它当作示例数据来用：这些号码结构上合法，但从未发行给任何人，其中的有效期也不对应任何真实账户。如果你的测试需要覆盖边界，建议不要依赖生成结果的默认值，而是自己准备几张刻意处在「本月到期」「下月到期」「已过期一个月」的固定数据，相关内容见测试信用卡号是什么。
给开发者：控件、边界与自查
输入控件的取舍直接影响边界测试的成本：
- 两个框还是四个：分开的月份框与年份框能减少歧义，但粘贴体验更差；单框加自动插入分隔符体验更好，但需要处理用户回删。无论选哪种，归一化逻辑都应该只接受数字。
- 自动跳转要谨慎：填满两位自动跳到下一个框很顺手，但用户在中间改了前一位时容易卡住。允许删除并回退是必须的。
- 不要用日期选择器：有效期是月份粒度，日历控件会诱导用户选一个具体日期，反而制造歧义。
边界值方面，至少准备这几种情况：当月到期、下月到期、上个月到期、去年同月、年份为两位最小值和最大值。注意「当月到期是否有效」这个用例必须同时在前端提示和后端判断两处验证，因为两处常常用的是不同的实现。
「已过期」的判断建议集中在一个函数里，输入是有效期与参照时间，输出是一个明确的布尔结果。集中之后，配合固定的参照时间做测试，就不会出现本地能跑、线上因为时区而不同的情况。上线前把这类边界放进回归清单，具体项目可参考支付表单测试清单。
下一步
记住两句话：有效期到印刷月份的月底，而不是月初；界面上的格式不等于传输时的格式。