应使用 ISO 8601 带时区格式（如 new Date('2025-03-15T14:30:00+08:00')）或数值参数（new Date(2025, 2, 15, 14, 30, 0)）安全创建 Date 实例，避免无时区字符串解析。
JavaScript 的 Date 对象不是“拿来就能用”的工具，它默认返回本地时区时间、构造行为易出错、方法命名不统一（比如 getMonth() 从 0 开始但 getDate() 从 1 开始），直接调用很容易埋下时区或边界逻辑 bug。
怎样安全创建一个表示“2025-03-15 14:30:00”的 Date 实例
别用字符串构造器 new Date('2025-03-15 14:30:00') —— 它在 Safari 和部分旧环境会返回 Invalid Date，且解析行为依赖宿主实现。更可靠的方式是：
- 用 ISO 8601 格式带时区：
new Date('2025-03-15T14:30:00+08:00')（显式指定 +08:00） - 用数值参数：
new Date(2025, 2, 15, 14, 30, 0)（注意：月份是 0–11，所以 3 月传2） - 若时间来自后端 Unix 时间戳（毫秒），直接传数字：
new Date(1710484200000)
关键点：永远明确时区意图；避免无时区的字符串解析。
为什么 getMonth() 返回 0–11，而 getDate() 返回 1–31
这是历史遗留设计，getMonth() 对应内部存储的月份数组索引（Jan=0, Feb=1…），而 getDate() 是“当月第几天”，自然从 1 开始。这种不一致导致常
-
date.getMonth() + 1才是人类理解的月份 -
date.getDay()返回的是星期几（0=Sunday, 1=Monday…），不是“第几天”——别和getDate()混了 - 所有
getXXX()方法都基于本地时区，如需 UTC 值，必须用getUTCXXX()系列（如getUTCHours()）
如何把 Date 转成标准格式字符串（不含时区偏移）
原生 toString() 或 toLocaleString() 都带时区信息或受系统 locale 影响，不可控。要稳定输出如 "2025-03-15 14:30:00"，得手动拼接：
const d = new Date();
const y = d.getFullYear();
const m = String(d.getMonth() + 1).padStart(2, '0');
const dt = String(d.getDate()).padStart(2, '0');
const h = String(d.getHours()).padStart(2, '0');
const min = String(d.getMinutes()).padStart(2, '0');
const s = String(d.getSeconds()).padStart(2, '0');
const str = `${y}-${m}-${dt} ${h}:${min}:${s}`;
注意：padStart(2, '0') 防止个位数月份/日期被截断；如果需要 UTC 时间，全部换成 getUTCXXX() 方法。
getTimezoneOffset() 返回值为什么是负数？
new Date().getTimezoneOffset() 返回的是当前时区与 UTC 的**分钟差**，但定义是 “UTC 减本地时间”，所以东八区（UTC+8）返回 -480（即 UTC 时间比本地早 480 分钟）。这个负号容易让人困惑，实际使用中建议：
- 不要靠它推算时区缩写（如 CST、PST），不同地区同名缩写可能指向不同时区
- 跨时区计算时间差，优先用时间戳（
date.getTime()）相减，再除以 60000 得到分钟差 - 真正需要时区标识时，用
Intl.DateTimeFormat().resolvedOptions().timeZone获取 IANA 时区名（如"Asia/Shanghai"）
时区处理是 Date 最容易翻车的地方——哪怕只做简单展示，也要确认你拿到的 Date 实例到底代表哪个时区的时间，以及你准备把它按什么规则渲染出去。
