JavaScript中Date对象默认使用本地时区，字符串构造有歧义，应优先用参数形式；获取时间用getFullYear()等，UTC操作用getUTC系列；格式化推荐Intl.DateTimeFormat；日期运算宜用毫秒加减。
JavaScript 中 Date 对象的创建和基础校准
直接用 new Date() 创建的是本地时区时间，不是 UTC，也不是服务器时间。很多时间计算出错，根源就在这里。
-
new Date()：取浏览器当前本地时间（含时区偏移） -
new Date('2024-01-01')：字符串解析有歧义——'2024-01-01'被当作 UTC 时间处理，但'2024/01/01'才按本地时区解析 - 避免用字符串构造器，改用参数形式：
new Date(2024, 0, 1, 12, 30, 0)（注意：月份是 0～11） - 需要 UTC 时间？用
Date.UTC(2024, 0, 1, 12, 30, 0)得到毫秒数，再传给new Date(...)
获取年月日时分秒——别直接用 getYear() 和 getYear() 已废弃
getYear() 返回的是距 1900 的年份数（如 2024 → 124），且已被标准废弃，必须用 getFullYear()。
-
getFullYear()/getMonth()/getDate()：本地时区值（getMonth()同样是 0～11） -
getUTCFullYear()/getUTCMonth()/getUTCDate()：对应 UTC 值，跨时区场景必须用这套 -
getHours()和getUTCHours()差异可能达 ±24 小时，比如北京时间new Date('2024-01-01T00:00:00Z')的getHours()是 8，getUTCHours()是 0
格式化输出——toJSON()、toISOString() 和 toLocaleString() 的关键区别
toISOString() 和 toJSON() 行为一致，都返回形如 "2024-01-01T00:00:00.000Z" 的 UTC 字符串；而 toString() 返回带本地时区的长字符串，不可靠。
Pilot Digital Twin Setup
下载
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
-
date.toISOString()：适合 API 传输、数据库存储，明确带Z表示 UTC -
date.toLocaleString('zh-CN')：按用户本地语言+时区格式化，但结果不可预测（比如 iOS 和 Chrome 对hour12: true处理不同） - 需要可控格式？别拼字符串，用
Intl.DateTimeFormat：
const fmt = new Intl.DateTimeFormat('zh-CN', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
hour12: false
});
fmt.format(new Date()); // "2024-01-01 12:30:45"
日期加减和比较——用毫秒运算，别改 Date 实例内部
Date 对象本身不可变（所有 setter 都是原地修改），但「加 7 天」这种操作容易误写成 date.setDate(date.getDate() + 7)，看似合理，实则在夏令时切换日或跨月时出错（比如 3 月 31 日加 1 天，可能跳到 4 月 1 日，也可能变成 4 月 0 日 → 自动归位到 3 月 30 日）。
立即学习“Java免费学习笔记（深入）”；
- 安全做法：转成毫秒，加减后再重建：
new Date(date.getTime() + 7 * 24 * 60 * 60 * 1000) - 比较两个时间？直接用
date1 > date2或date1.getTime() > date2.getTime()，两者等价，但前者更简洁 - 注意
NaN风险：无效 Date（如new Date('abc')）的getTime()是NaN，参与比较会始终返回false
时区、字符串解析歧义、夏令时边界、getMonth() 从 0 开始——这些不是边缘情况，而是日常踩坑高频点。写时间逻辑前，先确认你到底要本地时间、UTC 时间，还是某个固定时区时间。
