js格式化时间：把时间戳变成人看得懂的字符串

先搞清楚 Date 对象里那些反直觉的细节

很多人第一次写日期格式化，卡住的不是拼接字符串，而是 Date 的取值规则。

getMonth() 返回 0 到 11，所以一月拿到的是 0；getDate() 才是「几号」，而 getDay() 是星期几。名字相近，含义差得远，写错一次就会在控制台里看到莫名其妙的月份。

另一个坑是时间戳的单位。Date.now() 给的是毫秒，但有些后端接口返回的是秒。直接塞进 new Date() 会得到一个离谱的年份，排查半天才发现少乘了一千。拿不准的时候，先打印一下数值的位数，心里就有数了。

还有 getYear()，它返回的是年份减去 1900 的结果，早就该被 getFullYear() 取代。看到老代码里用它，顺手改掉比较稳妥。

手写一个补零函数，比想象中更耐用

最朴素的做法是自己拼字符串：取年、月、日、时、分、秒，逐个补零，再按想要的顺序连起来。

补零逻辑可以抽成一个小函数：把数字转成字符串，长度不够就在前面加一个零。这样 9 变成 09，12 保持原样。写一次，后面到处复用。

```jsconst pad = n => String(n).padStart(2, '0');function format(date) {const d = new Date(date);return ${d.getFullYear()}-${pad(d.getMonth() + 1)}-${pad(d.getDate())} +${pad(d.getHours())}:${pad(d.getMinutes())}:${pad(d.getSeconds())};}```

这种写法的好处是完全可控：想改成斜杠分隔、想只保留到分钟、想加毫秒，改模板就行。缺点是要自己处理时区，因为 getHours() 取的是本地时间，服务器和用户不在同一时区时结果会不一样。

如果只需要展示给用户看，本地时间通常正合适；如果要把时间写进日志或传给后端，就得想清楚该用本地时间还是 UTC，对应的取值方法也不一样。

toLocaleString 与正则替换：两条更省事的路

不想手写拼接，可以借助 toLocaleString。它接受语言和选项参数，能直接输出带年月日时分秒的字符串，还能指定是否补零、用哪种日历。

不过它的输出格式受运行环境影响，不同浏览器、不同系统语言设置下结果可能不同。做国际化展示很合适，做需要稳定格式的导出或接口字段就不太合适。

另一条路是先拿到一个标准格式的字符串，再用正则替换。比如把 ISO 字符串里的 T 换成空格、去掉末尾的 Z 和毫秒部分，几行就完成。正则在这里的优势是灵活：想保留哪一段、想换哪种分隔符，改表达式即可。

这两种方式各有适用面，关键是想清楚输出是给人看还是给程序用。给人看的，格式宽松一点无妨；给程序用的，格式必须稳定可预期。

时区与解析：格式化之外更容易翻车的地方

格式化本身不难，难的是输入。new Date('2024-01-01') 这种只有日期的字符串，按规范会被当作 UTC 零点解析，而带时间的字符串又可能按本地时间处理。同一段代码在不同环境里差出几个小时，往往就出在这里。

稳妥的做法是明确传入年、月、日等数字参数，或者统一使用带时区偏移的 ISO 字符串。解析规则清楚了，格式化结果才稳定。

还有夏令时。某些地区在切换当天会出现某个小时不存在或重复的情况，用本地时间做加减运算时要留意。涉及跨时区业务时，建议在内部统一存 UTC，只在展示层转换成用户所在时区。

最后提醒一句：格式化函数最好只做展示，不要在格式化后的字符串上再做日期计算。字符串一旦脱离 Date 对象，比较大小和加减都会变得不可靠。

相关文章

• js格式化日期：为什么总差一点，怎么处理才稳

  从时区、补零到本地化输出，讲清 js格式化日期 的常见偏差来源与稳妥写法，附排查思路。

• js格式化年月日时怎么转换时间戳：从字符串到毫秒数

  讲解将年月日时格式的字符串转换为时间戳的几种方法，包括Date构造函数、手动解析和时区处理，并给出常见错误排查思路。

• js格式化字符串转换成时间戳：别让时区悄悄改了结果

  讲清日期字符串转时间戳的解析规则、时区陷阱与常见写法差异，帮助开发者在代码处理中少走弯路。

• js格式化字符串：从混乱到清晰的实用技巧

  介绍js格式化字符串的常见场景与处理方法，包括模板字符串、多行文本和占位符替换，帮助开发者写出更清晰的代码。

• js格式化xml：让杂乱XML可读的实用技巧

  介绍用JavaScript格式化XML的常见思路与注意点，帮助开发者处理接口返回的紧凑XML，提升调试与阅读效率。

常见问题