17370845950

推荐使用 Intl.DateTimeFormat 进行安全、可本地化的日期格式化，它自动处理时区、语言和历法差异，避免手动拼接或 getMonth() 等易错方法；需显式指定 timeZone（如 'Asia/Shanghai'）确保一致性。

用 Intl.DateTimeFormat 做安全、可本地化的格式化

硬拼接字符串或手写 getYear()/getMonth() 容易出错（比如月份从 0 开始、年份返回 119 而不是 2019），Intl.DateTimeFormat 是现代浏览器和 Node.js（v14+）推荐的方案，自动处理时区、语言、历法差异。

• 中文环境下默认输出「2025年10月5日星期四」，英文环境是「Thursday, October 5, 2025」
• 指定 timeZone: 'Asia/Shanghai' 可避免用户本地时区干扰，尤其在服务端渲染或日志时间统一场景下必须显式设置
• 不要依赖 toString() 或 toDateString() —— 它们不接受自定义格式，且输出固定、不可本地化

const date = new Date('2025-10-05T14:30:00Z');
const formatter = new Intl.DateTimeFormat('zh-CN', {
  year: 'numeric',
  month: 'long',
  day: 'numeric',
  weekday: 'long',
  hour: '2-digit',
  minute: '2-digit',
  second: '2-digit',
  timeZone: 'Asia/Shanghai'
});
console.log(formatter.format(date)); // "2025年10月5日星期四 22:30:00"

用 toLocaleString() 快速取常用格式，但注意隐式行为

toLocaleString() 底层调用 Intl.DateTimeFormat，适合快速原型或调试，但参数松散，容易因环境不同导致结果漂移。

• date.toLocaleString('zh-CN') → 带时间的完整本地格式（含秒）
• date.toLocaleDateString('en-US') → 仅日期，如 "10/5/2025"
• date.toLocaleTimeString('ja-JP') → 仅时间，如 "22:30:00"
• 不传 locale 时，完全依赖运行环境系统设置，CI 环境或 Docker 容器中可能 fallback 到 en-US，造成测试不一致

手动格式化只在必要时使用：补零、自定义分隔符、兼容旧环境

当项目需支持 IE 或需要严格控制输出（如日志文件名 2025-10-05_14-30-00），才考虑手动拼接。务必对 getMonth() +1、getDate() 补零。

• getMonth() 返回 0–11，必须加 1；getFullYear() 比 getYear() 安全（后者返回距 1900 年偏移量）
• 用 String.prototype.padStart(2, '0') 补零，比 '0' + n 更可靠（避免 '0' + 5 → '05' 但 '0' + 12 → '012'）
• 避免用 moment.js：已进入维护模式，体积大，同功能可用 date-fns 或原生 API 替代

const d = new Date();
const y = d.getFullYear();
const m = String(d.getMonth() + 1).padStart(2, '0');
const day = 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');
console.log(`${y}-${m}-${day}_${h}-${min}-${s}`); // "2025-10-05_14-30-00"

时区处理最容易被忽略：UTC vs 本地 vs 指定时区

同一个 Date 对象，在不同时区调用 toISOString()、toLocaleString()、getTimezoneOffset() 会得到完全不同的字符串 —— 这不是 bug，是设计如此。关键在于明确你要表达的时间基准。

• date.toISOString() 总是返回 UTC 时间（末尾带 Z），适合存储和传输
• new Date(date.toISOString()) 在本地解析时仍按本地时区解释，不会“还原”为原始时区
• 若需将用户输入的「北京时间下午2点」转成 UTC 时间戳，必须显式传入 timeZone: 'Asia/Shanghai' 给 Intl.DateTimeFormat 或用 date-fns-tz 类库
• 服务器时间统一用 UTC 存储，前端展示时再按用户偏好时区格式化，避免跨时区逻辑混乱

时区和本地化不是锦上添花的选项，而是日期处理里最先要确认的前提；一旦假设错误，后续所有格式化、比较、计算都会偏离预期。