【ES2026】前端必学（上）：终结日期 / 金额的 10 年之痛

场景 1：日程提醒的“周日陷阱”#

你写了个“每周一早上 8 点提醒”的功能：

1
// 用户设置：每周一 08:00
2
const reminder = new Date('2025-10-06T08:00:00') // 10月6日是周一
3

4
// 定时检查
5
setInterval(() => {
6
  const now = new Date()
7
  // getDay()返回0=周日，1=周一，2=周二...
8
  if (now.getDay() === 1 && now.getHours() === 8) {
9
    sendReminder() // 预期周一触发
10
  }
11
}, 60000)

结果周日凌晨 0 点就触发了——因为 new Date('2025-10-06T08:00:00') 在 UTC 时区是“2025-10-06T00:00:00”（北京时区是+8，所以本地时间是 08:00），但 now.getDay() 取的是本地时区的星期，周日的 getDay() 返回 0，周一返回 1。

问题回溯与分析：

如果用户在周日晚上 11 点打开页面，now 的 getDay() 还是 0，但 now.getHours() 是 23，不会触发；但到了周日凌晨 0 点，now.getDay() 变成 0，getHours() 是 0，也不会触发？

不对，等一下，正确的例子应该是用户设置“每周一”，但用 Date 的 getDay() 会把周日当 0，周一当 1，所以如果用户设置的是“每周一”，代码是对的，但如果用户设置的是“每周日”，代码会写错？

或者我们来看另一个例子：

用户设置“每月 1 日早上 8 点”，用 new Date('2025-10-01T08:00:00')，但如果是 10 月 1 日是周三，getDay() 返回 3，而如果用户在 9 月 30 日（周二）打开页面，now.getDate() 是 30，getMonth() 是 8（9 月），getFullYear() 是 2025。

所以代码是对的，但如果是跨时区的情况，比如用户在东京，new Date('2025-10-01T08:00:00') 在东京时区是 10 月 1 日 08:00，但在 UTC 是 9 月 30 日 23:00，所以 now.getDate() 是 30，getMonth() 是 8，getFullYear() 是 2025，导致提醒在 9 月 30 日触发？

哦，更准确的例子：用户在东京（GMT+9）设置“2025-10-01 08:00”的提醒，用 Date 写：

1
const reminder = new Date('2025-10-01T08:00:00+09:00') // 东京时间
2
console.log(reminder.toISOString()) // 2025-09-30T23:00:00.000Z（UTC时间）
3

4
// 定时检查
5
setInterval(() => {
6
  const now = new Date()
7
  if (now.toISOString() === reminder.toISOString()) {
8
    sendReminder()
9
  }
10
}, 60000)

结果9 月 30 日 23:00 UTC（东京时间 10 月 1 日 08:00）触发，这是对的，但如果用户在上海（GMT+8）打开页面，now.toISOString() 是上海时间减 8 小时，所以当上海时间 10 月 1 日 07:00 时，UTC 是 23:00，会触发提醒，而用户预期的是上海时间 10 月 1 日 08:00，这就错了。

问题根源：Date 把“时区”藏在黑盒里，toISOString() 返回的是 UTC 时间，而 new Date() 会根据本地时区解析字符串，导致跨时区的歧义。

场景 2：跨浏览器的“日期解析混乱”#

new Date('2025-10-01') 在 Chrome 中返回UTC 时间的 2025-10-01T00:00:00，而在 Firefox 中返回本地时区的 2025-10-01T00:00:00。如果用户在上海（GMT+8）打开页面：

• Chrome 中 new Date('2025-10-01').toLocaleString() 是“2025/10/1 08:00:00”（UTC+8）；
• Firefox 中是“2025/10/1 00:00:00”（本地时区）。

这会导致跨浏览器的功能不一致——比如“显示用户生日”的功能，在 Chrome 中显示“10 月 1 日 08:00”，在 Firefox 中显示“10 月 1 日 00:00”。

场景 3：月份的“0 开始陷阱”#

Date 的 getMonth() 返回 0=1 月，1=2 月，…，11=12 月。你写了个“显示当前月份”的功能：

1
const now = new Date()
2
const month = now.getMonth() + 1 // 加1才是真实月份
3
console.log(`当前月份：${month}`) // 比如10月显示10

如果忘了加 1，就会显示“当前月份：9”（10 月），这是前端最常见的低级 bug 之一——不是你粗心，是 Date 的设计反直觉。

Temporal 的核心类型：告别“黑盒”#

Temporal 把日期时间拆成 5 种明确的类型，每个类型只负责一件事：

场景 1：重新实现“每周一提醒”#

用 Temporal 写“每周一早上 8 点提醒”，逻辑清晰到“不用注释”：

1
// 1. 定义“每周一 08:00”的规则（纯日期+纯时间）
2
const reminderTime = Temporal.PlainTime.from('08:00:00')
3
const reminderDay = 1 // Temporal.PlainDate.getDayOfWeek()返回1=周一，7=周日
4

5
// 2. 定时检查当前时间
6
setInterval(async () => {
7
  // 获取当前的“上海时区时间”（ZonedDateTime）
8
  const now = Temporal.Now.zonedDateTimeISO('Asia/Shanghai')
9
  // 提取当前的“纯日期”和“纯时间”
10
  const today = now.toPlainDate()
11
  const currentTime = now.toPlainTime()
12

13
  // 检查：是否是周一，且时间是08:00
14
  if (today.dayOfWeek === reminderDay && currentTime.equals(reminderTime)) {
15
    sendReminder() // 精准触发
16
  }
17
}, 60000)

对比 Date 的优势：

• Temporal.PlainDate.dayOfWeek 返回 1=周一，7=周日，完全符合人类直觉；
• ZonedDateTime 明确带时区，不会有“本地时间 vs UTC”的歧义；
• 类型拆分后，每一步操作都可预测，不会出现“周日触发周一提醒”的 bug。

场景 2：跨时区的酒店入住时间计算#

再看之前的酒店预订例子，用 Temporal 写更清晰：

1
// 用户在北京（GMT+8）选了“2025-10-01”入住
2
const checkInDate = Temporal.PlainDate.from('2025-10-01') // 纯日期，无时间/时区
3
// 转成北京时区的“0点”（PlainDateTime）
4
const beijingCheckIn = checkInDate.toPlainDateTime(
5
  Temporal.PlainTime.from('00:00')
6
)
7
// 转成东京时区的ZonedDateTime（GMT+9）
8
const tokyoCheckIn = beijingCheckIn.toZonedDateTime('Asia/Tokyo')
9

10
console.log(tokyoCheckIn.toString())
11
// 输出：2025-10-01T01:00:00+09:00[Asia/Tokyo]（北京0点=东京1点）
12

13
// 东京酒店的最晚退房时间：次日12点
14
const tokyoCheckOut = tokyoCheckIn.add({ days: 1 }).with({ hour: 12 })
15
// 转回北京时区给用户看
16
const beijingCheckOut = tokyoCheckOut.toZonedDateTime('Asia/Shanghai')
17

18
console.log(beijingCheckOut.toString())
19
// 输出：2025-10-02T11:00:00+08:00[Asia/Shanghai]（东京12点=北京11点）

为什么不会出错？：

• PlainDate 是纯日期，所以“2025-10-01”不会被解析成 UTC 时间；
• ZonedDateTime 明确带时区，转换时会自动调整时差；
• 每一步操作都有“类型约束”，比如 toPlainDateTime 只能把 PlainDate 转成 PlainDateTime，不会有意外的时区转换。

为什么 0.1 无法精确表示？#

0.1 的十进制转二进制是 0.00011001100110011…（无限循环）。而尾数位只有 52 位，无法存储无限循环的二进制小数，所以 0.1 在 JS 中存储的是近似值：
$0.1000000000000000055511151231257827021181583404541015625$

为什么 19.9+29.8 会出错？#

19.9 和 29.8 都是不精确的浮点数：

• 19.9 的二进制表示：$10011.111001100110011...$（无限循环）；
• 29.8 的二进制表示：$11101.11001100110011...$（无限循环）。

当它们相加时，不精确的部分会累积，导致结果变成 49.699999999999996——不是“计算错误”，是“存储错误”。

实战：电商满减的“精确计算”#

假设你在做电商的购物车功能，需要实现“满 300 减 50”的优惠规则。用 Math.sumPrecise 写，逻辑精准且简洁：

1
// 购物车商品列表（单价均为浮点数）
2
const cart = [
3
  { name: '羽绒服', price: 199.99 },
4
  { name: '牛仔裤', price: 129.5 },
5
  { name: '围巾', price: 89.9 },
6
]
7

8
// 1. 精确计算商品总价（Math.sumPrecise接收数组参数）
9
const total = Math.sumPrecise(cart.map((item) => item.price))
10
console.log(total) // 419.39（完全精确，没有小数点后的冗余）
11

12
// 2. 计算满减优惠（满300减50）
13
const discount = total >= 300 ? 50 : 0
14

15
// 3. 精确计算实付金额（再次使用Math.sumPrecise确保精度）
16
const payable = Math.sumPrecise([total, -discount])
17
console.log(payable) // 369.39（精确到分）

对比传统方案：到底好在哪？#

我们用三种方案计算同一个购物车的总价，看结果差异：

底层原理：Kahan 求和的“补偿魔法”#

Kahan 算法的核心是用一个“补偿变量”（compensation）跟踪求和过程中丢失的精度，每次迭代时把误差“补回来”。我们手动实现一个 Kahan 求和，对比普通求和的差异：

1
/**
2
 * 手动实现Kahan求和算法
3
 * @param numbers 要相加的浮点数数组
4
 * @returns 精确的求和结果
5
 */
6
function kahanSum(numbers: number[]): number {
7
  let sum = 0 // 总和
8
  let compensation = 0 // 补偿变量（记录丢失的精度）
9

10
  for (const num of numbers) {
11
    // 1. 把之前的误差补到当前数上
12
    const y = num - compensation
13
    // 2. 计算临时总和
14
    const t = sum + y
15
    // 3. 计算新的误差。
16
    compensation = t - sum - y
17
    // t - sum = y + compensation？ 不！！！
18
    // 解释一下：t = sum + y，所以 t - sum - y = 0 吗？
19
    // 不对，因为浮点数精度问题，t - sum - y 会等于丢失的精度
20

21
    // 4. 更新总和
22
    sum = t
23
  }
24

25
  return sum
26
}
27

28
// 测试：0.1+0.2+0.3
29
const numbers = [0.1, 0.2, 0.3]
30
console.log(
31
  '普通求和:',
32
  numbers.reduce((a, b) => a + b, 0)
33
) // 0.6000000000000001
34
console.log('Kahan求和:', kahanSum(numbers)) // 0.6（完全精确）

Kahan 算法的步骤拆解（以 0.1+0.2+0.3 为例）：

1. 初始化：sum = 0，compensation = 0；
2. 加 0.1：y = 0.1 - 0 = 0.1，t = 0 + 0.1 = 0.1，compensation = 0.1 - 0 - 0.1 = 0，sum = 0.1；
3. 加 0.2：y = 0.2 - 0 = 0.2，t = 0.1 + 0.2 = 0.30000000000000004，compensation = 0.30000000000000004 - 0.1 - 0.2 = 4.440892098500626e-17，sum = 0.30000000000000004；
4. 加 0.3：y = 0.3 - 4.440892098500626e-17 = 0.29999999999999996，t = 0.30000000000000004 + 0.29999999999999996 = 0.6，compensation = 0.6 - 0.30000000000000004 - 0.29999999999999996 = 0，sum = 0.6；