企业官网建设流程全解析

我们几乎每天都会写时间相关的代码：订单要显示下单时间、列表要按创建时间排序、活动页要做倒计时、会员要判断过期时间。表面看，这些都是"取当前时间、格式化一下、算个差值"的小需求，但真正动手时，问题老是一个接一个：接口返回的时间戳转出来总是差8小时；后端传一个"2025-04-01 10:00:00"给前端，iOS 上直接变成Invalid Date；用getMonth()取月份，明明当前是 4 月，返回的却是 3。时间函数并不复杂，但能把这些基础问题讲透的文章并不多。

我的一个明确判断是：时间函数本身不难，难的是建立正确的时间模型。Date对象、时间戳、UTC、本地时间、时区偏移，这些概念看起来各自独立，实际上是一条线串起来的。绝大多数时间处理 Bug，根源都不是"API 没记住"，而是把"绝对时刻"和"本地日历时间"混为一谈，或者把"存储"和"展示"两个阶段混在了一起。这个底层模型一旦理顺，很多问题不用查资料也能自己推导出答案。

这篇文章会先从最底层的时间戳和时区模型讲起，再深入 JavaScriptDate的创建、读取、格式化和时间计算，用完整代码演示倒计时、相对时间和跨时区展示，然后对比 Python、Java、SQL 中时间函数的设计差异，最后给你一套可落地的最佳实践和排查手册。读完你会理解：为什么new Date()在不同机器上结果不同；为什么 UTC 和本地时间会差 8 小时；什么时候应该用原生Date，什么时候应该引入dayjs或date-fns；以及遇到奇怪时间 Bug 时，第一步应该从哪里查起。建议先收藏这篇文章，再跟着代码一节一节验证。

1. 这篇文章真正要解决的问题

先别急着看 API 清单，我们先回答一个根本问题：时间函数究竟难在哪？

从使用场景看，时间函数主要解决四类需求：获取当前时间、解析外部传入的时间、格式化展示、进行时间计算。这四个场景在任意一门语言里都有对应函数，语法也都差不多。真正的难点来自三个层面的混叠。

第一，时间表示方式不统一。同一个时间点，可以被表示为时间戳1743484800000，也可以被表示为带时区的字符串2025-04-01T10:00:00.000Z，还可以被表示为本地时间字符串2025-04-01 18:00:00。接口用哪一种，前端展示用哪一种，数据库存储用哪一种，如果团队没有约定，就会出现"传出去对不上、接回来又偏几小时"的问题。

第二，API 细节有反直觉设计。最典型的就是 JavaScript 的getMonth()返回 0 到 11，并不是 1 到 12；new Date()接收不同格式的字符串时，不同浏览器的解析结果可能完全不同；时间戳单位有的是秒，有的是毫秒，后端用Timestamp返回秒级，前端用毫秒级Date处理，数值差了一千倍，计算差值就变成了天文数字。

第三，展示层和逻辑层被混杂。很多同学习惯在拿到时间字符串后，先做一次格式化再传到下一层，这个做法非常危险。因为格式化后的字符串已经丢失了原始时区信息，后续如果再转一次，很容易出现重复偏移。比较稳妥的做法是：逻辑层只处理时间戳或 ISO 字符串，只在展示层做一次格式化。

这篇文章不是想罗列多少种时间函数用法，而是希望帮你构建一个"时间处理模型"，再围绕这个模型给出可复用的代码和排查思路。无论你写前端、后端还是数据库脚本，这套模型都是通用的。下面我们先从最基础的时间戳和时区讲起。

2. 时间模型：时间戳、UTC 与本地时间

理解时间函数，必须先分清三个概念：时间戳、UTC 时间和本地时间。很多时间 Bug 都出在这三者的转换上。

时间戳是从1970-01-01T00:00:00.000Z开始计算的毫秒数或秒数。它描述的是"绝对时刻"，不依附于任何时区。无论在伦敦、北京还是纽约，同一个物理时刻对应的时间戳完全一样。在 JavaScript 中，Date对象内部存储的本质就是一个数字——距今的毫秒数。你可以把Date理解成一个"时间戳容器"。

UTC 时间是一种标准化的日历时间表达方式，使用 24 小时制，以格林尼治天文台旧址所在经线为 0 度基准线。2025-04-01T10:00:00.000Z末尾的Z表示 "Zulu time"，也就是 UTC 时间。UTC 时间本身也不是"某个国家的本地时间"，它是全球统一的时间标尺。

本地时间是 UTC 时间加上当前时区偏移量之后得到的结果。中国标准时间是UTC+8，所以当 UTC 时间是2025-04-01T10:00:00Z时，北京本地时间就是2025-04-01 18:00:00。这就是"差 8 小时"问题的来源——不是时间戳错了，而是你把一个 UTC 时刻直接当成本地时间展示，或者把一个本地时间字符串按 UTC 解析了。

三个概念的关系可以用这个例子理解：

在 JavaScript 中，Date对象本身不保存时区信息。它保存的只是一个时间戳，当你调用getFullYear()、getHours()等方法时，运行环境会把它转换成当前系统时区下的本地时间；当你调用getUTCFullYear()、getUTCHours()时，它会转换到 UTC 时间。这意味着，同一个Date对象，在不同时区的服务器上调用getHours()，得到的本地小时数是不同的，但调用getUTCHours()的结果始终一致。

一个常见误区是"给日期加时区"。比如有同学以为new Date("2025-04-01 10:00:00+08:00")会保存一个带时区的对象，然后后续操作都是在UTC+8下进行。实际上，Date保存的还是时间戳，只是解析字符串时按照你提供的偏移量换算成了 UTC 时刻并保存。这个细节是理解后续所有函数行为的基础。时间戳是一切的锚点，理解了它，后面所有 API 都在你的掌控之内。

3. JavaScript Date 核心操作：创建、读取与格式化

JavaScript 的Date是前端时间处理的核心对象。很多人对它又爱又恨，是因为方法太多、行为太杂。下面我们从创建、读取、格式化三个维度拆开讲，并指出每个环节容易踩的坑。

3.1 创建 Date 对象

创建Date有四种常见方式，分别对应不通的输入来源。建议你在实际开发中优先使用时间戳和 ISO 8601 字符串，因为它们不受本地时区影响，可预测性最强。

// 方式一：不传参数，获取当前时刻 const now = new Date(); console.log(now.getTime()); // 输出当前时刻的毫秒时间戳 // 方式二：传入毫秒时间戳 const fromTs = new Date(0); console.log(fromTs.toISOString()); // 输出 1970-01-01T00:00:00.000Z // 方式三：传入 ISO 8601 字符串（推荐） const fromIso = new Date("2025-04-01T10:00:00.000Z"); console.log(fromIso.toISOString()); // 输出 2025-04-01T10:00:00.000Z // 方式四：传入本地时间字符串（兼容性风险较高） const fromLocalStr = new Date("2025/04/01 10:00:00");

这里需要特别注意的是第四种方式。new Date("2025-04-01 10:00:00")这种带空格、不带时区的字符串，JavaScript 规范并不强制要求浏览器统一解析。Chrome 会把它当作本地时间解析，而部分旧版 iOS Safari 会直接返回Invalid Date。如果后端接口返回的是这种格式，建议不要直接传给new Date，而是先做一次统一的字符串清洗，替换成2025-04-01T10:00:00或2025-04-01T10:00:00+08:00这样的明确格式。

3.2 读取日期时间的常用方法

Date的读取方法可以分为两组：本地时间方法和 UTC 方法。两者的返回值可能不同，取决于当前系统时区。

最容易被忽略的是getMonth()返回值是 0 到 11。当你用new Date("2025-04-01")创建日期后，调用getMonth()得到的是3，而不是4。这也是"月份少 1"类 Bug 的固定来源。正确的做法是date.getMonth() + 1。

另外，getTime()返回的是毫秒时间戳，是Date对象最核心的数值表达。无论做比较还是计算差值，第一步都应该先把日期转换成getTime()结果，而不是直接用字符串比较。

3.3 格式化日期：手写还是用 Intl

日期格式化是最常用的需求。如果你只想输出2025-04-01 10:00:00这样的字符串，可以封装一个支持 UTC 和本地时间切换的格式化函数。

function formatDate(date, { useUTC = false } = {}) { const year = useUTC ? date.getUTCFullYear() : date.getFullYear(); const month = (useUTC ? date.getUTCMonth() : date.getMonth()) + 1; const day = useUTC ? date.getUTCDate() : date.getDate(); const hours = useUTC ? date.getUTCHours() : date.getHours(); const minutes = useUTC ? date.getUTCMinutes() : date.getMinutes(); const seconds = useUTC ? date.getUTCSeconds() : date.getSeconds(); const pad = (n) => String(n).padStart(2, "0"); return `${year}-${pad(month)}-${pad(day)} ${pad(hours)}:${pad(minutes)}:${pad(seconds)}`; } const d = new Date("2025-04-01T10:00:00.000Z"); console.log(formatDate(d)); // 本地时区展示，UTC+8 下输出 2025-04-01 18:00:00 console.log(formatDate(d, { useUTC: true })); // 输出 2025-04-01 10:00:00

如果进一步要求国际化展示，比如"2025年4月1日 星期二"或"4月1日 18:00:00"，手写格式化会越写越复杂，而且不一定兼容各种语言。此时更推荐使用Intl.DateTimeFormat，它是操作系统内置的国际化 API，不需要额外依赖库。

const d = new Date("2025-04-01T10:00:00.000Z"); 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(d)); // 输出类似：2025/04/01 18:00:00

Intl.DateTimeFormat的timeZone参数支持"Asia/Shanghai"、"UTC"、"America/New_York"等 IANA 时区名称。这个能力在展示"某个时间点在不同时区是什么时间"时非常方便，原生Date本身并不提供这种直接的时区转换方法。

3.4 解析时间字符串的兼容性陷阱

解析用户输入或后端返回的时间字符串，是时间 Bug 的高发区。这里给出一个优先顺序，供你参考：

1. 优先解析 ISO 8601 字符串，例如2025-04-01T10:00:00.000Z。这种格式有明确时区标识，解析结果跨端一致。
2. 如果字符串是2025-04-01 10:00:00这种本地时间格式，并且你能确认它代表的业务语义就是"本地时间"，建议手动拆解后使用new Date(2025, 3, 1, 10, 0, 0)这种参数传值方式创建，避免字符串解析歧义。
3. 不要依赖Date.parse()对非标准格式的解析，它的行为在规范层面就没有完全统一。

此外，后端返回的常见格式还有 Unix 秒级时间戳。此时前端要先进行单位换算，再传给Date：new Date(timestamp * 1000)。如果你不加* 1000，得到的时间会比预期晚了约 228 万年，这已经是生产环境中出现过的真实事故。

4. 时间计算与综合实战：倒计时、相对时间与跨时区展示

理解了创建、读取和格式化，接下来进入综合实战。这一节会用一个订单倒计时组件、一个相对时间函数和一个跨时区展示案例，把时间函数串起来。

4.1 时间差计算

计算两个时间点相差多少天、多少小时，正确思路是先把两个时间都转换为时间戳，再做差值，最后把差值拆分成天、时、分、秒。下面的函数接收一个目标时间，返回当前时间到目标时间的倒计时对象。

function getCountdown(targetTime, now = Date.now()) { let diff = new Date(targetTime).getTime() - now; if (diff < 0) { diff = 0; // 倒计时已结束，统一归零 } const totalSeconds = Math.floor(diff / 1000); const days = Math.floor(totalSeconds / 86400); const hours = Math.floor((totalSeconds % 86400) / 3600); const minutes = Math.floor((totalSeconds % 3600) / 60); const seconds = totalSeconds % 60; return { days, hours, minutes, seconds }; } // 假设活动结束时间是 2025-12-31 23:59:59（北京时间） const result = getCountdown("2025-12-31T23:59:59+08:00"); console.log(result); // 输出类似：{ days: 248, hours: 5, minutes: 12, seconds: 30 }

这段代码的关键是diff可能为负数。实际业务中倒计时一旦结束，应该显示00:00:00而不是负数，所以这里做了归零处理。另一个容易疏忽的点是Math.floor和Math.ceil的选择：如果你希望"剩余 1 秒"在不足 1 秒时也能触发业务动作，可能需要结合具体场景调整取整方式。

在倒计时组件中，每隔一秒重新获取当前时间并更新视图即可。需要注意的是，不要用setInterval累加一个计数器来推进时间，因为定时器可能因为线程阻塞而延迟，导致倒计时越走越不准确。更稳妥的做法是：每次都基于Date.now()重新计算差值。

4.2 相对时间：刚刚、x 分钟前

社区内容、IM 消息、操作日志里常见"刚刚""5 分钟前""3 小时前"这类相对时间。它的计算逻辑并不复杂，本质还是时间差的分段判断。

function timeAgo(dateInput) { const target = new Date(dateInput).getTime(); const diff = Date.now() - target; const minute = 60 * 1000; const hour = 60 * minute; const day = 24 * hour; const month = 30 * day; if (diff < minute) { return "刚刚"; } if (diff < hour) { return `${Math.floor(diff / minute)} 分钟前`; } if (diff < day) { return `${Math.floor(diff / hour)} 小时前`; } if (diff < month) { return `${Math.floor(diff / day)} 天前`; } return new Date(dateInput).toISOString().slice(0, 10); }

这个函数默认输入是一个可被Date解析的时间。注意输出"x 天前"时，如果超过 30 天，直接展示具体日期会比"35 天前"更直观。实际项目中你可以根据业务需要调整分段阈值。

4.3 跨时区展示

假设你在做一个国际化协作工具，后端返回一个会议开始时间2025-04-01T10:00:00.000Z，需要分别展示给北京和纽约的用户。如果直接调用date.toString()，用户看到的本地时间会随着浏览器系统时区自动变化，这通常是对的。但如果产品要求在北京界面显示"北京时间 18:00"，在纽约界面显示"纽约时间 06:00"，你就要借助Intl.DateTimeFormat固定时区。

function formatInTimeZone(dateInput, timeZone) { const d = new Date(dateInput); const formatter = new Intl.DateTimeFormat("en-US", { timeZone, year: "numeric", month: "2-digit", day: "2-digit", hour: "2-digit", minute: "2-digit", hour12: false, }); return formatter.format(d); } const meetingTime = "2025-04-01T10:00:00.000Z"; console.log(formatInTimeZone(meetingTime, "Asia/Shanghai")); console.log(formatInTimeZone(meetingTime, "America/New_York"));

这里的关键认知是：Date对象存储的永远是绝对时刻，而Intl.DateTimeFormat负责把它转换到指定时区的日历时间。展示层传入时区标识，就能保证同一时刻在不同地区呈现出对应的本地时间，同时不会破坏底层数据。

5. 需要引入 dayjs / date-fns 吗：原生与第三方库的取舍

很多初学者会陷入一个纠结：原生Date已经能做大部分事，为什么还要引入dayjs？我的建议是：看业务复杂度，不要为了用库而用库。

原生Date的优势是零依赖、加载成本为零，适合简单场景。但它在时间解析、时区切换、相对时间、时间加减等操作上确实不够直观。举几个例子：date.add(1, 'day')这种语义化操作，原生没有；date.startOf('month')这种取月初的逻辑，原生没有；对不同时区的转换，原生也没有专门 API，只能借助Intl。当这类需求频繁出现时，手写工具函数会越来越多，最后每个项目维护一套自己的时间工具库，反而更容易出错。

dayjs和date-fns是目前前端比较主流的两套选择，它们的设计思路略有不同。

下面以dayjs为例，演示安装和使用：

npm install dayjs

import dayjs from "dayjs"; import relativeTime from "dayjs/plugin/relativeTime"; import "dayjs/locale/zh-cn"; dayjs.extend(relativeTime); dayjs.locale("zh-cn"); console.log(dayjs().format("YYYY-MM-DD HH:mm:ss")); // 当前时间格式化 console.log(dayjs("2025-04-01").fromNow()); // 相对当前时间的描述，如“27天前” console.log(dayjs().add(1, "day").startOf("day").valueOf()); // 明天零点的时间戳

dayjs的链式调用比原生 API 更接近业务语义，代码可读性也更高。不过引入第三方库也意味着要承担依赖升级、包体积、团队学习成本。如果项目里只有零星几个格式化需求，完全没有必要上库；但如果你的项目涉及多项时间计算，或者历史代码已经大量使用类似moment风格的 API，那么统一到dayjs会是不错的选择。

还有一点值得注意：无论使用原生Date还是第三方库，时间模型的底层逻辑是不变的。库只是把"比较、加减、格式化"这些操作封装得更友好，并不会替你解决"字符串是什么时区"这类语义问题。数据源不规范，再好的库也救不了。

6. 其他语言的时间函数：Python、Java、SQL 的差异

时间函数的很多概念是跨语言通用的，但每个语言在 API 设计和底层实现上有一些差异。快速掌握一门外语的时间函数，关键不是死背方法名，而是看看它如何表达"时刻"和"本地时间"这两个概念。

6.1 Python：datetime 与 timezone

Python 的datetime模块提供了非常清晰的时间对象。一个常见误区是使用datetime.now()获取本地时间，却不带时区信息，导致跨时区运行和 UTC 转换时语义不清。推荐的方式是使用带时区的datetime对象。

from datetime import datetime, timezone, timedelta now_utc = datetime.now(timezone.utc) now_beijing = now_utc.astimezone(timezone(timedelta(hours=8))) print(now_utc.isoformat()) print(now_beijing.isoformat())

Python 的astimezone()方法可以轻松把一个时区时间转换为另一个时区时间，这一点和 JavaScript 依赖Intl实现有所不同。日常开发中要注意：datetime.datetime对象有naive和aware之分，naive对象不携带时区信息，直接做时区转换时容易出错。

6.2 Java：java.time 包

从 Java 8 开始，推荐使用java.time包，它把"时刻""本地日期""带时区的日期时间"拆成了不同类。Instant表示绝对时刻，LocalDateTime表示不带时区的本地时间，ZonedDateTime表示带时区的日期时间。

import java.time.Instant; import java.time.ZoneId; import java.time.ZonedDateTime; public class TimeDemo { public static void main(String[] args) { Instant instant = Instant.now(); ZonedDateTime beijing = instant.atZone(ZoneId.of("Asia/Shanghai")); System.out.println(beijing); } }

Java 的老版本java.util.Date设计上有很多不方便的地方，比如月份从 0 开始、可变对象、时区处理繁琐。新款java.time在命名和语义上更接近自然语言，也很好地解决了这些问题。如果你维护的是老项目，遇到Date和Calendar的代码，可以考虑逐步迁移到java.time。

6.3 SQL：数据库时间函数

SQL 时间函数在不同数据库之间存在差异，但常见需求是类似的：获取当前时间、转换时区、计算时间差、按日期分组统计。以 MySQL 为例：

-- 获取当前时间和当前 UTC 时间 SELECT NOW(), UTC_TIMESTAMP(); -- 计算两个日期相差天数 SELECT DATEDIFF('2025-04-10', '2025-04-01'); -- 按日期分组统计订单数 SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM orders GROUP BY DATE(create_time);

SQL 时间函数最大的坑是：数据库连接时区、服务器时区、客户端时区如果不一致，同样一条NOW()会呈现出不同结果。生产环境建议统一将数据库时区设置为 UTC，存储时间时使用 UTC，只有在上层应用获取和展示时才转换为业务时区。

从这些语言对比中可以看到，时间函数的底层模型高度一致：时刻是绝对的，日历时间是相对的。无论语言怎么变化，只要你清楚输入的时间是绝对时刻还是本地时间，处理思路就不会走偏。

7. 常见问题与排查方法

时间 Bug 的排查并不难，只要抓住"源头是什么时区、中间怎么转换、最后怎么展示"这条链路。下面是一份高频问题速查表，遇到异常可以直接对照。

写代码遇到时间问题，建议按以下顺序排查：

1. 确认输入值：打印原始时间戳或字符串，判断它是绝对时刻还是本地时间表达。
2. 确认解析方式：new Date(输入值)解析出来的getTime()是否符合预期。如果偏了整数小时，先检查时区偏移。
3. 确认展示方式：格式化时用的是getFullYear()还是getUTCFullYear()，两者输出可能完全不同。
4. 确认单位：检查时间戳是秒还是毫秒。
5. 检查第三方库版本：如果用了dayjs或moment，确认版本和 locale 配置是否一致。

一个很实用的调试技巧是：在任何时间转换函数里先输出一个基准时间。比如new Date("2025-01-01T00:00:00.000Z")，然后手动计算它在当前时区下应该显示成几点。如果基准时间输出正确，说明环境没问题，问题出在业务传入的数据上；如果基准时间都偏了，说明时区配置或格式化函数有误。

8. 时间函数最佳实践与工程建议

代码层面的 API 掌握到一定程度后，真正决定项目质量的是团队对时间的约定。时间处理最容易出现的问题，往往不是某个函数写错，而是整个系统对"时间应该以什么格式流通"缺乏统一规范。我建议从以下几个维度建立标准。

第一，存储和传输统一使用 UTC 时刻。数据库字段建议存储 UTC 对应的日期时间，接口传输时统一使用 ISO 8601 字符串，例如2025-04-01T10:00:00.000Z，或者使用带时区偏移的格式2025-04-01T18:00:00+08:00。前端拿到这类字符串后，可以明确知道这是一个绝对时刻，不会再产生歧义。

第二，展示层才允许转换本地时区。业务逻辑层、数据层不要调用toLocalString()或getHours()去格式化时间。把时间按本地时区转换成给人看的字符串，只应发生在 UI 展示那一层。这样做的最大好处是，后端运行在 UTC 时区还是北京时间时区，都不会影响接口数据的一致性。

第三，封装统一的时间工具模块。项目中建议封装一个time.ts或dateUtil.js，所有格式化、解析、时间计算都通过该模块导出的函数完成，而不是散落在业务代码里各写各的。工具模块内部可以按需使用原生Date、Intl或dayjs，但对外暴露的方法名和返回值类型要保持统一。

第四，命名规范要体现语义。字段名建议清晰表达时间语义，比如startTime、endTime、createTime、expireTime、publishAt、updatedAt。如果字段表示的是 UTC 还是本地时间，可以从字段命名上体现，比如createdAtUtc。这能减少跨端联调时的理解成本。

第五，注意时间边界。在测试和业务实现中，要特别关注跨天、跨月、跨年，以及夏令时切换的时刻。比如2025-03-31加一天是2025-04-01，这类边界要写测试用例覆盖。定时任务、每日统计、会员过期判断这些功能，涉及"当天 0 点"这种时间点，需要明确是本地时间还是 UTC 时间。

第六，日志中保留完整时间信息。生产环境排查问题时，最怕日志里只有"18:00"这种没有日期和时区的信息。日志建议输出 ISO 8601 字符串或包含时区偏移的字符串，这样即使服务器部署在不同的时区，也能还原出事件发生的绝对时刻。

第七，最小权限与安全边界意识。在操作数据库或生产环境时间相关配置时，要先在测试环境验证，确认备份和回滚方案之后再执行。比如修改数据库时区、批量更新某张表的时间字段，都属于高风险操作，必须遵循变更流程，不能直接在生产库上随意更新。

这些实践不会让代码立刻变少，但会显著降低时间类 Bug 的出现频率。尤其是团队协作项目，统一约定比个人技巧重要得多。

9. 总结与后续学习方向

这篇文章先把时间处理的底层模型做了系统梳理：时间戳是绝对时刻，UTC 是标准日历时间，本地时间是带偏移的展示形式；然后围绕 JavaScriptDate讲解了创建、读取、格式化、时间计算的完整路径；接着用倒计时、相对时间、跨时区展示三个例子演示了综合应用，并讨论了原生Date与dayjs、date-fns的取舍；最后通过 Python、Java、SQL 的对比，说明了时间模型在不同语言之间的通用性，并提供了一份可复用的问题排查表和工程规范。

如果现在你要做一个时间相关的功能，完整的心流应该是这样：先明确输入的时间是"绝对时刻"还是"某个时区的本地时间"；再决定用时间戳还是 ISO 字符串进行内部传递；最后在 UI 层通过格式化函数或dayjs展示给人看。遇到差 8 小时、月份少 1、Invalid Date等问题时，不再靠猜，而是按"输入值、解析结果、展示逻辑、单位换算"四个环节逐个排查。

下一步建议你深入研究三块内容。第一是Intl.DateTimeFormat的完整参数，它是原生能力中非常强大但容易被忽视的日期时间国际化和时区处理工具。第二是dayjs的插件机制，比如utc、timezone、duration插件如何解决复杂时区和时间段场景。第三是不同数据库对时区和时间函数的行为差异，尤其是TIMESTAMP与DATETIME的区别，这对后端选型非常重要。把这些内容验证过一遍，时间处理就不会再成为项目的定时炸弹。建议你现在就新建一个timeUtils.js文件，把本文的格式化函数、倒计时函数和相对时间函数放进去，跑通后用在自己的项目里，才是真正把它消化成自己的技能。