JavaScript Date对象操作易出错的根源在于时区处理、字符串解析不一致、可变性及本地化不可控：需用数字参数或ISO格式构造，克隆后操作，用UTC方法读取，序列化优先toISOString()。
JavaScript 的 Date 对象本身不直接支持时区转换、日期加减或格式化，所有“常见操作”都得靠手动计算或补丁逻辑——这是多数人踩坑的根源。
为什么 new Date() 有时返回 NaN 或 Invalid Date
直接传入非标准格式字符串（比如 "2024-02-30"、"31/12/2024"、带中文的 "2024年1月1日"）极易触发解析失败。浏览器对 Date.parse() 的宽松程度不一致，Chrome 可能容忍 "2024-01-01 12:00"，但 Safari 会返回 NaN。
- 始终优先用数字参数构造：
new Date(2024, 0, 1, 12, 0)（注意：月份从 0 开始） - 解析字符串时，只信任 ISO 8601 格式：
"2024-01-01T12:00:00Z"（末尾Z表示 UTC） - 用
isNaN(new Date(...).getTime())而不是toString() === "Invalid Date"判断有效性
如何安全地做日期加减（比如加 7 天）
Date 对象是可变的，setDate() 会直接修改原对象，且不处理跨月/跨年边界——new Date(2024, 0, 31).setDate(31 + 7) 会变成 2 月 7 日，但 2024 年 2 月只有 29 天，结果自动滚到 3 月 7 日。这看似合理，实则掩盖了逻辑意图。
- 先克隆再操作：
const d = new Date(original); d.setDate(d.getDate() + 7); - 避免用
setMonth()加减月数：它不保证日期“存在”，new Date(2024, 0, 31).setMonth(1)得到的是 2024-03-02（因为 2 月只有 29 天，多出的 2 天顺延） - 真要加月，用
new Date(d.getFullYear(), d.getMonth() + 1, d.getDate())，再检查getDate()是否等于原值，不等说明被归一化了
toLocaleDateString() 的输出为什么在不同机器上不一样
这个方法完全依赖宿主环境的系统区域设置和 ICU 数据，en-US 下是 "1/1/2024"，de-DE 下是 "1.1.2024"，连是否显示星期几、年份用 2 位还是 4 位都不可控。它不适合用于数据交换或 UI 一致性要求高的场景。
立即学习“Java免费学习笔记（深入）”；
- 需要稳定格式时，别用
toLocale*系列，改用getFullYear()、getMonth()等手动拼接 - 若必须本地化，显式传参：
date.toLocaleDateString("en-US", { year: "numeric", month: "2-digit", day: "2-digit" }) - 注意
timeZone选项只影响时区偏移计算，不改变格式结构；且部分旧 Android WebView 不支持该选项
时区问题最常被忽略的细节
Date 对象内部存储的是毫秒数（UTC 时间戳），但几乎所有 getter（如 getHours()）默认返回**本地时区**值。这意味着 new Date("2024-01-01T00:00:00Z").getHours() 在东八区返回 8，而非 0。
- 读取 UTC 值用
getUTCHours()、getUTCDate()等对应方法 - 构造明确 UTC 时间，用
new Date(Date.UTC(2024, 0, 1, 0, 0))，而不是new Date("2024-01-01")（后者按本地时区解析） - 序列化为后端可解析的时间字符串，优先用
toISOString()（返回"2024-01-01T00:00:00.000Z"），别用toString()或toJSON()（后者底层调用toISOString，但语义模糊）
真正麻烦的从来不是“怎么写”，而是“哪一步隐含了时区切换”“哪个 getter 悄悄用了本地时间”“哪个字符串解析在 iOS 上就挂了”。这些细节不会报错，只会让时间在某个凌晨三点悄悄偏移一天。
