JavaScript Date 对象需区分 UTC 与本地时区：toISOString() 返回 UTC 标准化字符串，toLocaleString() 返回本地时区不可控格式；安全加 7 天用 setDate()，格式化 "YYYY-MM-DD" 应手动取年月日补零。
JavaScript 原生 Date 对象本身不提供安全、可读的格式化方法，直接拼字符串或用 toString() 会受时区和浏览器实现差异影响；日期计算（如加减天数、获取月初）也容易因忽略月份天数不均、闰年、时区偏移而出错。
为什么 new Date().toISOString() 和 new Date().toLocaleString() 结果不一样
前者返回 UTC 时间的标准化字符串（"2024-05-20T08:30:00.000Z"），后者返回**本地时区**下的格式化结果，且格式不可控（比如中文系统可能带“年/月/日”，英文系统用斜杠或短横）。两者本质不是同一时间点的“不同写法”，而是不同时间基准（UTC vs 本地）。
- 跨时区应用（如后台 API 期望 UTC）必须用
toISOString()或手动调getUTCFullYear()等 UTC 系列方法 - 仅用于页面展示且无需精确时区语义时，
toLocaleDateString({ year: 'numeric', month: '2-digit', day: '2-digit' })更可靠 - 避免用
new Date().toString().substring(0, 15)截取——不同环境返回长度和分隔符可能不同
如何安全地给日期加 7 天（不踩时区坑）
直接改 date.setDate(date.getDate() + 7) 是正确做法，它操作的是“本地日期值”，不会触发时区换算。但要注意：如果原始 Date 对象是通过字符串（如 "2024-05-20"）创建的，它会被解析为 UTC 零点，再转成本地时间——这会导致意外偏移。
Pilot Digital Twin Setup
下载
部署一个包含 4 个智能体（agent）的数字孪生平台。在以下情况下使用该技能： 1. 用户希望为物理资产监控与预测性维护等场景搭建数字孪生系统……
- 从字符串初始化日期时，显式指定时区：
new Date("2024-05-20T00:00:00")（ISO 格式默认 UTC）或new Date("2024-05-20T00:00:00+0800") - 若需纯日期运算（忽略时间部分），先归零时间：
date.setHours(0,0,0,0); date.setDate(date.getDate() + 7); - 不要用毫秒加减（
date.getTime() + 7*24*60*60*1000）——夏令时切换日可能导致误差（比如某地少/多 1 小时）
格式化成 "YYYY-MM-DD" 最简稳方案
不用第三方库时，手写格式化最稳妥的方式是分别取年月日并补零，而非依赖 toJSON() 或正则截取——因为 toJSON() 仍返回带时间的 ISO 字符串，而 Date 构造函数对非标准字符串解析行为不一致。
立即学习“Java免费学习笔记（深入）”；
function formatDate(date) {
const y = date.getFullYear();
const m = String(date.getMonth() + 1).padStart(2, '0');
const d = String(date.getDate()).padStart(2, '0');
return `${y}-${m}-${d}`;
}
-
getMonth()返回 0–11，必须 +1 -
padStart(2, '0')比slice(-2)更直观且无隐式类型转换风险 - 此函数输出与本地日期一致；若需 UTC 版本，改用
getUTCFullYear()、getUTCMonth()、getUTCDate()
真正麻烦的从来不是“怎么写”，而是“什么时候该用本地时间、什么时候该用 UTC”。一个 Date 对象内部始终存的是毫秒数（自 1970-01-01T00:00:00Z 起），所有 getter 方法只是视角切换——选错视角，格式化和计算就全偏了。
