Date对象默认返回本地时区时间，字符串解析存在兼容性问题，推荐用ISO格式或参数形式构造；getYear()已废弃，应统一用getFullYear()；set方法会自动归一化；格式化优先使用toLocaleString等内置方法。

Date 对象不是“拿来就用”的工具，它默认返回本地时区时间，且构造函数对字符串解析高度依赖环境，不加判断直接 new Date('2025-10-01') 在 Safari 和某些旧 Android WebView 中可能返回 Invalid Date。

new Date() 构造函数的坑比你想象的多

传字符串时，只有 ISO 8601 格式（如 '2025-10-01T00:00:00'） 是 ECMAScript 明确要求支持的；'2025/10/01' 或 '2025-10-01'（无时间部分）在不同浏览器行为不一致。

• 推荐写法：new Date('2025-10-01T00:00:00') 或 new Date(2025, 9, 1)（注意：月份从 0 开始）
• 避免写法：new Date('2025-10-01')（Safari 可能解析为 UTC 时间，导致本地时间偏移一天）
• 动态构造推荐用参数形式：new Date(year, monthIndex, date, hour, minute, second, millisecond)，可控性强

getY

ear() 已废弃，别再用了

getYear() 返回的是距 1900 年的年份差（如 2025 → 123），且在现代引擎中已被弃用。所有年份操作应统一使用 getFullYear()。

• getDate()：返回每月第几天（1–31）
• getMonth()：返回月份索引（0–11），不是 1–12
• getDay()：返回星期几（0=周日，1=周一…）
• 获取 UTC 时间请用 getUTCFullYear()、getUTCHours() 等对应方法

setXXX 方法会隐式触发日期归一化

setDate(40) 不会报错，而是自动进位到下个月；setMonth(13) 会变成下一年的 1 月。这是合法行为，但容易引发逻辑误判。

• 比如：当前是 2025-01-31，执行 date.setMonth(1)（设为 2 月），结果是 2025-03-03（因为 2 月没有 31 日，自动溢出到 3 月 3 日）
• 如需“保持日不变”，建议先记下原 getDate()，再用 setDate() 显式重置
• setTime() 最安全：直接设置毫秒数，完全绕过日期计算逻辑

格式化输出别手写拼接，优先用 toLocaleString

手动拼 date.getFullYear() + '-' + (date.getMonth()+1) 容易漏补零、忽略时区、无法适配多语言。现代浏览器已普遍支持 toLocaleDateString() 和 toLocaleTimeString()。

• 中文短格式：date.toLocaleDateString('zh-CN') → '2025/10/1'
• 带时间与秒：date.toLocaleString('zh-CN', { hour12: false, hour: '2-digit', minute: '2-digit', second: '2-digit' })
• ISO 标准字符串（含时区）：date.toISOString() → '2025-10-01T00:00:00.000Z'（注意：只对 UTC 有效）

真正难的不是调用哪个方法，而是意识到 Date 对象内部始终以毫秒数存储，而所有 get/set 方法都受本地时区影响——哪怕你只处理日期不涉及时间，new Date('2025-10-01') 在东八区和西五区得到的毫秒值也不同。跨时区场景下，务必明确你是在操作“日历日期”还是“绝对时间点”。