企业官网建设流程全解析

1. 为什么前端日期格式化总在“翻车”，以及 Intl.DateTimeFormat 能解决什么

1.1 日期格式化的真实痛点

作为前端开发，日期格式化几乎是每天都要打交道的基础操作。后端接口返回的时间格式五花八门，有 ISO 字符串、时间戳、UTC 时间、带时区的 RFC 2822 格式，到了前端这一步，最终都得转换成用户习惯的“2024-01-01 20:00:00”或“2024年1月1日”这样的展示形态。

但这个看似简单的工作，实际写起来远比想象中容易出问题。最常见的几类坑：

• 月份从 0 开始。new Date().getMonth()返回的是 0 到 11，不是 1 到 12，新手经常忘掉+1，结果页面上永远显示比实际少一个月。
• 补零逻辑重复写。getHours()返回9而不是09，为了显示09:05:03，每次都得拼一层String(n).padStart(2, '0')或者三元判断。
• 时区转换靠猜。后端存的是 UTC 时间，前端直接调用getHours()拿到的是本地时区时间，用户在北京看到的和在上海看到的不一样，甚至和产品经理看到的都不一样。
• 多语言和本地化规则难以统一。中文环境“2024年1月1日”，英文环境是“Jan 1, 2024”，如果项目还涉及阿拉伯语、日语等，手写一套规则表会让人崩溃。
• 高频刷新场景下的性能问题。大屏页面每秒格式化一次时间，每次都重新计算字符串拼接，性能和维护成本都很难看。

这些问题不是某个框架能解决的，也不是简单地引入一个第三方库就能一劳永逸。本质上前端需要一个“标准化”的格式化能力：告诉它语言环境、时区、展示精度，它自动处理补零、月份、星期、时区等细节。这就是原生 APIIntl.DateTimeFormat存在的意义。

1.2 Intl.DateTimeFormat 到底是什么

Intl是 JavaScript 内置的“国际化”对象，不是第三方库，也不属于某个框架。它是 ECMAScript 标准的一部分，所有现代浏览器和 Node.js 环境都直接支持。Intl.DateTimeFormat是Intl下专门负责日期时间格式化的构造函数。

一句话解释：你给它传一个语言区域，再告诉它你想显示到“年、月、日”还是“小时、分钟、秒”，它负责把所有格式化规则处理好，直接返回一个格式化函数。

const formatter = new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); console.log(formatter.format(new Date())); // 2024/01/01 20:05:03

注意这个输出，年月日之间是/而不是-，这正是中文区域默认的日期分隔风格。如果你需要-，不能直接靠Intl.DateTimeFormat的输出字符串，需要额外处理，这个在后面的实战部分会专门说。

它的核心价值不只是“省掉了几行补零代码”，而是把语言、时区、日历类型（中国用户可能还会用到农历、日本用户可能用到和历）这些非常复杂的国际规则，全部交给语言运行时去处理。你不需要知道中文里“周一”和“星期一”的差异，也不需要知道英文里简写月份规则，只需要声明“我要哪个区域、哪个精度”，剩下的交给它。

2. 从构造到调用：Intl.DateTimeFormat 核心用法详解

2.1 构造参数和基本调用

Intl.DateTimeFormat的构造语法是new Intl.DateTimeFormat(locales, options)。两个参数都可选，但实际使用中基本都会传。

locales参数用来指定语言区域，常见的有：

• 'zh-CN'：中国大陆简体中文。
• 'zh-TW'：中国台湾繁体中文。
• 'en-US'：美国英语。
• 'en-GB'：英国英语。
• 'ja-JP'：日语。
• 也可以传数组，按优先级匹配，比如['zh-CN', 'en-US']，系统会优先使用第一个能解析的区域。

如果不传locales，会采用运行环境默认区域。这一点在写代码时很容易埋雷：你的电脑是中文系统，看起来没问题，但用户如果是英文环境，显示出来的格式就会完全不一样。所以只要是涉及展示给真实用户看的时间，建议显式指定。

第二步是options，它决定格式化的精度和风格。最常用的基础配置是分别指定年、月、日、时、分、秒：

const formatter = new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false });

字段对应的取值主要有'numeric'和'2-digit'两种。numeric表示数字正常显示，2-digit表示不足两位前面补零。比如day: 'numeric'显示1，day: '2-digit'显示01。

拿到 formatter 实例后，有两种调用方式：

// 方式一：调用实例的 format 方法 const result = formatter.format(new Date()); // 方式二：直接把实例作为函数调用（少数场景下会这么写） const result2 = formatter(new Date());

实际开发中推荐方式一，可读性更好。format方法接收的参数可以是Date对象，也可以是能被Date解析的时间字符串或时间戳。如果你拿到的是后端返回的 ISO 字符串，可以直接传进去：

formatter.format('2024-01-01T12:00:00Z');

这里有一个容易忽略的点：format本质上就是“解析时间 → 按规则输出”，它不会要求你提前把字符串转成Date，但内部会做转换。如果字符串格式不合法，会抛出RangeError，一定要注意异常处理。

2.2 options 里的高频选项说明

除了最基础的年月日时分秒，options里还有几个非常实用的配置项。

dateStyle和timeStyle是组合式快捷配置，取值都是'full'、'long'、'medium'、'short'。用它们可以快速输出比较完整的本地化日期和事件描述：

new Intl.DateTimeFormat('zh-CN', { dateStyle: 'full' }).format(new Date()); // 2024年1月1日星期一 new Intl.DateTimeFormat('zh-CN', { timeStyle: 'medium' }).format(new Date()); // 20:05:03 new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date()); // Monday, January 1, 2024

注意：dateStyle和单独指定year/month/day不能同时使用。如果你写了{ dateStyle: 'full', year: 'numeric' }，会抛TypeError。选择哪种方式取决于需求，通常业务系统要求精确到秒，建议用单独指定日期的字段；如果是做展示型文案，比如文章发布时间，用dateStyle更自然。

weekday用于显示星期几，取值'long'、'short'、'narrow'，分别对应“星期一”“周一”“一”。比如有些列表页希望在时间后面带上“周一”这种信息，用weekday会比手写数组判断靠谱得多。

timeZone是时区控制的核心，取值是 IANA 时区名，比如'Asia/Shanghai'、'UTC'、'America/New_York'。这个字段非常重要，尤其是后端存的是 UTC 时间、用户分布在各个地区时，用它可以直接转换展示。

new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }).format(new Date('2024-01-01T12:00:00Z')); // 2024/01/01 20:00:00

如果后端存的是 UTC12:00:00，北京时区展示成20:00:00，这个逻辑完全不需要自己手动做“加 8 小时”的操作。

hour12和hourCycle控制 12 小时制还是 24 小时制。hour12: true会显示上午/下午标记，hour12: false强制 24 小时制。hourCycle的取值更细，有'h11'、'h12'、'h23'、'h24'，一般业务场景用hour12就够了。

timeZoneName用于显示时区名称，取值'short'或'long'，输出像“GMT+8”或“中国标准时间”，通常在后台系统的审计日志场景里会有价值。

下面的表格可以快速帮助回忆：

2.3 formatToParts 与 resolvedOptions：两个容易被忽略的 API

很多开发者用Intl.DateTimeFormat只调用一个format方法，等到需要单独把月份提取出来、或者想要自定义拼接格式时，才发现 string 已经定死，只能正则替换。这时候formatToParts就派上用场了。

formatToParts返回一个数组，把格式化结果拆成独立片段，每段有type和value：

const formatter = new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); const parts = formatter.formatToParts(new Date()); console.log(parts); // [ // { type: 'year', value: '2024' }, // { type: 'literal', value: '/' }, // { type: 'month', value: '01' }, // { type: 'literal', value: '/' }, // { type: 'day', value: '01' }, // { type: 'literal', value: ' ' }, // { type: 'hour', value: '20' }, // { type: 'literal', value: ':' }, // { type: 'minute', value: '05' }, // { type: 'literal', value: ':' }, // { type: 'second', value: '03' } // ]

利用它，你可以把/分隔符替换成任意想要的符号，也可以单独提取月份做“只看月份”的筛选场景。比如想输出2024-01-01 20:05:03，可以这么拼：

function formatDateTime(dateStr) { const parts = new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }).formatToParts(new Date(dateStr)); const data = {}; parts.forEach((part) => { if (part.type !== 'literal') { data[part.type] = part.value; } }); return `${data.year}-${data.month}-${data.day} ${data.hour}:${data.minute}:${data.second}`; } formatDateTime('2024-01-01T12:00:00Z'); // 2024-01-01 20:00:00

另外一个方法resolvedOptions()用来查看当前 formatter 实际生效的配置，包括语言、时区、日历等。排查问题时特别有用：

const formatter = new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', year: 'numeric' }); console.log(formatter.resolvedOptions()); // { // locale: "zh-CN", // calendar: "gregory", // numberingSystem: "latn", // timeZone: "Asia/Shanghai", // year: "numeric", // ... // }

当你发现格式化结果和自己预期不符，先resolvedOptions()看一下实际生效的时区和区域，往往能立刻定位问题。

3. 除了 Intl.DateTimeFormat，还有哪些方案可选

3.1 toLocaleString：真香但也真的容易被误解

Date.prototype.toLocaleString可能是最早接触到的原生格式化 API。很多新手会疑惑：既然有toLocaleString，为什么还要用Intl.DateTimeFormat？

实际上toLocaleString底层调用的就是Intl.DateTimeFormat，只是它更像一个“语法糖”。它接收两个参数，其实对应locales和options：

new Date().toLocaleString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false });

它的优点是写法更简洁，缺点也很明显：没法复用 formatter 实例，每次调用都会重新做一次配置解析，高频场景下性能不如Intl.DateTimeFormat的实例复用。另外toLocaleString不同浏览器对空参数的处理有些细微差异，比如new Date().toLocaleString('zh-CN')在不同系统上可能分别输出2024/1/1 20:05:03和2024/01/01 20:05:03，这类环境差异非常磨人。

日常写 demo 和快速验证用toLocaleString没问题，但正式项目中如果同一时间格式需要在多个地方展示，我更建议直接建一个公共的 formatter 实例。

3.2 手写格式化函数：从补零到正则替换

在Intl.DateTimeFormat还没有被广泛使用的时候，前端最流行的做法是自己写一个格式化函数。思路很简单：通过正则替换模板字符串里的占位符。

function formatDate(date, template = 'YYYY-MM-DD HH:mm:ss') { const d = new Date(date); const pad = (n) => String(n).padStart(2, '0'); const map = { YYYY: d.getFullYear(), MM: pad(d.getMonth() + 1), DD: pad(d.getDate()), HH: pad(d.getHours()), mm: pad(d.getMinutes()), ss: pad(d.getSeconds()) }; return template.replace(/YYYY|MM|DD|HH|mm|ss/g, (match) => map[match]); }

这段代码相信很多前端都写过，甚至写到简历“通用工具函数”里。它确实灵活，模板只要改一个字符串就能输出不同格式。但问题也明显：

• 时区逻辑是硬编码的，getHours()只能取本机时区。要把 UTC 字符串转成北京时间，得额外判断，容易出错。
• 多语言支持基本为零。换成英文环境，你依然只能输出数字，很难输出“Monday”“January”。
• 补零规则是自己维护的。如果模板里突然出现M想显示非补零月份，又要再写一层判断。

我并不是说手写函数不能用，而是它更适合“一次性、单语言、单时区”的小页面。项目一旦复杂起来，它的维护成本会指数上升。

3.3 dayjs 等第三方库：要不要为了格式化引入一个库

第三方库方案里最出名的是 moment.js 和 dayjs。moment.js 由于体积和历史包袱已经不怎么被新项目选用了，dayjs 凭借轻量（2KB 左右）+ 插件化成为目前主流。

import dayjs from 'dayjs'; dayjs('2024-01-01T12:00:00Z').format('YYYY-MM-DD HH:mm:ss'); // 2024-01-01 20:00:00

dayjs 的优势是 API 语义化，模板字符串直观，团队协作时阅读成本低；时区切换有专门的utc插件和timezone插件，表达能力比Intl.DateTimeFormat强不少。如果你项目里已经在用 dayjs 处理日期加减、比较等业务，那格式化用 dayjs 是顺手的事，没必要为了“原生”而原生。

但如果你只是想“格式化时间”，而项目里还没有引入任何日期库，那我建议优先考虑Intl.DateTimeFormat。原因很现实：引入第三方库意味着包体积增加、版本管理成本增加、维护者变动后团队学习成本增加。为了一个格式化需求引库，性价比不高。

当然，面试时如果对方问“为什么用原生 API 不用 dayjs”，不要只回答“原生 API 更好”，更要说明场景取舍：项目属于轻量场景用原生，复杂业务用 dayjs 或 date-fns，双方互补，这才是正常的工程思维。

3.4 一张表看清几种方案的取舍

简单总结：没有所谓“最好的方案”，只有“当前项目最合适的方案”。选型的核心判断标准永远是：时间格式化的复杂度、团队的维护习惯、以及是否已经存在同类依赖。

4. 实际场景中的格式化实战：订单页、UTC 转换与国际化

4.1 订单列表时间格式化

绝大多数中后台页面都逃不掉订单时间展示。后端给的常见字段是 ISO 字符串，比如createdAt: "2024-01-01T12:00:00Z"，前端列表里要展示成“2024-01-01 20:00:00”。

网上很多方案是new Date(createdAt).toLocaleString('zh-CN')，但注意它输出的是2024/1/1 20:00:00，和 UI 稿上的“2024-01-01 20:00:00”大概率对不上。直接用formatToParts拼接，或者用一个公共工具函数处理：

const dtf = new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); function formatDateTime(input) { const parts = dtf.formatToParts(new Date(input)); const values = {}; parts.forEach((part) => { if (part.type !== 'literal') values[part.type] = part.value; }); return `${values.year}-${values.month}-${values.day} ${values.hour}:${values.minute}:${values.second}`; }

这里我把dtf定义在模块顶层，而不是每次调用都new一次，主要是为了复用实例。如果列表有几百条数据，每次都走一遍完整解析是有额外开销的。实测下来，在 1000 条数据渲染场景里，实例复用的耗时大约只有每次新建实例的三分之一不到，体感非常明显。

4.2 UTC 时间如何正确转成北京时间

很多前端第一次处理国际业务时，都会犯一个错误：直接new Date(utcStr).getHours() + 8。这看起来很“合理”，因为北京在东八区，UTC 加八小时就是北京时间。但问题在于：

• 如果用户的系统时区本身就不是 UTC，getHours()返回的已经是本地时间，再加 8 就重复加了。
• 如果涉及夏令时区域，固定加几小时根本说不准。
• 如果字符串带偏移量，比如2024-01-01T12:00:00+05:00，手动算更是自找麻烦。

正确姿势是把“时间展示”交给Intl.DateTimeFormat的timeZone配置：

const formatter = new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); console.log(formatter.format(new Date('2024-01-01T12:00:00Z'))); // 2024/01/01 20:00:00

你不需要关心用户的设备时区是什么，只需要明确“我要展示的是北京时间”。这套逻辑对多地区部署尤其友好，哪怕后端服务器跑在海外，前端展示依然稳定。

如果还要显示“美国东部时间”“东京时间”，把timeZone换成'America/New_York'、'Asia/Tokyo'即可，不需要额外写任何转换函数。

4.3 大屏、多语言场景下怎么一起用

大屏项目对时间刷新频率非常高，通常每秒更新一次。这时如果每次渲染都new Intl.DateTimeFormat(...)，虽然现代浏览器性能不至于崩，但长时间跑下来会产生无意义的对象创建和 GC 压力。建议在模块初始化时创建好 formatter，后续只调用format()：

const timeFormatter = new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }); function updateClock() { document.querySelector('#clock').textContent = timeFormatter.format(new Date()); } setInterval(updateClock, 1000);

多语言项目（国际化）场景下，Intl.DateTimeFormat的价值就体现得更明显了。假设状态管理里有一个locale变量，切换语言时格式化函数要跟着变。最直观的做法是把它做成一个响应式 computed 或者用一个带缓存的工厂函数：

const formatterCache = new Map(); function getDateTimeFormatter(locale) { if (!formatterCache.has(locale)) { formatterCache.set(locale, new Intl.DateTimeFormat(locale, { year: 'numeric', month: 'long', day: 'numeric', weekday: 'long' })); } return formatterCache.get(locale); } getDateTimeFormatter('zh-CN').format(new Date()); // 2024年1月1日星期一 getDateTimeFormatter('en-US').format(new Date()); // Monday, January 1, 2024

这样一套代码，中文、英文、日文都能直接切，不需要手写字典。语言本身的复杂规则（比如日文的日期语序、阿拉伯文的数字符号）都由Intl内部处理，团队不用为这些细节投入额外维护成本。

有一点需要提醒：Intl.DateTimeFormat能很好处理“显示层面的本地化”，但它不会自动帮你翻译业务文案。比如“创建时间”这个 label，还是需要走 i18n 方案，不要混淆分工。

5. 踩坑实录与面试高频问题

5.1 兼容性：哪些环境不支持 Intl

Intl.DateTimeFormat并不是所有运行时都原生支持。现代浏览器（Chrome、Firefox、Safari、Edge）都没问题，但有两个常见场景要小心：

• 低版本 Android WebView（Android 4.4 左右）和 iOS 10 以下的部分版本，对Intl支持不完整，某些options直接无效。
• 较老版本的 Node.js（比如 0.10、0.12）默认不带Intl，服务端渲染时必须确认环境版本。

如果项目要兼容低端设备，又确实想用Intl.DateTimeFormat，可以引入intlpolyfill，或者退回到 dayjs。另外一个思路是检测当前环境是否支持目标选项，不支持时用toLocaleString兜底，但这个兜底本身行为也不统一。

我的建议是：先明确项目的浏览器兼容范围，再决定用哪条路。如果公司内部系统明确只跑 Chrome，那完全可以放心用Intl.DateTimeFormat；如果是面向大量低端安卓机的 C 端页面，手写函数或者 dayjs 反而更省心。

5.2 为什么我格式化出来的月份看起来不对

一个容易被忽略的细节是：new Date()解析字符串遇到“无时区信息”的日期时，行为在不同浏览器之间是有差异的。比如new Date('2024-01-01')，在多数浏览器中解析为 UTC 时间，而new Date('2024/01/01')解析为本地时间。如果你在 UTC 时间基础上调用本地时区的方法，能看到的时间就可能是前一天。

另外，getMonth()返回 0 到 11 的问题前面提过，手写函数时很容易踩。但Intl.DateTimeFormat内部会用正确规则处理月份，很少出现月份错乱。如果你用Intl.DateTimeFormat还是发现月份不对，优先检查输入字符串本身是否带了时区偏移，而不是怀疑格式化逻辑。

举个例子：

new Intl.DateTimeFormat('zh-CN', { month: 'long' }).format(new Date('2024-01-01T00:00:00Z')); // 在 UTC+8 环境下输出“1月”，没毛病

但如果写成new Date('2024-01-01')，在 UTC+8 区域解析成 UTC 时间的2024-01-01 08:00:00，展示依然是 1 月，不会出大问题，可一旦日期靠近临界点，比如'2024-01-01T00:00:00'，就很容易“跨天”，所以统一建议后端接口返回 ISO 字符串，并且显式带时区后缀。

5.3 “24:00:00”与午夜的边界问题

用 24 小时制的时候，凌晨零点的展示有时候会奇怪。某些区域设置和浏览器组合下，hour: '2-digit'配合hourCycle: 'h24'，可能会输出24:00:00而不是00:00:00。

这不算 bug，因为h24循环里凌晨就是24:00:00，但大多数业务系统更习惯从00:00:00开始。解决办法也很简单：不要把hourCycle强制设成h24，用默认hour12: false就行。

new Intl.DateTimeFormat('zh-CN', { hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }).format(new Date('2024-01-01T00:00:00')); // 00:00:00

个别情况下hour12: false在英文区域也不会出问题，所以推荐优先使用hour12: false，别手动去碰hourCycle。

5.4 面试题里的时间格式化陷阱

最近两年面试前端，日期格式化几乎成了“手写题”环节的常客。这里整理几道高频题目，以及对应的答题思路。

第一道：手写一个格式化函数，支持YYYY-MM-DD HH:mm:ss。这类题考察的是基础日期 API 的熟练度，以及对getMonth() + 1、补零、正则替换是否熟悉。写完后可以主动提一句：“这套实现基于本地时区，如果需要指定时区，建议改用 Intl.DateTimeFormat。”这句话会显得你边界感很强。

第二道：后端返回2024-01-01T12:00:00Z，如何在前端展示为北京时间？如果只是回答new Date(str)后转字符串，面试官大概率会追问“如果用户机器不在中国时区呢”。更完整的回答是先new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai', ... })，再解释timeZone的作用，最后补一句“也可以配合 formatToParts 自定义拼接格式”。

第三道：1000 条数据的列表页，每条都要格式化时间，如何优化？考察点是性能意识。答案核心是“复用 formatter 实例”，而不是每次循环都new Intl.DateTimeFormat(...)。如果有更高的渲染性能要求，还可以考虑用Intl.DateTimeFormat格式化一次后只做字符串缓存，或者直接交给虚拟列表处理。

第四道：Intl.DateTimeFormat和toLocaleString有什么区别？答清楚“toLocaleString 是语法糖，底层走 Intl.DateTimeFormat；DateTimeFormat 能复用实例，性能和一致性更好”就够了。不要为了贬低 one 而过度吹捧另一个，工程上说清楚取舍更重要。

第五道：时区固定显示为纽约时间怎么写？直接给timeZone: 'America/New_York'的完整示例，并说明 IANA 时区名和 UTC 偏移量的区别。如果能顺带提一句“夏令时由运行时自动处理”，面试官会觉得你确实写过国际业务。

这五道题如果能自行组织语言讲透，说明对格式化这件事已经不再是“背 API”，而是真正理解了。

6. 结合工程实践的个人建议

写了这么多，最后分享一点个人经验。很多开发者一听到“原生 API”就认为一定要用，一听到“第三方库”就认为不纯粹，其实工具选型从来不是立场问题。我在实际项目中的判断标准很简单：

• 如果只是中后台管理系统，展示格式比较统一，优先用Intl.DateTimeFormat，公共函数封装好，够用且零依赖。
• 如果项目已经引入 dayjs，业务上有大量日期加减、比较、倒计时计算，那就直接用 dayjs 的format()，省得两套体系并行反而混乱。
• 如果需要做多语言切换，且语言数量超过两种，Intl.DateTimeFormat是首选，千万别手写语言规则表。
• 如果需要兼容远古浏览器，再考虑 dayjs 或手写函数。

另外一个经常被忽略的点是：时间和时区本质上属于“数据契约”问题。前后端约定接口时，一定要明确所有时间字段到底是 UTC、带偏移的 ISO，还是“服务器本地时间”。这个约定不清晰，无论用哪种 API 格式化都会出问题。我见过太多团队前段用Intl.DateTimeFormat改得头头是道，结果后端返回的是服务器本地时间，前端还傻傻按 UTC 转，最后对不上账。

如果你正准备面试，建议把Intl.DateTimeFormat的formatToParts、resolvedOptions、timeZone这几个点都亲手跑一遍。仅仅知道format方法是不够的，面试官一个“如何自定义分隔符”就能问到这层。

最后再分享一个小技巧：排查日期相关 bug 时，第一步永远不是看代码，而是把后端返回的原始字符串原样打印出来，确认它有没有Z、有没有+08:00，再决定后续处理。这个习惯帮我少踩了很多坑。