LocalDateTime.plus()和minus()参数须为TemporalAmount类型，优先用Period处理年月日、Duration处理时分秒；解析字符串需匹配格式；转Instant/ZonedDateTime必须指定时区；它不感知夏令时，仅适用于无时区场景。
LocalDateTime.plus() 和 minus() 方法怎么选参数
LocalDateTime 本身不可变，所有运算都返回新实例，不是修改原对象。用 plus() 或 minus() 时，传入的单位必须是 TemporalAmount 类型——最常用的是 Period（年月日）和 Duration（时分秒纳秒）。混用会编译报错：plus(Period.ofDays(1)) 合法，plus(Duration.ofHours(1)) 也合法，但 plus(1) 或 plus("1d") 直接不通过。
常见误操作：想加 30 分钟却写成 plus(Period.ofMinutes(30)) ——Period 不处理小时以下单位，此时应改用 Duration.ofMinutes(30)。反过来，加 1 个月必须用 Period.ofMonths(1)，因为 Duration 没有“月”概念（天数不固定）。
- 加减天数、月数、年数 → 优先用
Period - 加减小时、分钟、秒、纳秒 → 优先用
Duration - 跨日计算（如“当前时间 + 25 小时”）→ 用
Duration，它会自动进位到第二天
解析字符串后做运算，为什么有时结果不对
LocalDateTime.parse() 默认只认 ISO_LOCAL_DATE_TIME 格式（如 "2023-10-05T14:30:45"）。如果原始字符串带毫秒（"2023-10-05T14:30:45.123"）或带时区（"2023-10-05T14:30:45+08:00"），直接 parse 会抛 DateTimeParseException。
解决方法是显式传入 DateTimeFormatter。例如解析带毫秒的字符串：LocalDateTime.parse("2023-10-05T14:30:45.123", DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSS"))。漏掉 S 数量或大小写不匹配（如用小写 yyyy-mm-dd），都会导致解析出错或值偏移。
- 年份必须大写
yyyy，小写yy会被当成两位年，可能变成 19xx - 月必须大写
MM，小写mm是分钟，极易混淆 - 解析后立刻做运算前，建议打日志确认值是否符合预期，比如
System.out.println(parsed)
与 Instant、ZonedDateTime 互转时丢失信息怎么办
LocalDateTime 没有时区也没偏移，转成 Instant 必须指定时区，否则编译不通过。常见错误写法：localDateTime.atInstant(ZoneOffset.UTC) ——这看似合理，但如果原始 LocalDateTime 是按系统默认时区理解的（比如用户输入的“今天下午三点”），强行用 UTC 转换会导致时间值错 8 小时（东八区）。
正确做法是先明确业务上下文：如果是存储用户本地时间并后续按本地逻辑运算，就别急着转 Instant；如果必须存为时间戳，则用 localDateTime.atZone(ZoneId.systemDefault()).toInstant()。反向转换（Instant → LocalDateTime）同理，必须指定时区，否则无法还原。
-
LocalDateTime.now()是系统默认时区的“此刻”，不是 UTC -
LocalDateTime.ofInstant(instant, ZoneId.of("Asia/Shanghai"))才能还原为中国标准时间下的本地表示 - 跨时区调度类场景（如定时任务），不要用
LocalDateTime做持久化，该用ZonedDateTime或Instant
夏令时切换当天做加减运算会出问题吗
不会——因为 LocalDateTime 本身不感知夏令时。它只是“年月日时分秒”的组合，没有时区语义。真正出问题的是 ZonedDateTime 或 Instant 转换环节。例如在柏林，2023 年 3 月 26 日凌晨 2 点直接跳到 3 点（夏令时开始），此时 ZonedDateTime.of(..., ZoneId.of("Europe/Berlin")) 构造 2023-03-26T02:30 会抛异常；但 LocalDateTime.of(2023, 3, 26, 2, 30) 完全合法，只是它不代表任何真实时刻。
所以关键判断点在于：你的业务是否需要映射到真实世界的时间线？如果只是做报表日期归档（如“统计 3 月第 4 周的数据”），用 LocalDateTime 安全；如果涉及定时触发、倒计时、跨时区协作，就必须升维到带时区的类型。
- 用
LocalDateTime做“日期计算器”没问题，比如生成未来 7 天的日历列表 - 但用它算“距离某个事件还剩多少毫秒”，就一定得转成
Instant再减 - Java 8 的
LocalDateTime没有内置“是否在夏令时区间内”的判断能力，别试图自己实现
