应使用 DateTime.IsLeapYear() 判断闰年，它已封装公历全部规则且稳定高效；勿手动计算或用 new DateTime(year, 2, 29) 异常判断；注意年份需在1–9999范围内并预先校验，且该方法不适用于农历。
用 DateTime.IsLeapYear() 最简单也最可靠
别自己写逻辑算“能被4整除但不能被100整除，除非能被400整除”——这容易漏边界、错优先级，而且 DateTime.IsLeapYear() 已经封装好所有规则，包括公历修正和跨世纪特例。
它只接受 int 类型的年份参数，不接受 DateTime 对象本身（想从日期取年份得先 .Year）：
bool is2000Leap = DateTime.IsLeapYear(2000); // true bool is1900Leap = DateTime.IsLeapYear(1900); // false bool is2100Leap = DateTime.IsLeapYear(2100); // false
- 传入负数或超出
DateTime支持范围（公元1–9999年）会抛出ArgumentOutOfRangeException - 不要传
DateTime.Now.Year这种表达式进去再加空值检查——先确保年份变量非空且合法，再调用 - 这个方法是静态的，不依赖文化或时区，结果稳定
别在 DateTime 构造里硬凑 2 月 29 日来判断
有人用 new DateTime(year, 2, 29) 是否抛异常来反推是否闰年，这不仅低效（触发异常开销大），还会掩盖真实问题：比如传入非法年份时你分不清是“不是闰年”还是“年份根本无效”。
- 异常类型都是
ArgumentOutOfRangeException，无法区分原因 - 如果年份是变量且未校验（比如来自用户输入或数据库），可能在构造时直接崩，而不是返回
false - 性能上比
IsLeapYear()慢一个数量级（实测 10 万次调用差约 8ms）
注意 DateTime 默认是公历，不支持农历或其它历法
DateTime 类型底层绑定的是 GregorianCalendar，所以 IsLeapYear() 的结果永远按公历规则计算。如果你业务涉及农历闰月（比如春节、节气），这个方法完全不适用。
- 农历闰年 ≠ 公历闰年（例如 2023 年公历不是闰年，但农历有闰二月）
- 没有内置 API 能直接判断农历闰年；需要引用第三方库如
ChineseLunisolarCalendar，或自己维护节气表 - 混淆这两者会导致排班、合同到期日、利息计算等业务逻辑出错，而且很难复现
从 DateTime 实例取年份时记得先判空和有效性
如果你拿到的是可空类型 DateTime? 或来自外部的字符串解析结果，直接链式调用 .Value.Year 或 .Year 可能炸掉。
DateTime? date = null;
int year = date?.Year ?? 0; // 安全取值
if (year != 0 && year >= 1 && year <= 9999) {
bool leap = DateTime.IsLeapYear(year);
}
-
DateTime本身不能为null，但DateTime?、object或 ORM 映射字段可能为空 - 字符串转
DateTime失败时，别用Convert.ToDateTime()硬转——它对非法格式直接抛异常，改用DateTime.TryParse() - 年份为 0 是无效值（
DateTime最小年份是 1），但IsLeapYear(0)会抛异常，不是返回false
IsLeapYear()。 
