JS 开发避坑指南：getMonth() 返回的值为啥总是少 1？

深夜排查线上问题时，遇到过这样一个场景：产品经理反馈某个报表里的“本月统计”数据不对。用户明明选的是 3 月，系统显示的却是 2 月的数据。翻代码一看，问题就出在日期处理的那几行逻辑上——new Date().getMonth() 拿到的值是 2，而前端模板直接把它渲染成了月份。

这大概是每个 JavaScript 初学者都会踩的第一块“地雷”。

很多刚接触日期的开发者会凭直觉认为，getMonth() 方法理应返回 1 到 12 的数字，代表一月至十二月。但实际情况是，JavaScript 的 Date 对象沿用了类似 C 语言的传统，将一年中的月份定义为 从 0 开始计数。也就是说，0 代表 1 月，11 代表 12 月。这个设计确实有点反人类，尤其是当你需要直接把结果展示给用户看的时候。

想要拿到正确的月份数字，最直接的修正方案就是 +1。

const now = new Date();
const month = now.getMonth() + 1; 
console.log(month); // 比如今天是 5 月，输出 5

看起来简单，但这只是解决了数值上的偏差。在实际的前端界面中，我们往往还需要考虑字符串格式化的问题。如果直接使用上述数字拼接日期，会出现像 "2023-5-12" 这样的显示效果，而大多数 UI 规范更倾向于 "2023-05-12" 这种双位格式。这就需要我们手动进行补零处理。

比较稳妥的做法是利用 String.prototype.padStart 方法。它能在字符串左侧填充指定字符，直到达到目标长度。配合上面的 +1 逻辑，可以封装成一个通用的工具函数：

function getFormattedMonth(date) {
  const m = date.getMonth() + 1;
  return String(m).padStart(2, '0');
}

这样无论是一月到九月，都能稳定输出 "01" 到 "09"，避免了视觉上的参差不齐。

不过，依赖基础 API 做数学运算难免繁琐，随着 ES6 及后续标准的演进，其实有更现代的方案来应对本地化需求。特别是当你的应用需要支持多语言环境时，硬编码 "+1" 和补零逻辑就显得有些笨重了。

这时可以试试 Intl.DateTimeFormat 接口。它是国际化标准的一部分，能根据用户的浏览器区域设置自动调整日期格式，而且完全不需要关心月份是从 0 还是 1 开始计算的问题。

const formatter = new Intl.DateTimeFormat('zh-CN', { month: 'numeric' });
const monthStr = formatter.format(new Date()); 
// 在某些环境下可能返回 "5"，若需 "05" 可结合其他配置或保留手动处理

虽然 Intl 默认返回的数字有时不带前导零（取决于具体实现和 locale），但它最大的优势在于 解耦。你不再需要记忆各个方法的偏移量，也不用担心闰年或者不同地区对月份开始定义的差异。对于新项目来说，优先使用标准化 API 通常比手写逻辑维护成本更低。

当然，并不是所有情况都推荐用 Intl。如果在纯 Node.js 后端环境，或者为了追求极致的性能且无需考虑多语言，传统的 getMonth() + 1 依然是高效之选。关键是要在团队协作中约定好：凡是调用此方法，必须明确知道它的返回值范围是 0-11。

为了避免日后类似的 Bug 再次发生，建议在项目中建立统一的日期处理模块。把“加 1"、“补零”、“转字符串”这些细节全部收敛在这个模块内部，业务代码只负责调用结果。这样一来，即便未来切换成新库，也不需要改动上层逻辑。

写代码不仅是与机器对话，更是与未来的自己合作。理解 getMonth 背后的机制，比单纯记住答案更重要。毕竟，API 可能会更新，但底层的逻辑陷阱始终在那里等着疏忽的人。下次再处理日期时，记得先确认一下那个小小的月份数字，别让它成为隐藏的逻辑漏洞。