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，非标准格式走本地时区。这一差异是许多日期逻辑出错的根源，尤其在 Office Scripts、Node.js 或跨浏览器场景中极易引发隐性 Bug。
✅ 标准格式：严格按 UTC 解析
根据 ECMA-262 规范，仅当字符串精确匹配 YYYY-MM-DD（月、日必须为两位数，含前导零）或完整 ISO 格式（如 YYYY-MM-DDTHH:mm:ss.sssZ）时，引擎才将其视为“Date Time String Format”，并强制以 UTC 为基准解析：
console.log(new Date("2023-12-16").toISOString()); // "2023-12-16T00:00:00.000Z"
console.log(new Date("2023-09-14").toISOString()); // "2023-09-14T00:00:00.000Z"
console.log(new Date("2023-01-01").toISOString()); // "2023-01-01T00:00:00.000Z"所有结果均为对应日期的 UTC 零点，与时区无关。
⚠️ 非标准格式：本地时区 + 实现依赖
一旦格式偏离规范（例如 "2023-1-1" 或 "2023-9-14"，缺少前导零），引擎将放弃标准解析，转而启用实现特定（implementation-defined）启发式解析。此时行为由运行环境决定，但主流引擎（V8、SpiderMonkey 等）普遍按本地时区解释为午夜：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
// 假设你在 UTC-7（如美国山地时间）：
console.log(new Date("2023-1-1").toISOString()); // "2023-01-01T07:00:00.000Z"
console.log(new Date("2023-9-14").toISOString()); // "2023-09-14T06:00:00.000Z" （夏令时 UTC-6）注意："2023-1-1" → 07:00 UTC 表明本地时间 2023-01-01 00:00 被转换为 UTC+7；而 "2023-9-14" → 06:00 UTC 则反映夏令时偏移变化（UTC-6）。这种波动性正是问题核心。
? 正确实践：始终使用标准化格式
为确保跨环境一致性，请强制补零，或改用更安全的构造方式：
// ✅ 推荐：显式标准化（兼容所有环境）
const date1 = new Date("2023-12-16"); // 标准格式 → UTC
const date2 = new Date("2023-01-01"); // 注意：必须是 "01"，非 "1"
// ✅ 更健壮：手动构造（完全规避字符串解析歧义）
const date3 = new Date(2023, 11, 16); // 注意：月份从 0 开始（11 = 十二月）
const date4 = new Date(2023, 0, 1); // 2023-01-01
// ✅ TypeScript/现代项目：考虑使用 luxon 或 date-fns（明确时区语义）
import { DateTime } from 'luxon';
const dt = DateTime.fromISO("2023-12-16", { zone: 'utc' });? 关键总结
-
"YYYY-MM-DD"是唯一被规范强制要求的字符串格式，且必须带前导零； - 任何偏差（如
"Y-M-D"）都会触发不可移植的本地解析，引入时区和夏令时不确定性； - 在 Office Scripts、自动化脚本等对时间精度敏感的场景中，绝不依赖
new Date("2023-1-1")这类写法； - 调试时善用
.toISOString()（返回 UTC 字符串）而非.toString()（返回本地时区字符串），避免混淆。
遵循标准化格式，是驯服 JavaScript 日期最简单、最可靠的法则。
