QML日期解析与时间戳转换实战：避开Invalid Date的坑

前阵子做一个日志检索界面，后端给的查询条件里有一个时间字段，长这样：2024-06-15 14:30:00。我在QML里拿到这个字符串，第一反应是new Date(str)然后getTime()拿时间戳，再Qt.formatDateTime做显示。结果预估三分钟的事，实际排了半个多小时——console.log打出来是一个Invalid Date。后来我把QML里日期解析这套东西彻底捋了一遍，才发现坑比想象中多：Date.parse不稳定、时区容易被忽略、时间戳还有秒和毫秒的区别。这篇文章就把“字符串转日期、日期转时间戳、时间戳再转显示格式”整条链路写清楚，也给出一份可以直接复用的DateUtils.js。不管你是刚接触QML，还是从C++ Qt转过来做界面，只要项目里要处理后端返回的时间字段，这篇文章应该能帮你少走不少弯路。

1. 先认清QML里的日期体系：Date对象、Qt工具函数和C++侧的关系

1.1 QML里的Date其实就是ECMAScript标准对象

QML内置的JavaScript引擎从Qt 5.2开始就是V4引擎，它实现了大部分ECMAScript标准，所以你在QML里能直接使用Date对象、Math对象这些JS原生能力。很多人容易把QML里的Date和C++的QDate、QDateTime混在一起，其实它们完全是两套东西：

• C++侧：QDate只管日期，QTime只管时间，QDateTime是日期+时间，底层用msecsSinceEpoch()或toSecsSinceEpoch()表示时间戳。
• QML侧：能用的就是ECMAScript的Date，内部只存一个数字，单位是毫秒，代表从1970-01-01T00:00:00Z到当前时刻的毫秒数。

所以在写QML日期逻辑之前，先要把脑子里C++那套清空，QML里没有现成的QDateTime::fromString，所有字符串解析都得自己写或用JS语法。

1.2 Qt.formatDateTime不是万能的：能输出但不负责解析

QML里最常用的日期辅助函数是Qt.formatDate、Qt.formatTime、Qt.formatDateTime，它们的作用是把一个Date对象格式化成字符串。比如：

var d = new Date(); var text = Qt.formatDateTime(d, "yyyy-MM-dd hh:mm:ss"); console.log(text); // 输出类似 2024-06-15 14:30:00

这套yyyy、MM、dd、hh、mm、ss的格式标记，和QDateTime::toString的格式接近，用起来确实方便。但请注意：Qt.formatDateTime只做“Date 转字符串”这一个方向。QML没有内置的“字符串转Date”函数，你翻遍文档也找不到Qt.parseDateTime这类东西。所以字符串解析只能靠JS写，或者借助C++方法从外部转好了再传给QML。

1.3 时间戳的本质：从1970-01-01T00:00:00Z算起的毫秒数

Date对象内部就是时间戳，理解这一点很重要。常用API可以这样归纳：

简单类比一下：时间戳就是一个“绝对时间的坐标点”，它本身跟时区无关。同一个时间戳在纽约和北京用getHours()显示出来的数字不一样，因为getHours()返回的是本地时区换算后的小时，但getTime()在任何设备上都一样。这个特性后面做时区处理时会反复用到。

2. 字符串转日期：从固定格式拆分到通用模板解析

2.1 翻车现场：为什么new Date("2024-06-15 14:30:00")在QML里经常是Invalid Date

我在浏览器里写JS时，new Date("2024-06-15 14:30:00")基本都能解析出一个正常Date对象，所以到了QML里我理所当然地直接用了。结果QML控制台打出来一个Invalid Date，当时我第一反应是“我代码写错了”，后来把字符串换成"2024-06-15T14:30:00"（中间带个大写的T）又能解析了。

原因在ECMAScript规范里：标准明确要求JS引擎必须支持的是ISO 8601格式，比如"2024-06-15T14:30:00.000Z"这种带T带时区的写法。而"2024-06-15 14:30:00"这种带空格、不带时区后缀的字符串，规范说“实现可以自行决定是否解析”。浏览器的V8引擎比较宽容，能解析很多非标准格式；但QML的V4引擎明显选择了收紧策略，导致同一个字符串在Chrome里能用、在QML里就是Invalid Date。

这个坑的直接教训是：不要依赖Date.parse或new Date(str)去解析业务字符串，老老实实自己拆字段，或者用日期库。

2.2 最推荐的一步到位：按格式拆分后构造Date

如果你要解析的字符串格式固定，比如后端统一返回"2024-06-15 14:30:00"，最高效可靠的做法是用正则拆分然后再new Date(year, monthIndex, day, hour, minute, second)构造。

function parseStandard(str) { var m = str.match(/^(\d{4})-(\d{2})-(\d{2})[T\s](\d{2}):(\d{2}):(\d{2})$/); if (!m) return null; var year = parseInt(m[1], 10); var month = parseInt(m[2], 10); var day = parseInt(m[3], 10); var hour = parseInt(m[4], 10); var minute = parseInt(m[5], 10); var second = parseInt(m[6], 10); var date = new Date(year, month - 1, day, hour, minute, second); // 回读校验：2月30日这类非法日期会被Date自动"进位" if (date.getFullYear() !== year || date.getMonth() !== month - 1 || date.getDate() !== day) { return null; } return date; }

这里有两个关键点要解释清楚：

第一，new Date(year, month, day, ...)的月份参数是从0开始的。1月是0，2月是1，所以真实月份必须减1。很多初学者在这个地方踩坑，传进去month = 6，结果得到的是7月的日期。

第二，为什么构造之后还要“回读校验”？因为JS的Date构造函数非常“宽容”，如果你传入new Date(2024, 1, 30)，2月没有30号，Date会自动进位成3月1号，并且不报任何错误。等你在界面上显示的时候，用户看到日期变成了3月1日，但你根本不知道是什么时候错的。所以解析函数里必须做一次回读，校验年月日是否和输入一致。

我给的parseStandard还兼容了T和空格两种分隔符。后端如果返回的是"2024-06-15T14:30:00"，同样能解析，这样接口小范围调整时你不用改代码。

2.3 用正则兼容常见的杂格式

实际项目里字符串可不止一种：有的接口返回斜杠日期"2024/06/15 14:30:00"，有的日志系统返回纯数字时间戳字符串"20240615143000"，还有的带毫秒"2024-06-15 14:30:00.123"。如果你不想为了每种格式都写一个函数，可以写一个更宽松的parseFlexible。

function parseFlexible(str) { if (!str) return null; // 匹配 2024-06-15 14:30:00.123 / 2024/06/15 14:30:00 / 2024-06-15T14:30:00 var m = str.match(/^(\d{4})[-\/](\d{2})[-\/](\d{2})[T\s](\d{2}):(\d{2}):(\d{2})(?:\.(\d{1,3}))?$/); if (m) { var year = parseInt(m[1], 10); var month = parseInt(m[2], 10); var day = parseInt(m[3], 10); var hour = parseInt(m[4], 10); var minute = parseInt(m[5], 10); var second = parseInt(m[6], 10); var ms = m[7] ? parseInt(m[7], 10) : 0; return new Date(year, month - 1, day, hour, minute, second, ms); } // 匹配 20240615143000 这种14位纯数字 var m2 = str.match(/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})$/); if (m2) { return new Date(parseInt(m2[1], 10), parseInt(m2[2], 10) - 1, parseInt(m2[3], 10), parseInt(m2[4], 10), parseInt(m2[5], 10), parseInt(m2[6], 10)); } return null; }

这种宽松解析适合做数据清理、日志导入这类场景。但要注意：宽松解析只适合你明确知道数据来源的格式，如果格式五花八门到无法穷举，问题就不在解析函数，而是应该找上游接口统一规范。

2.4 进阶：写一个按format模板逆向解析的通用函数

比parseFlexible更进一步的做法，是模仿Qt.formatDateTime的格式模板，写一个通用的parseDateTime(str, format)。这样你只需要写一个函数，就能支持"yyyy-MM-dd HH:mm:ss"、"yyyy/MM/dd HH:mm:ss"、"dd.MM.yyyy HH:mm"等不同习惯的格式。

核心思路其实不复杂：把模板里的yyyy、MM、dd、HH、mm、ss、zzz这些token替换成正则捕获组，比如yyyy替换成(\d{4})，MM替换成(\d{1,2})。模板里的其他字符（横杠、冒号、斜杠、空格）做正则转义。然后用生成的正则去匹配输入字符串，把捕获到的字段取出来构造Date。

function escapeRegExp(s) { // 转义正则特殊字符 return s.replace(/[-\/\\^$*+?.()|[\]{}]/g, "\\$&"); } function parseDateTime(str, format) { if (str === null || str === undefined || str === "") return null; format = format || "yyyy-MM-dd HH:mm:ss"; var tokenDefs = [ { token: "yyyy", name: "year", pattern: "(\\d{4})" }, { token: "MM", name: "month", pattern: "(\\d{1,2})" }, { token: "dd", name: "day", pattern: "(\\d{1,2})" }, { token: "HH", name: "hour", pattern: "(\\d{1,2})" }, { token: "hh", name: "hour", pattern: "(\\d{1,2})" }, { token: "mm", name: "minute", pattern: "(\\d{1,2})" }, { token: "ss", name: "second", pattern: "(\\d{1,2})" }, { token: "zzz", name: "ms", pattern: "(\\d{1,3})" } ]; var regexParts = []; var captured = {}; var i = 0; while (i < format.length) { var matched = false; for (var k = 0; k < tokenDefs.length; k++) { var token = tokenDefs[k].token; if (format.substr(i, token.length) === token) { if (!captured[tokenDefs[k].name]) { captured[tokenDefs[k].name] = regexParts.length + 1; } regexParts.push(tokenDefs[k].pattern); i += token.length; matched = true; break; } } if (!matched) { regexParts.push(escapeRegExp(format.charAt(i))); i += 1; } } var m = str.match(new RegExp("^" + regexParts.join("") + "$")); if (!m) return null; function getVal(name, defaultVal) { if (captured[name]) return parseInt(m[captured[name]], 10); return defaultVal; } var year = getVal("year", 0); var month = getVal("month", 1); var day = getVal("day", 1); var hour = getVal("hour", 0); var minute = getVal("minute", 0); var second = getVal("second", 0); var ms = getVal("ms", 0); var date = new Date(year, month - 1, day, hour, minute, second, ms); // 回读校验 if (date.getFullYear() !== year || date.getMonth() !== month - 1 || date.getDate() !== day || date.getHours() !== hour || date.getMinutes() !== minute || date.getSeconds() !== second || date.getMilliseconds() !== ms) { return null; } return date; }

这个实现里hh和HH我都统一按24小时制处理，不区分12小时制。如果你需要支持AP/A这种上下午标记，可以在token表里再加，逻辑就是判断hour < 12，这里不展开。模板解析最大的价值是：当项目里不同模块用了不同日期格式时，你不用维护七八个解析函数，只传不同format就行。

3. 日期与时间戳互转：毫秒原点、秒级换算与格式化输出

3.1 getTime()、Date.now()与new Date(ms)是互转的全部

字符串解析完成后，下一步通常就是转时间戳。这个转换其实就是三件套：

var date = new Date(); // 当前时间 var ms = date.getTime(); // Date -> 毫秒时间戳 var back = new Date(ms); // 毫秒时间戳 -> Date console.log(ms === back.getTime()); // true

后端如果要求你传时间戳给查询接口，传ms就行。前端如果拿到一个时间戳要显示，先new Date(ts)得到Date对象，再格式化。整个过程没有别的魔法。

要注意的是，getTime()返回的是毫秒，很多后端接口习惯用秒级时间戳，这里的换算很容易出错。后面我单独拿出一节说。

3.2 后端惯用的10位秒级时间戳如何安全换算

后端接口最常见的时间戳是10位秒级，也就是Unix时间戳的标准形式，例如1718433000。JS的Date最小精确到毫秒，所以秒级时间戳必须乘以1000才能给new Date使用。

function unixToDate(sec) { return new Date(sec * 1000); } function dateToUnix(date) { return Math.floor(date.getTime() / 1000); }

为什么dateToUnix要用Math.floor？因为如果当前时间带毫秒，比如1718433000123，除以1000得到1718433000.123，而后端期望的是整数秒，直接Math.floor丢掉小数部分。如果用Math.round，在毫秒超过500时会进位，可能把一个还没到的未来时间戳传给后端，时间上会出现轻微的“未卜先知”。这种细节在联调时很难发现，但会造成数据统计在边界处差一秒。

我之前对接过不同后端语言，时间戳单位可以说是五花八门：

所以拿到一个时间戳，先看位数基本能猜出单位。但更稳妥的方式是看接口文档，不要凭位数猜。位数一旦分辨错误，整个时间都会错乱。

3.3 把时间戳格式化成"yyyy-MM-dd HH:mm:ss"的标准写法

前端拿到毫秒时间戳之后，最终要显示给用户，所以要有一个格式化函数。我会自己写一个formatDate，而不是每次都调Qt.formatDateTime，因为自定义函数能全局替换token，也更方便单元测试。

function pad2(n) { return n < 10 ? "0" + n : "" + n; } function pad3(n) { return n < 10 ? "00" + n : n < 100 ? "0" + n : "" + n; } function formatDate(date, format) { if (!(date instanceof Date) || isNaN(date.getTime())) return ""; var tokens = [ { k: "yyyy", v: date.getFullYear() }, { k: "MM", v: pad2(date.getMonth() + 1) }, { k: "dd", v: pad2(date.getDate()) }, { k: "HH", v: pad2(date.getHours()) }, { k: "hh", v: pad2(date.getHours()) }, { k: "mm", v: pad2(date.getMinutes()) }, { k: "ss", v: pad2(date.getSeconds()) }, { k: "zzz", v: pad3(date.getMilliseconds()) } ]; var result = format; for (var i = 0; i < tokens.length; i++) { result = result.split(tokens[i].k).join("" + tokens[i].v); } return result; }

这里用split().join()是为了全局替换，防止string.replace(tokens[i].k, ...)只替换第一处。比如模板里出现两个dd，或者替换完yyyy后后面的字符串又被误操作，用split().join()更稳。

pad2是做补零的：月份是6就显示成06，小时是9就显示成09。很多显示问题其实不是因为时间戳算错，而是忘了补零，界面上出现2024-6-9 9:5:3这种很业余的效果。

配合new Date(ms)，一行就能完成时间戳转显示字符串：

var text = formatDate(new Date(ms), "yyyy-MM-dd HH:mm:ss");

如果你图省事，直接用Qt.formatDateTime(new Date(ms), "yyyy-MM-dd hh:mm:ss")效果一样。区别在于Qt.formatDateTime的hh在Qt里是00-23的小时，而很多人从Java/JS的习惯过来会把hh当成12小时制。为了避免团队认知分歧，我自定义的formatDate里hh和HH统一按24小时制处理，至少在项目内部不会出现两套理解。

3.4 关于"毫秒时间戳精度"我的一点提醒

QML和JS的Date精度只到毫秒，这是ECMAScript标准决定的。如果后端返回的是微秒或纳秒级时间戳，比如1718433000123456，你直接new Date(1718433000123456)，得到的其实不是真实时间，因为超出毫秒精度的部分会被Date内部处理成一个完全错误的值。

处理高精度时间戳的正确姿势是：让后端在返回前就把单位换算成毫秒或秒，或者把原始高精度时间戳作为字符串原样返回，前端只做展示，不要轻易parseInt后去构造Date。

还有一个常见场景是通信双方做时间同步，比如设备上报一个“采集时间戳”，单位到底是秒还是毫秒必须在协议里写明。我在实际项目里见过两次：设备端以为是毫秒，服务端按秒解析，结果所有数据时间全部错了八万年。这种事情一旦上线，排查成本很高。所以我在对接时都会在接口文档里标一句：时间戳统一按UTC毫秒传递，字符串统一按带时区ISO格式传递。

4. 时区、无效日期和异常处理：最容易排错一晚上的地方

4.1 本地时间与UTC：为什么new Date(0).getHours()在中国是8

时区是日期解析里最大的暗坑。先看这段代码：

var d = new Date(0); console.log(d.toISOString()); // 1970-01-01T00:00:00.000Z console.log(d.getHours()); // 在中国是8，在美国西部可能是17

new Date(0)生成的Date对象在时间戳上就是1970-01-01T00:00:00Z，这个瞬时时刻全球一致。但getHours()返回的是本机时区换算后的小时，中国在东八区，所以看到的是8点。

这意味着什么？意味着new Date(year, monthIndex, day, hour, minute, second)这套构造方式，默认把参数当成本地时间来构造Date。而Date.UTC(year, monthIndex, day, hour, minute, second)则是把参数当成UTC时间来构造毫秒时间戳。两种写法得到的getTime()完全不同：

var a = new Date(2024, 5, 15, 14, 30, 0); // 参数按本地时间解释 var b = new Date(Date.UTC(2024, 5, 15, 14, 30, 0)); // 参数按UTC解释 console.log(a.getTime() === b.getTime()); // 在中国为false，相差8小时

所以，当你从字符串解析出一个“2024-06-15 14:30:00”时，必须先问自己：这个时间到底是服务器记录的UTC时间，还是客户端本地时间？这决定了用new Date(...)还是Date.UTC(...)。

如果这个字符串来自后端数据库，字段类型是DATETIME，通常是服务端所在时区的本地时间。如果字段类型是TIMESTAMP，底层其实存的是UTC时间，但展示时由客户端转换。最省心的做法是：前后端约定所有接口统一返回毫秒时间戳或带时区后缀的ISO字符串，不要返回光秃秃的本地时间字符串。

4.2 带Z或+08:00时区后缀的字符串到底怎么解析

ISO 8601字符串经常带时区后缀，比如"2024-06-15T14:30:00Z"表示UTC时间，"2024-06-15T14:30:00+08:00"表示东八区时间。这种格式不能简单用new Date(year, month-1, day, hour, minute, second)处理，因为后缀的偏移量要和字面时间叠加。

一个可靠的解析思路是：先把字符串里的字面时间用Date.UTC算出一个“假想UTC时间戳”，再减去时区偏移量，得到真实的UTC时间戳。代码如下：

function parseISOWithZone(str) { var m = str.match(/^(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2}):(\d{2})(Z|([+-])(\d{2}):(\d{2}))?$/); if (!m) return null; var year = parseInt(m[1], 10); var month = parseInt(m[2], 10); var day = parseInt(m[3], 10); var hour = parseInt(m[4], 10); var minute = parseInt(m[5], 10); var second = parseInt(m[6], 10); // 先把字面时间当成UTC，算出临时毫秒 var utcMs = Date.UTC(year, month - 1, day, hour, minute, second); var offsetMs = 0; if (m[7] === "Z") { offsetMs = 0; } else if (m[7]) { var offsetMin = parseInt(m[9], 10) * 60 + parseInt(m[10], 10); if (m[8] === "-") offsetMin = -offsetMin; offsetMs = offsetMin * 60000; } var date = new Date(utcMs - offsetMs); // 回读校验 if (date.getFullYear() !== year || date.getMonth() !== month - 1 || date.getDate() !== day) { return null; } return date; }

举个例子，字符串是"2024-06-15T14:30:00+08:00"。字面时间是14:30，时区偏移是+8小时，那么真实UTC瞬时是14:30 - 8小时 = 06:30。utcMs先按14:30算，再减去8小时的毫秒数，得到的就是2024-06-15T06:30:00Z对应的时间戳。这样无论在哪个时区的设备上解析，getTime()完全一致，显示成本地时间时也能正确转换。

这套代码不管QML还是纯JS环境都能跑，不需要依赖Intl，V4引擎完全支持。

4.3 2月30日、空字符串和null：解析函数必须有的防御

日期解析函数最容易在边界数据上翻车。常见的边界条件有三个：

第一，非法日期自动进位。前面说过new Date(2024, 1, 30)会变成3月1日。所以每个解析函数我都做了回读校验，解析后年份、月份、日期对不上就直接返回null。

第二，空字符串和null。很多接口在时间字段为空时会返回空串、null，甚至一个非法格式的占位符。解析函数必须在入口就拦住这些值，返回null，而不是让后续代码拿着一个Invalid Date继续算。

第三，不要在解析函数里抛异常。QML的属性绑定对异常的处理不像C++那样有完整的try-catch流程，一个绑定函数抛异常可能导致整个绑定链失效，界面上某个控件直接不更新，那种问题排查起来非常头疼。所以我的习惯是：解析函数只返回Date或null，格式化函数只返回字符串或空串，所有异常都在业务侧统一判断。

var d = DateUtils.parseDateTime(rawTime, "yyyy-MM-dd HH:mm:ss"); if (d) { text = DateUtils.formatDate(d, "yyyy/MM/dd"); } else { text = "--"; }

这样的代码可读性也更好，UI层一眼就能看出空值处理逻辑。

4.4 一个可直接复用的DateUtils.js（完整版）

把前面几节的函数汇总到一个DateUtils.js文件里，放到项目的shared/qml目录，所有页面统一import使用：

import "DateUtils.js" as DateUtils Item { Component.onCompleted: { var raw = "2024-06-15 14:30:00"; var d = DateUtils.parseDateTime(raw, "yyyy-MM-dd HH:mm:ss"); console.log(d.getTime()); // 毫秒时间戳 var ms = 1718433000000; console.log(DateUtils.fromTimestamp(ms, "yyyy-MM-dd HH:mm:ss")); console.log(DateUtils.formatDate(new Date(), "yyyy/MM/dd HH:mm:ss")); } }

DateUtils.js的函数清单建议包含：

把解析和格式化收敛到一个JS模块里之后，整个项目的时间处理口径就统一了。后续要支持新格式，只需要在这个文件里加函数，不用到处改UI代码。

5. 高频调用场景的性能取舍：不要在每一帧里反复转换

5.1 动画、图表刷新场景下的临时字符串问题

日期转换本身不复杂，但如果在高频刷新场景里滥用，性能问题非常明显。我见过一个实时曲线页面，底层模型每200毫秒推一个时间戳，界面上几个Text元素同时做这样的绑定：

text: DateUtils.formatDate(new Date(model.timestamp), "yyyy-MM-dd HH:mm:ss")

当时在PC上跑还好，换到嵌入式设备上整个界面掉帧明显。原因是formatDate内部有多次字符串split().join()，每次都会产生临时字符串；再加上new Date(...)、getTime()等操作，QML的垃圾回收器会频繁回收这些小对象，渲染线程被拖住。

这个问题的本质是：字符串是值类型，每次拼接和替换都会重新分配内存。而QML的属性绑定一旦依赖某个时间戳变化，就会重新执行整个表达式。高频更新时，反复的字符串分配和GC就是性能杀手。

5.2 实用优化思路：预转换、缓存与数据层处理

优化的核心思路很简单：能不在UI层算，就不要在UI层算。

如果数据源是C++侧提供的，最好的方案是在C++的model层就把时间戳转换成显示用的字符串，QML只负责展示字符串。C++的QDateTime::toString性能不差，而且可以把格式化逻辑和UI解耦。

如果是纯QML项目，也有几个可行手段：

第一，用缓存。同一个时间戳在短时间内重复格式化，结果一定是一样的，没必要每次重新计算。可以做一个简单的缓存Map，以输入时间戳为key，格式化结果做value。但要注意容量，不要无限增长，否则又引入了新的内存问题。做1000条以内的LRU或者直接定长覆盖都行。

第二，降低刷新频率。如果只是显示实时时间，比如“当前时间”这种，没必要每帧更新，用Timer每500毫秒刷新一次就够用户感知了。游戏循环里的deltaTime只用数字运算，不要转成字符串。

第三，不要在动画onPaint里调用任何格式化函数。动画引擎每帧调用批量属性更新，如果每次更新都做字符串分配，帧率必然受影响。把格式化结果先算好存到普通属性，再交给动画绑定，代价小很多。

第四，数据进QML之前先转换。从网络回调拿到JSON后，第一时间在数据处理函数里把时间字段变成显示字符串或Date对象，不要在Text的绑定表达式里才开始解析。这样绑定表达式足够简单，也方便排查。

5.3 绑定表达式保持简单：一切封装进纯函数

最后再说一个长期受益的习惯：QML里所有日期相关逻辑都封装成纯函数，别让界面层承担解析细节。

property string displayTime: { var d = DateUtils.parseDateTime(rawTime, "yyyy-MM-dd HH:mm:ss"); return d ? DateUtils.formatDate(d, "MM.dd HH:mm") : "--"; }

这样写有几个好处：界面层只关心“传入字符串，得到展示文本”；解析失败时返回一个安全的占位符，不影响任何绑定链；单元测试时可以直接用Qt Test的TestCase去测DateUtils.js里的函数，验证各种边界输入，不用启动整个UI。

我在项目里维护DateUtils.js时，固定会在里面加一组测试样例，比如“A正常格式返回Date” “A空字符串返回null” “A2月30日返回null” “A带时区后缀按偏移解析”。每次改动解析逻辑，先跑一遍这些用例，基本不会在回归时出问题。

最后再分享一个经验：和后端约定时间字段时，能传时间戳就传时间戳，能带Z就带Z，纯字符串最容易产生分歧。如果必须用"2024-06-15 14:30:00"这种格式，一定要在接口文档里写清楚是本地时间还是UTC。前端代码写得再稳，也架不住两边对“同一个字符串到底代表哪个时间”理解不一致。日期解析这条链路，工具只是最后一公里，前面的规范和约定才是真正省时间的部分。