如何使用JavaScript处理日期与时间【教程】_技术教程

JavaScript Date对象存在时区、解析和格式化缺陷，如ISO字符串被默认解析为UTC导致跨时区偏差，推荐显式指定时区或用Date.UTC构造，加减操作应避免直接修改原对象并注意夏令时影响，格式化宜手动拼接或使用date-fns等库。

JavaScript 的 Date 对象本身不提供格式化、时区转换或相对时间计算等常用能力，直接用它做业务逻辑容易出错——尤其在跨时区、夏令时、日期加减或字符串解析场景下。

为什么 new Date('2025-10-01') 在某些浏览器里变成 9 月 30 日？

这是因为 ISO 格式字符串（如 '2025-10-01'）被解析为 UTC 时间，再转成本地时区显示。例如在中国（UTC+8），new Date('2025-10-01') 实际表示的是 UTC 时间 2025-10-01T00:00:00，对应北京时间 2025-10-01T08:00:00 —— 看起来没问题；但若传入 '2025-10-01T00:00:00'（带时间部分却无时区），不同浏览器可能按本地时区或 UTC 解析，导致不一致。

安全做法：显式指定时区，比如 new Date('2025-10-01T00:00:00+08:00')
更稳妥方案：用 new Date(Date.UTC(2025, 9, 1)) 构造 UTC 时间（注意月份是 0 起始）
避免依赖字符串解析，尤其是用户输入或后端返回的日期字段

如何正确做「今天
+ 7 天」这种计算？

直接改 date.setDate(date.getDate() + 7) 是可行的，但要注意它会**修改原对象**，且不处理跨月/跨年边界（其实会自动处理，但易被忽略）。更大的问题是：它基于本地时区，若需服务端对齐或跨时区一致性，应统一用 UTC 计算。

const date = new Date();
// ✅ 安全的本地时间加法（修改原对象）
date.setDate(date.getDate() + 7);
// ✅ 更清晰、不污染原对象的方式
const nextWeek = new Date(date);
nextWeek.setDate(nextWeek.getDate() + 7);
// ⚠️ 错误示例：date.getTime() + 7  24  60  60  1000 可能因夏令时偏移失效（如某地 DST 开始当天只有 23 小时）

如何把 Date 输出成 '2025-10-01 14:30' 这种格式？

Date.prototype.toLocaleString() 和 toISOString() 都有局限：toISOString() 固定输出 UTC 时间并带 Z 后缀；toLocaleString() 行为依赖运行环境语言和地区设置，不可控。

推荐用 date.getFullYear()、date.getMonth() + 1 等手动拼接，确保格式稳定
需要兼容老浏览器时，注意 date.toISOString() 在 IE8 及以下不可用
若项目已引入 moment 或 date-fns，优先用它们的格式化函数（如 format(date, 'yyyy-MM-dd HH:mm')），避免手写逻辑

function formatDateTime(date) {
  const y = date.getFullYear();
  const m = String(date.getMonth() + 1).padStart(2, '0');
  const d = String(date.getDate()).padStart(2, '0');
  const H = String(date.getHours()).padStart(2, '0');
  const M = String(date.getMinutes()).padStart(2, '0');
  return `${y}-${m}-${d} ${H}:${M}`;
}

时区问题最常踩的三个坑

几乎所有线上日期 bug 都和时区有关，尤其当后端用 UTC 存储、前端又用本地时间渲染时。

后端返回时间戳（如 1696118400000）是绝对值，new Date(1696118400000) 总是正确解析为对应 UTC 时间点的本地显示 —— 这个没问题
后端返回字符串 '2025-10-01T00:00:00' 没有时区标识，JS 会按本地时区解释，导致欧美用户看到的是 10 月 1 日凌晨，而日本用户看到的是 10 月 1 日上午 9 点
调用 date.toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' }) 并不能改变时间值本身，只是影响显示格式；若想把一个时间“当作”东八区时间来解析，必须先构造为该时区的 Date 对象（实际需借助 Intl.DateTimeFormat 或第三方库）

真正棘手的不是怎么写，而是搞清你操作的时间到底代表什么：是用户本地钟表上的时刻？还是服务器所在时区的瞬间？还是全球统一的 UTC 时间点？没理清这个，后面所有格式化、加减、比较都会埋雷。