JavaScript 的 Date 构造函数对符合 ISO 8601 标准格式（如 "YYYY-MM-DD"）的字符串统一按 UTC 解析，而对非标准格式（如 "YYYY-M-D"）则依赖实现，通常按本地时区解析，导致相同逻辑下日期对象的时区行为不一致。
javascript 的 `date` 构造函数对符合 iso 8601 标准格式（如 `"yyyy-mm-dd"`）的字符串统一按 utc 解析，而对非标准格式（如 `"yyyy-m-d"`）则依赖实现，通常按本地时区解析，导致相同逻辑下日期对象的时区行为不一致。
在 JavaScript 中，new Date(dateString) 的行为并非完全直观——其解析逻辑严格区分标准化格式与非标准化格式，而这直接决定了时区处理方式。
✅ 标准格式：强制 UTC 解析
根据 ECMAScript 规范（ECMA-262 §21.4.1.18），仅当字符串精确匹配 Date Time String Format（即 YYYY-MM-DD 或 YYYY-MM-DDTHH:mm:ss.sssZ 等）时，引擎才以UTC 为基准解析：
console.log(new Date("2023-12-16")); // → 2023-12-16T00:00:00.000Z（UTC 零点）
console.log(new Date("2023-09-14")); // → 2023-09-14T00:00:00.000Z（UTC 零点）注意："2023-09-14" 中的 09 是两位月（含前导零），符合 MM 要求，因此被识别为标准格式。
⚠️ 非标准格式：本地时区 + 实现依赖
一旦格式偏离规范（例如 "2023-1-1" 或 "2023-9-14" 缺少前导零），引擎将放弃标准解析，转而使用实现特定的启发式规则（如 V8、SpiderMonkey 各有差异），但主流浏览器/运行时普遍按本地时区解释为“当天 00:00”：
立即学习“Java免费学习笔记（深入）”；
console.log(new Date("2023-1-1")); // → 2023-01-01T07:00:00.000Z（假设本地为 UTC-7）
console.log(new Date("2023-9-14")); // → 2023-09-14T06:00:00.000Z（假设本地夏令时 UTC-6）这就是你观察到“未来日期用 UTC、过去日期用本地时区”的根本原因——本质不是时间远近，而是字符串是否满足 YYYY-MM-DD 格式（M 和 D 必须为两位数）。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
✅ 正确实践：始终使用标准化格式或显式构造
为确保跨环境行为一致，请遵循以下原则：
-
推荐：使用带前导零的 ISO 格式
new Date("2023-01-01"); // ✅ 明确 UTC，无歧义 new Date("2023-12-25"); // ✅ 同上 -
避免：省略前导零或混合格式
new Date("2023-1-1"); // ❌ 非标准，本地时区，行为不可靠 new Date("2023/01/01"); // ❌ 实现依赖，部分环境可能失败 -
更稳健：用参数形式构造（完全规避字符串解析）
// 注意：月份索引从 0 开始（0 = 一月） new Date(2023, 0, 1); // → 2023-01-01T00:00:00.000（本地时区） new Date(Date.UTC(2023, 0, 1)); // → 2023-01-01T00:00:00.000Z（UTC）
? 小结
Date 构造函数的字符串解析是 JavaScript 中最易踩坑的特性之一。其核心规则简单却关键：只有严格符合 YYYY-MM-DD 的字符串才保证 UTC 解析；其余皆属未定义行为。在 Office Scripts、Node.js 或浏览器环境中，统一使用零填充 ISO 格式，或改用数值参数构造，是保障日期逻辑可预测、可移植的唯一可靠方案。
