Calendar.getInstance() 返回当前JVM默认时区的实例，非UTC也非系统本地时区；其行为受JVM时区设置影响，易因环境差异引发线上问题。
Calendar.getInstance() 返回的到底是什么时区？
它默认返回当前 JVM 默认时区的实例，不是 UTC，也不是系统本地时区（如果 JVM 时区被显式设置过）。很多线上问题就出在这儿——本地开发环境和服务器时区不一致，Calendar.getInstance() 表现不同。
- 查当前默认时区：
TimeZone.getDefault().getID()，别靠猜 - 要确定行为，显式传入时区：
Calendar.getInstance(TimeZone.getTimeZone("Asia/Shanghai")) - 避免在容器环境（如 Docker）里依赖默认时区，镜像可能没设
TZ环境变量，JVM 就 fallback 到 GMT
set() 和 add() 的行为差异经常被搞混
set() 是“覆盖”，add() 才是“相对偏移”。比如一个 Calendar 对象当前是 2023-01-31，调用 cal.set(Calendar.MONTH, 1)（即 2 月），结果不是 2023-02-31（不存在），而是自动滚到 2023-03-03；而 cal.add(Calendar.MONTH, 1) 才是真正加一个月，变成 2023-02-28（或 29）。
-
set()后记得调用cal.getTime()前先cal.complete()，否则字段可能未归一化（尤其跨月/年 set 后直接 get 某字段） -
add()支持负数，roll()则只在本范围内滚动（比如对日期 roll(1) 不会进月） - 批量修改多个字段时，
set()多次不如用set(year, month, date, ...)构造器一次到位
Calendar 的线程安全性问题在哪儿？
Calendar 实例不是线程安全的。它的内部状态（比如 fields[]、isTimeSet）在 get()/set()/add() 过程中会被反复修改，多线程共用同一个实例，极易出现时间错乱或 ArrayIndexOutOfBoundsException（尤其在并发调用 getTime() 时触发内部计算）。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 永远不要把
Calendar当作静态工具类成员或 Spring bean 单例注入 - 短生命周期场景下，每次用都
Calendar.getInstance()新建——开销远小于排查并发 bug 的成本 - 若真需复用，必须配合
synchronized或ThreadLocal<calendar></calendar>，但后者注意内存泄漏风险（尤其 Web 容器中未 remove）
为什么 new GregorianCalendar() 比 Calendar.getInstance() 更危险？
GregorianCalendar 是 Calendar 的具体子类，但直接 new GregorianCalendar() 会跳过父类的时区/语言环境初始化逻辑，且默认构造器使用的是 JVM 默认时区 + 默认 Locale，但某些 JDK 版本中它甚至不触发 complete()，导致首次 get() 出现未定义行为。
立即学习“Java免费学习笔记（深入）”；
- 一律用
Calendar.getInstance()，哪怕你要的是格里高利历——它返回的本来就是GregorianCalendar实例（JDK 7+） - 需要指定纪年方式（如日本和历）才考虑直接 new 子类，并传全参数：
new GregorianCalendar(JapaneseChronology.INSTANCE, Locale.JAPAN) - 注意：Android 上部分低版本对
GregorianCalendar构造器参数兼容性差，getInstance()更稳
