JS 基础篇：别把 getDate() 用成了“陷阱”

深夜排查线上 Bug，发现用户活动的截止提醒早推了整整一天。翻代码时只看到一行简单的 new Date().getDate()，却忽略了时区和格式转换的坑。很多前端开发在初学阶段都会觉得日期对象简单，直到被它看似反直觉的特性绊倒。其实，JavaScript 的日期处理逻辑并不复杂，关键在于理解每个方法背后的返回值含义。

Date 对象里的 getDate() 是高频调用方法，但它返回的仅仅是一个月中的第几天（1 到 31）。这一点常被新手与 getDay() 混淆。后者返回的是星期几（0 到 6），其中 0 代表周日。如果你本意是想取今天是星期几，却误用了 getDate()，拿到的结果完全是数字日期而非周数，逻辑判断自然就会失效。

日常开发中，最头疼的不是取值，而是补零。当你直接使用模板字符串拼接日期时，例如 ${date.getDate()}号，如果是每月 5 号，显示出来就是"5 号”而不是"05 号”。这在订单系统或时间轴展示里显得很不专业。解决思路是用 String.prototype.padStart，确保数字始终占两位：

const day = String(date.getDate()).padStart(2, '0');

仅仅关注天数还不够，构建完整日期字符串时，必须意识到月份从 0 开始计数。这是 JS 日期对象最著名的“槽点”。getMonth() 返回 0 代表一月，11 代表十二月。如果你直接拼接 YYYY-MM-DD 格式，不处理这个偏移量，生成的日期永远会比实际慢一个月。正确的写法是取出月份后手动 +1。

另一个隐蔽的问题出在时区上。默认情况下，new Date() 创建的是当前浏览器本地时间，而 getDate() 也是基于当地时间解析的。如果你的服务器位于东八区之外，或者需要统一计算国际标准时间，直接调用本地方法就会产生偏差。此时应优先使用 getUTCDate()，它基于 UTC 标准时间返回日份，配合后端统一时区策略能避免大量跨时区显示的逻辑漏洞。

除了手动拼接，其实 ES 提供了更优雅的替代方案。如果只是为了给用户展示友好日期，无需关心具体数值计算，toLocaleDateString() 是更好的选择。它能根据运行环境的语言设置自动格式化，比如在中国环境输出"2023/10/1"，在美国可能变成"10/1/2023"。这种方式不仅代码少，而且天然解决了补零和月份翻译问题，适合纯展示场景。

归根结底，JS 日期处理的核心不在于记忆 API，而在于明确数据流向。你需要确认自己是想要原始数值做计算，还是直接展示给用户看。做计算就保留数字精度，注意月份偏移；做展示就用本地化 API，让浏览器帮忙适配样式。理清了这个边界，那些莫名其妙的日期 Bug 自然也就消停了。掌握这些细节，能让你的代码在处理时间线、倒计时和日程管理时更加稳健。