推荐使用 cal_days_in_month(CAL_GREGORIAN, 2, $year)，它不依赖时间戳、规避闰年逻辑错误，兼容1–9999年；date('t') 和 DateTime 因时间戳限制及废弃风险不推荐。
PHP怎么用 date() 和 cal_days_in_month() 获取二月天数
直接看结果：闰年二月是29天，平年28天。PHP不靠手算年份，而是用内置函数查日历表——cal_days_in_month() 最稳，date('t', ...) 也能用，但得注意时间戳精度。
常见错误是硬写逻辑判断闰年（比如 $year % 4 == 0），漏掉“整百年必须被400整除”这条规则，导致2100年、1900年这类年份算错。
-
cal_days_in_month(CAL_GREGORIAN, 2, $year)：最推荐，底层调用系统日历库，完全规避闰年逻辑出错风险 -
date('t', mktime(0, 0, 0, 2, 1, $year))：可行，但依赖mktime()对无效日期（如2月30日）的自动修正，PHP 8.1+ 已标记mktime()为废弃，未来可能移除 - 别用
strtotime("2024-02-01")再格式化，strtotime()在时区或 DST 边界下可能返回 false，导致date('t')算出31天这种荒谬结果
为什么 DateTime::createFromFormat() 不适合查二月天数
它本意是解析字符串，不是计算月份长度。强行用 new DateTime("2024-02-01")->format('t') 看似能跑通，但本质和 date('t') 一样，绕不开时间戳构造环节；更麻烦的是，如果传入的年份超出 PHP 时间戳范围（Unix timestamp 溢出，比如年份 2038 在32位系统），会静默返回1月天数（31），而不是报错。
典型翻车场景：处理历史数据（如1752年英国历法改革年）或远期规划（2150年养老金计算），DateTime 实例化失败却无提示，format('t') 还照常返回31。
立即学习“PHP免费学习笔记（深入）”；
- 只在确定年份落在 1901–2038（32位）或 1970–2038（部分旧配置）范围内才考虑
DateTime - 跨世纪年份一律退回
cal_days_in_month()，它不依赖时间戳，纯查格里高利历表 - 注意
CAL_GREGORIAN是常量，不是字符串，写成'CAL_GREGORIAN'会报Warning: cal_days_in_month(): invalid calendar
cal_days_in_month() 的兼容性坑点
这个函数从 PHP 4.0 就存在，看似很稳，但有两个隐藏限制：一是 Windows 下某些旧版 PHP（
真正容易被忽略的是参数顺序：cal_days_in_month($calendar, $month, $year)，不是 ($year, $month)。把年份放第二位会导致返回 false，而 PHP 默认不报错，后续 if 判断直接走错分支。
- 务必检查返回值是否为
false，尤其当$year来自用户输入或数据库字段时（比如空字符串、负数、超大整数） - Windows + PHP 5.2 环境下，传入
$year = 0可能返回 28 而不是预期的错误，Linux 下则返回false，跨平台代码必须做类型校验 - 不用试图用它查农历二月——
CAL_JEWISH或CAL_CHINESE不支持月份天数查询，会直接返回false
简单封装一个安全的闰年二月天数函数
把校验和兜底写进函数里，比每次调用都手动 check 更可靠。重点不是多 fancy，而是堵住 null、字符串、负数这些常见脏数据入口。
function getFebDays(int $year): int
{
if ($year < 1 || $year > 9999) {
throw new InvalidArgumentException('Year must be between 1 and 9999');
}
$days = cal_days_in_month(CAL_GREGORIAN, 2, $year);
return $days ?: 28; // fallback only for extreme edge cases (e.g. broken extension)
}
这个函数没加闰年逻辑重实现，就是信任 cal_days_in_month()。如果你发现它返回了28但你知道那年是闰年，问题一定出在 PHP 编译时没启用 calendar 扩展（检查 php -m | grep calendar），而不是代码逻辑错了。
闰年规则本身不难，难的是让代码在各种 PHP 版本、系统、输入质量下都不掉链子。最省心的做法，就是把计算交给 C 层日历库，而不是在 PHP 层重复造轮子。
