先记住这个答案
创建Intl.DateTimeFormat实例时，在options对象中设置timeZone为合法的IANA标识符，例如America/New_York。未指定时，格式化使用宿主环境的默认时区。不同运行环境（Node、浏览器）的ICU数据覆盖可能有差异，但常用城市基本一致。用法简单：先构造格式化器，再调用format(date)。
- timeZone必须用IANA标识符，否则抛RangeError
- 不设置timeZone时使用环境的默认时区
- Node和浏览器的时区支持范围并非完全一致
timeZone如何改变格式化结果
Intl.DateTimeFormat使用ICU的时区数据库。Date对象内部只保留从1970-01-01T00:00:00Z起的毫秒偏移。格式化时，它根据timeZone指定的时区标识符在数据库中查询，获得该时区在当前时刻的UTC偏移量与夏令时规则，进而计算出对应的年、月、日、时、分、秒。整个过程不修改原Date对象，每一次调用format都基于同一个UTC时间戳重新换算。
如果省略timeZone，则默认采用宿主环境的系统时区。这意味着同一时间戳在不同用户的电脑上会显示为各自本地时间，在服务器上则显示为服务器时区。timeZone只接受IANA标识符，例如'Europe/London'，不接受'GMT+1'或'UTC+08'这类数值偏移写法，否则会抛出RangeError错误。
跨时区会议时间的统一展示
假设后端返回一个会议开始时间为'2024-03-10T18:00:00Z'的UTC时间戳，前端需要分别显示北京和纽约的当地时间。由于纽约在2024年3月10日恰逢夏令时切换（从EST变为EDT），直接写死偏移量会出错。正确做法是创建两个格式化器：一个设置timeZone:'Asia/Shanghai'，另一个设置'America/New_York'，并且统一指定日期与时间样式。然后对同一个Date对象调用各自的format方法，就能得到预期结果。
这个场景的关键在于选择城市而不是固定偏移。因为固定偏移无法应对冬夏令时切换，而IANA标识符关联了时区历史规则，能自动区分该时刻是采用-05:00还是-04:00。若使用'Asia/Shanghai'，则不会因夏令时导致变化，结果稳定。这就是为什么生产环境推荐用timeZone而非手动计算偏移。
时区数据缺失与解析失败的处理
当timeZone字符串不是合法IANA名时，构造函数会立刻抛出RangeError，例如'Asia/Calcutta'已废弃且被重命名的旧标识符会让现代ICU报错。另外，某些嵌入式或裁剪版Node环境仅编译了small-icu，只包含少量时区，遇到冷门区域可能会回退到'UTC'甚至抛出错误，这会直接影响格式化结果的正确性。
稳妥做法是用try...catch包裹构造代码，捕获到异常后，通过Intl.DateTimeFormat().resolvedOptions().timeZone获取当前环境默认时区作为备选。同时，在开发或部署前建立一份测试矩阵，覆盖目标产品实际会用到的Node版本和浏览器版本，确认所需的时区标识符均在支持列表中。若确实存在缺口，可以考虑引入polyfill或后端预格式化，但那样会引入额外复杂度。
容易答错的地方
- 误将UTC偏移量作为timeZone值
- 有人写
timeZone:'UTC+8'，期望得到东八区时间。但规范明确要求IANA标识符，这种写法直接抛RangeError。正确的做法是使用'Asia/Shanghai'等别名，或使用'East_Timor'等规范名。即使某些环境中这种写法不报错，它也不符合标准，并不具备可移植性。 - 认为格式化之后Date对象会被改变
- 格式化操作只产生字符串，不会改变Date对象内部的毫秒时间戳。比如对同一Date分别采用'Asia/Shanghai'和'Asia/Tokyo'格式化，输出不同字符串是正常的，但date变量始终代表同一个时刻，其getTime()结果不变。如果有多次格式化需求，无需复制Date。
面试官还会怎么问？
如何获取用户当前时区的IANA标识符？
可以调用Intl.DateTimeFormat().resolvedOptions().timeZone得到类似'America/Los_Angeles'的字符串。这个API在主流浏览器和Node中都可用，无需额外库。如果运行环境禁用了某些时区，可能返回'UTC'。
timeZone选项对仅输出日期部分有什么影响？
同一个UTC时刻在纽约可能是3月9日深夜，但在上海已经是3月10日凌晨，导致日期字段不同。因此，如果应用需要按具体城市显示日期，必须同时配置timeZone，不能只靠本地时区的日期部分，否则会错一天。
Node.js是否需要额外安装才能支持全部IANA时区？
Node.js通常默认构建为small-icu，只包含少量常用时区。要获取全量时区，需要安装full-icu模块，或通过NODE_ICU_DATA环境变量指向完整ICU数据集。这样会增大内存占用，但能保证时区名的完整支持。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。