始终用UTC处理和存储时间，展示时再转换为目标时区。前后端交换时间使用ISO 8601格式（如2025-04-05T10:00:00Z），确保时间纯净无歧义。避免依赖用户本地时间，关键时间由服务端提供UTC时间。推荐使用Luxon或Day.js处理时区转换，原生Date易出错。展示非本地时间时应标注时区，如(GMT+8)或EDT，可借助Intl.DateTimeFormat自动格式化。统一团队时间库和使用规范，减少跨时区问题。
JavaScript 中处理时间和时区看似简单，但一不小心就会踩坑，尤其是在涉及跨时区展示、存储或计算时间的场景。核心原则是：始终用 UTC 处理和存储时间，仅在展示时转换为本地或目标时区。以下是实用的最佳实践。
使用 ISO 8601 格式进行数据交换
前后端传递时间时，统一使用 ISO 8601 格式（如 2025-04-05T10:00:00Z），它明确表示 UTC 时间，避免歧义。
- 从服务器获取的时间应为带 Z 后缀或含时区偏移的字符串
- 前端发送给后端的时间也应转为 UTC 并格式化为 ISO 字符串
- 避免使用 new Date().toString() 或非标准格式
避免依赖系统本地时间进行关键逻辑
用户设备的本地时间可能被手动修改或时区设置错误，不能用于时间比较、过期判断等关键操作。
- 重要时间点（如订单创建、Token 过期）应由服务端提供 UTC 时间
- 前端可使用相对时间库（如 dayjs 或 luxon）结合服务器时间做本地渲染
- 不要用 new Date() 直接参与业务逻辑判断
用 Luxon 或 Day.js 替代原生 Date 处理时区
原生 Date 对象不支持任意时区转换，推荐使用现代时间库。
立即学习“Java免费学习笔记（深入）”；
Luxon 支持 IANA 时区名（如 Asia/Shanghai），适合复杂时区操作：
const { DateTime } = require('luxon');const dt = DateTime.fromISO('2025-04-05T10:00:00Z', { zone: 'utc' });
const beijingTime = dt.setZone('Asia/Shanghai');
console.log(beijingTime.toFormat('yyyy-MM-dd HH:mm')); // 输出北京时间
Day.js 轻量，配合 timezone 插件也能完成常见转换：
dayjs.extend(timezone);dayjs.extend(utc);
const timeInShanghai = dayjs.utc('2025-04-05T10:00:00').tz('Asia/Shanghai');
展示时间时明确标注时区
当显示非本地时间时，加上时区缩写或偏移量，避免误解。
- 会议时间可显示为 2025-04-05 18:00 (GMT+8)
- 使用 Intl.DateTimeFormat 自动格式化并包含时区信息
- 示例：
new Intl.DateTimeFormat('zh-CN', {
timeZone: 'America/New_York',
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
timeZoneName: 'short'
}).format(new Date())
// 输出类似 "2025/04/05 06:00 AM EDT"
基本上就这些。关键是保持时间数据的“纯净”——用 UTC 存储和传输，展示时再按需转换。选一个可靠的时间库，统一团队的使用方式，能大幅减少问题。不复杂但容易忽略。
