JavaScript原生Date对象易因时区、解析规则和API设计缺陷导致错误；应避免字符串解析，改用参数构造或带时区ISO格式，封装工具函数统一取值，加减天数优先用setDate()处理自然日，序列化用toISOString()，显示用toLocaleString()。
JavaScript 原生 Date 对象够用，但容易出错；真正需要的不是“怎么创建日期”，而是“怎么避免时区错乱、格式错位、跨月计算异常”。
为什么 new Date('2023-10-01') 在某些浏览器里变成 9 月 30 日？
因为 Date 解析字符串时，'YYYY-MM-DD' 格式被强制按 UTC 解析，再转成本地时区显示。比如你在北京，new Date('2023-10-01') 实际构造的是 UTC 时间 2023-10-01T00:00:00Z，对应北京时间是 2023-10-01T08:00:00 —— 看起来没问题；但如果你传的是 '2023-10-01T00:00:00'（带时间但无时区），它会被当作本地时间解析，行为不一致。
- 安全做法：用参数形式构造，
new Date(2023, 9, 1)（注意月份是 0 起始） - 或明确补时区：
new Date('2023-10-01T00:00:00+08:00') - 避免直接解析用户输入的字符串，先标准化为带时区的 ISO 格式
getMonth() 返回 0–11，但 getFullYear() 返回完整年份，怎么统一处理？
这是 Date API 的历史包袱，没有统一逻辑，只能靠记。更麻烦的是，getDay() 返回星期几（0=周日），而 getDate() 才是几号 —— 名称完全不提示差异。
- 别硬背，封装一个工具函数：
const getDateParts = (d) => ({ year: d.getFullYear(), month: d.getMonth() + 1, date: d.getDate(), day: d.getDay() }) - 需要格式化输出时，优先用
toLocaleDateString()配置options，而不是拼字符串 - 如果必须手动拼，月份和日期记得补零：
String(d.getMonth() + 1).padStart(2, '0')
如何安全地加减天数，避开 2 月 29 日或月末边界问题？
直接改 date.setDate(date.getDate() + 30) 看似简单，但遇到 1 月 31 日加 1 天，会自动进到 2 月 1 日；而 1 月 30 日加 3 天，也可能跳到 2 月 2 日 —— 这是预期行为，但很多人误以为“加 3 天就该是 2 月 2 日”，其实逻辑是对的。真正危险的是跨 DST（夏令时）或时区切换时毫秒计算偏差。
立即学习“Java免费学习笔记（深入）”；
- 加减天数用毫秒计算最稳：
new Date(date.getTime() + 30 * 24 * 60 * 60 * 1000) - 但要注意：跨 DST 时，某天可能只有 23 小时或 25 小时，所以“加 24 小时” ≠ “加 1 天”
- 业务上真要“加 N 个自然日”，还是用
setDate()，它内部已处理月末进位
时区处理：toUTCString()、toISOString()、toLocaleString() 到底该用哪个？
toISOString() 总是返回 UTC 时间的 ISO 字符串（末尾带 Z），适合存储和传输；toUTCString() 是老格式（Mon, 01 Jan 2023 00:00:00 GMT），基本不用；toLocaleString() 依赖运行环境时区，适合展示给用户，但不可用于计算或比较。
-
后端接口收发时间，一律用
toISOString()或带时区的 ISO 字符串 - 显示给用户时，用
toLocaleString('zh-CN', { dateStyle: 'medium', timeStyle: 'short' }) - 不要用
toString()—— 它返回本地时区字符串，格式不固定，无法解析回Date
最难的不是写对一行代码，而是所有环节都保持时区意识：构造、计算、序列化、反序列化、显示 —— 漏掉一环，时间就悄悄偏了。
