1. 为什么这个转换问题值得专门写一篇长文——从一个线上 Bug 说起Flutter 开发中时间戳与DateTime的相互转换看似是基础操作但几乎每个中型以上项目都曾因它引发过线上事故列表页时间显示错乱、倒计时跳变、缓存失效、跨时区用户提交时间异常、甚至后台接口校验失败导致订单被拒。我参与维护的某电商类 App在一次灰度发布后华东地区用户反馈“下单成功页显示的时间比手机系统快了8小时”而西北用户却说“慢了1小时”。排查三天最终定位到一行DateTime.parse(_strtime)—— 它在不同设备、不同系统版本、不同字符串格式下行为不一致且文档里没写清楚边界条件。这不是个别现象。Flutter 官方DateTime类的设计哲学是“轻量、明确、不自动猜测”但它把“明确”的成本完全转嫁给了开发者你必须清楚知道输入字符串是否带时区、是否 ISO 8601 标准、是否含毫秒、是否为 UTC 时间你也必须清楚millisecondsSinceEpoch是基于哪个时区基准计算的。很多人误以为DateTime.parse(2023-05-20)和DateTime.parse(2023-05-20T00:00:00)是等价的实则前者默认解析为本地时区午夜后者在无时区标识时也按本地时区处理但某些 Android 低版本系统会静默补全为 UTC导致同一段代码在不同设备上产生 8 小时偏差。本文不讲泛泛而谈的 API 列表而是聚焦真实项目中高频踩坑点DateTime.parse()的隐式规则、millisecondsSinceEpoch的基准陷阱、ISO 字符串的 7 种常见变体如何精准识别、以及为什么DateTime.fromMillisecondsSinceEpoch()必须手动传isUtc: true才能和DateTime.utc()对齐。所有内容均来自多个生产环境项目的复盘每一步都有可验证的代码片段和设备实测截图文中以文字描述还原适合 Flutter 中级开发者快速建立防御性时间处理意识。2. 核心设计思路拆解为什么不能“简单 parse”就完事2.1 Flutter 时间模型的底层逻辑UTC 基准 本地化渲染Flutter 的DateTime类本质是一个“时间点”instant的封装其内部存储结构只有两个关键字段_microsecondsSinceEpoch微秒级时间戳和_isUtc布尔标记。注意它不存储时区偏移量也不存储“年月日时分秒”这些日历字段——这些全部是运行时根据当前设备时区动态计算出来的。这意味着DateTime实例本身没有“属于哪个时区”的概念它只代表一个绝对时间点就像宇宙中的一个坐标。millisecondsSinceEpoch返回的是该时间点距离UTC 1970-01-01 00:00:00 的毫秒数这是全球统一的标尺。而DateTime.now()创建的实例其_isUtc为false表示它内部存储的时间戳是按本地时区解释的但_microsecondsSinceEpoch的值依然是 UTC 基准下的数值。举个例子在北京时间 2023-05-20 12:00:00东八区DateTime.now().millisecondsSinceEpoch返回的是1684574400000这个数字和伦敦时间同一天的 04:00:00UTC对应的是同一个毫秒值。所以millisecondsSinceEpoch从来不是“本地时间戳”它永远是 UTC 时间戳。这是绝大多数坑的根源——开发者常误以为DateTime.now().millisecondsSinceEpoch是“我的本地时间戳”结果传给后端做校验时后端用 UTC 解析发现时间对不上。因此整个转换设计的核心原则是所有中间传输、存储、计算环节必须统一使用 UTC 时间戳即millisecondsSinceEpoch仅在 UI 渲染层才做本地化格式化。DateTime.parse()的作用是把字符串“锚定”到这个 UTC 时间轴上而DateTime.fromMillisecondsSinceEpoch()的作用是把 UTC 时间轴上的点“具象化”为可读的DateTime实例。任何绕过这个原则的操作比如直接parse一个不含时区的字符串再调用toLocal()都是在制造不确定性。2.2DateTime.parse()的三大隐式规则与致命陷阱DateTime.parse()并非万能解析器它有一套严格的、文档未明示的优先级规则。官方文档只说“尝试解析 ISO 8601 格式”但没告诉你它遇到模糊格式时如何决策。通过源码分析和大量设备实测我们总结出它的三大隐式规则第一时区推断优先级显式 隐式 默认。如果字符串包含Z或08:00等时区标识它会严格按此解析如果字符串是2023-05-20T12:00:00无时区它会按设备当前时区解析但如果字符串是2023-05-20纯日期它会按设备当前时区的午夜解析并将_isUtc设为false。这导致一个问题同一段代码在北京设备上DateTime.parse(2023-05-20)得到的是2023-05-20 00:00:00 0800而在纽约设备上得到的是2023-05-20 00:00:00 -0400两者millisecondsSinceEpoch相差 12 小时。第二毫秒精度的静默截断。当字符串包含毫秒如2023-05-20T12:00:00.123时parse能正确保留但若毫秒位数超过 3 位如.123456它会直接截断为.123且不报错。第三空格与分隔符的容忍度极低。2023-05-20 12:00:00空格分隔会被解析为2023-05-20T00:00:00.000即只取日期部分因为parse认为这是非法格式降级处理。这些规则意味着绝不能信任DateTime.parse()对非标准字符串的解析结果必须预先清洗或使用更可控的方案。2.3 方案选型对比为什么推荐intl包而非原生parse面对parse的不确定性很多团队会考虑引入第三方包。我们对比了三种主流方案原生DateTime.parse()、intl包的DateFormat、以及jiffy包。测试环境覆盖 Android 8~14、iOS 14~17共 12 款主流机型。结论很明确DateTime.parse()在标准 ISO 字符串带Z或完整时区下表现稳定但对业务中常见的2023/05/20、2023-05-20 12:00、2023年05月20日等格式完全不可用jiffy功能强大但体积大增加约 120KB且其parse方法内部仍调用DateTime.parse()并未解决根本问题而intl的DateFormat是唯一能提供完全可控、可预测、可单元测试的解析方案。DateFormat(yyyy/MM/dd).parse(2023/05/20)的行为在所有设备上完全一致且支持自定义模式、时区强制指定、错误抛出控制。更重要的是intl是 Flutter 官方推荐的国际化方案生态成熟社区支持好。因此我们的核心设计思路是对已知格式的字符串一律使用DateFormat进行强约束解析对未知或混合格式先做正则预处理再交由DateFormat仅在确认字符串为标准 ISO 且含时区标识时才谨慎使用DateTime.parse()。这看似多了一步但换来的是线上稳定性提升 90% 以上。3. 核心细节解析与实操要点从字符串到毫秒的七道关卡3.1 关卡一识别字符串的真实格式——7 种常见变体及检测逻辑业务中接收到的时间字符串千奇百怪必须先分类才能选择正确的解析方式。我们归纳出最常出现的 7 种变体并给出可靠的检测正则表达式已在生产环境稳定运行 18 个月变体类型示例字符串检测正则关键特征解析策略1. 标准 ISO UTC2023-05-20T04:00:00.000Z^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d)?Z$末尾ZDateTime.parse(str)结果_isUtctrue2. 标准 ISO 时区偏移2023-05-20T12:00:0008:00^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d)?[-]\\d{2}:\\d{2}$/-HH:mmDateTime.parse(str)结果_isUtcfalse但时间戳正确3. 简化 ISO无时区2023-05-20T12:00:00^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d)?$有T无时区高危必须用DateFormat强制指定时区否则依赖设备4. 纯日期2023-05-20^\\d{4}-\\d{2}-\\d{2}$无T无时间同上且需明确是“当天开始”还是“当天结束”5. 中文分隔符2023/05/20、2023年05月20日^\\d{4}[\\/年]\\d{1,2}[\\/月]\\d{1,2}[日]?$/或年月日DateFormat自定义模式如yyyy/MM/dd6. 空格分隔时间2023-05-20 12:00:00^\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2}:\\d{2}(\\.\\d)?$空格代替T严禁parse先str.replaceAll( , T)再检测7. 时间戳字符串1684574400000^\\d{13}$纯数字 13 位直接int.parse(str)后DateTime.fromMillisecondsSinceEpoch()提示正则检测必须放在解析前且要按表格顺序从上到下匹配因为2023-05-20T12:00:00也会匹配纯日期正则但优先级更低。我们封装了一个TimeParser.detectFormat(String str)工具方法返回TimeFormatType枚举后续流程据此分支。3.2 关卡二DateTime.parse()的安全使用守则——三不原则即使面对标准 ISO 字符串DateTime.parse()也有隐藏风险。我们制定并严格执行“三不原则”一不不解析无时区标识的T格式字符串。如前所述2023-05-20T12:00:00在不同设备上行为不一致。正确做法是先用正则检测若无时区则视为“业务约定为 UTC”强制追加Z后再parse。代码如下String safeParseIso(String str) { if (str.contains(Z) || str.contains(RegExp(r[-]\d{2}:\d{2}))) { return DateTime.parse(str).toUtc().toIso8601String(); // 统一转为 UTC ISO } else if (str.contains(T)) { // 业务约定无时区 T 格式均为 UTC final utcStr $strZ; return DateTime.parse(utcStr).toIso8601String(); } throw FormatException(Unsupported ISO format: $str); }二不不信任parse的毫秒精度。实测发现Android 10 以下设备对.123456这类 6 位毫秒会截断为.123。解决方案是在parse前用正则提取毫秒部分手动补零或截断到 3 位。例如String normalizeMs(String str) { final msMatch RegExp(r\.(\d{1,6})).firstMatch(str); if (msMatch ! null) { final ms msMatch.group(1)!; final normalizedMs ms.length 3 ? ms.substring(0, 3) : ms.padRight(3, 0); return str.replaceFirst(RegExp(r\.\d{1,6}), .$normalizedMs); } return str; }三不不在build方法中调用parse。parse是同步耗时操作尤其在低端设备上单次解析可能达 2~5ms。列表页每项都parse会导致严重掉帧。正确姿势是在数据加载或状态更新时一次性完成所有时间字段的解析并缓存为DateTime或int毫秒戳UI 层只做格式化。3.3 关卡三millisecondsSinceEpoch的基准陷阱与校验方法millisecondsSinceEpoch的值本身是绝对可靠的但它的“含义”取决于你如何创建DateTime实例。这是最易混淆的点。我们用一个表格彻底厘清创建方式_isUtc值millisecondsSinceEpoch含义典型使用场景风险提示DateTime.now()false本地时间对应的 UTC 时间戳获取当前本地时刻传给后端前必须.toUtc().millisecondsSinceEpochDateTime.utc()trueUTC 时间对应的 UTC 时间戳生成 UTC 时间点安全可直接使用DateTime.fromMillisecondsSinceEpoch(ms)false默认将ms当作 UTC 时间戳但按本地时区解释错误这是最大坑导致时间偏移必须显式isUtc: trueDateTime.fromMillisecondsSinceEpoch(ms, isUtc: true)true将ms当作 UTC 时间戳按 UTC 解释正确用于从后端时间戳重建唯一安全用法注意DateTime.fromMillisecondsSinceEpoch(1684574400000)在北京设备上会创建一个2023-05-20 12:00:00 0800的实例但它的millisecondsSinceEpoch仍是1684574400000这看起来没问题但当你调用.toLocal()时它会再次加上 8 小时偏移变成2023-05-20 20:00:00彻底错乱。这就是为什么必须加isUtc: true。我们在项目中强制启用了flutter_lints的avoid_slow_async_operations_in_sync_functions规则并添加了自定义 lintavoid_unsafe_milliseconds_since_epoch当检测到fromMillisecondsSinceEpoch未传isUtc参数时编译期报错。3.4 关卡四时区处理的黄金法则——永远用toUtc()和toLocal()不用toLocal().toUtc()开发者常犯的一个错误是拿到一个DateTime实例后先调用.toLocal()再调用.toUtc()以为这样能“标准化”。这是完全错误的。toLocal()的作用是将一个时间点用本地时区的日历系统重新表示。如果原实例_isUtctrue如DateTime.utc()创建的toLocal()会减去本地时区偏移如北京减 8 小时如果原实例_isUtcfalse如DateTime.now()创建的toLocal()是恒等操作返回自身。因此dt.toLocal().toUtc()的结果是若dt是 UTC 时间则toLocal()后变成本地时间再toUtc()又加回偏移回到原点若dt是本地时间则toLocal()无变化toUtc()减去偏移得到正确 UTC。但这个过程冗余且易错。黄金法则是所有时间点只要需要跨时区比较或存储第一步就是.toUtc()所有 UI 显示最后一步才是.toLocal()。例如后端返回一个时间戳1684574400000我们应final utcDt DateTime.fromMillisecondsSinceEpoch(1684574400000, isUtc: true); // 存储或计算用 utcDt final localDisplay utcDt.toLocal(); // 仅在需要显示时转换而不是// ❌ 危险如果 utcDt 是本地时间戳这里就错了 final wrong utcDt.toLocal().toUtc();4. 实操过程与核心环节实现一个完整的防坑转换工具类4.1 工具类骨架与核心方法设计我们封装了一个TimeConverter工具类它不依赖任何外部状态所有方法都是静态的、纯函数式的便于单元测试和复用。核心方法包括parse(String str)主入口自动检测格式并安全解析为DateTimeUTC 时间点。format(DateTime dt, {String pattern yyyy-MM-dd HH:mm:ss})将DateTime必须为 UTC格式化为本地化字符串。toTimestamp(DateTime dt)将DateTime必须为 UTC转为毫秒时间戳。fromTimestamp(int ms)将毫秒时间戳转为DateTimeUTC。isSameDay(DateTime a, DateTime b)安全的同天判断考虑时区。类的设计遵循单一职责只做转换不做业务逻辑。所有业务规则如“活动开始时间按 UTC 解释”、“用户生日按本地时区解释”由调用方决定工具类只保证转换过程的确定性和安全性。4.2parse()方法的完整实现与逐行注释以下是parse()方法的生产级实现已通过 200 种字符串组合的单元测试/// 安全解析时间字符串为 UTC DateTime 实例。 /// 支持格式ISO UTC (Z), ISO 时区 (08:00), 纯日期 (2023-05-20), 中文分隔符 (2023/05/20) 等。 /// 不支持空格分隔 (2023-05-20 12:00)、非标准缩写 (May 20)、模糊格式。 /// throws FormatException 当格式不支持或解析失败时。 static DateTime parse(String str) { if (str null || str.trim().isEmpty) { throw FormatException(Time string is null or empty); } final cleanStr str.trim(); // 步骤1检测并处理时间戳字符串13位数字 if (RegExp(r^\d{13}$).hasMatch(cleanStr)) { final ms int.tryParse(cleanStr); if (ms null) throw FormatException(Invalid timestamp: $cleanStr); return fromTimestamp(ms); // 复用 fromTimestamp 的安全逻辑 } // 步骤2检测并处理 ISO 格式含 Z 或时区 if (cleanStr.contains(Z) || cleanStr.contains(RegExp(r[-]\d{2}:\d{2}))) { try { final dt DateTime.parse(cleanStr); // 关键无论输入是否 UTC输出统一为 UTC 时间点 return dt.isUtc ? dt : dt.toUtc(); } on FormatException catch (e) { throw FormatException(Failed to parse ISO time: $cleanStr, e); } } // 步骤3检测并标准化 T 格式无时区 if (cleanStr.contains(T)) { // 业务强约定所有无时区 T 格式均视为 UTC final utcStr cleanStr.endsWith(T) ? $cleanStr00:00Z : $cleanStrZ; try { return DateTime.parse(utcStr); } on FormatException catch (e) { throw FormatException(Failed to parse T-format as UTC: $cleanStr, e); } } // 步骤4检测并处理纯日期格式2023-05-20 if (RegExp(r^\d{4}-\d{2}-\d{2}$).hasMatch(cleanStr)) { // 业务约定纯日期表示当天 00:00:00 UTC try { final dt DateFormat(yyyy-MM-dd).parse(cleanStr); // DateFormat.parse 返回的是本地时间需转为 UTC return dt.toUtc(); } on FormatException catch (e) { throw FormatException(Failed to parse date-only: $cleanStr, e); } } // 步骤5检测并处理中文/斜杠分隔符 if (RegExp(r^\d{4}[\\/年]\d{1,2}[\\/月]\d{1,2}[日]?$).hasMatch(cleanStr)) { // 统一替换为标准分隔符便于 DateFormat 解析 final normalized cleanStr .replaceAll(RegExp(r[年月日]), -) .replaceAll(RegExp(r[\\/]), -); try { final dt DateFormat(yyyy-MM-dd).parse(normalized); return dt.toUtc(); } on FormatException catch (e) { throw FormatException(Failed to parse Chinese/slash date: $cleanStr, e); } } // 步骤6兜底处理——尝试用 DateFormat 的宽松模式 // 仅用于兼容历史数据不推荐新业务使用 try { final dt DateFormat.yMd().parseStrict(cleanStr); return dt.toUtc(); } on FormatException { throw FormatException(Unsupported time format: $cleanStr); } }4.3fromTimestamp()与toTimestamp()的安全实现这两个方法是整个工具链的基石必须 100% 可靠/// 将毫秒时间戳安全转换为 UTC DateTime。 /// param ms 毫秒时间戳必须为 UTC 基准如后端返回。 /// param isUtc 强制声明避免开发者误用。 static DateTime fromTimestamp(int ms) { // 关键校验防止负数时间戳1970年前导致崩溃 if (ms 0) { // 业务约定负数时间戳视为无效返回 Unix epoch return DateTime.utc(1970); } // 必须显式 isUtc: true这是安全底线 return DateTime.fromMillisecondsSinceEpoch(ms, isUtc: true); } /// 将 UTC DateTime 安全转换为毫秒时间戳。 /// param dt 必须为 UTC 时间点调用方需确保。 static int toTimestamp(DateTime dt) { // 强制校验确保传入的是 UTC 时间点 if (!dt.isUtc) { // 开发者违反约定记录警告但不崩溃便于调试 debugPrint([TimeConverter] Warning: toTimestamp called with non-UTC DateTime: $dt); // 自动纠正转为 UTC 后再取戳 return dt.toUtc().millisecondsSinceEpoch; } return dt.millisecondsSinceEpoch; }4.4format()方法的本地化与性能优化格式化是高频操作必须兼顾准确性和性能/// 将 UTC DateTime 格式化为本地化字符串。 /// param dt 必须为 UTC 时间点。 /// param pattern DateFormat 模式如 yyyy-MM-dd HH:mm:ss。 /// param locale 可选指定语言环境默认为系统 locale。 static String format(DateTime dt, {String pattern yyyy-MM-dd HH:mm:ss, String? locale}) { if (!dt.isUtc) { throw ArgumentError(DateTime must be UTC for safe formatting); } // 性能关键DateFormat 实例是线程安全的但创建开销大故缓存 final key $pattern-$locale; final format _formatCache[key] ?? DateFormat(pattern, locale); // toLocal() 是安全的因为 dt 是 UTCtoLocal() 会正确应用本地偏移 return format.format(dt.toLocal()); } // 静态缓存避免重复创建 DateFormat 实例 static final MapString, DateFormat _formatCache {};5. 常见问题与排查技巧实录来自 12 个真实项目的血泪教训5.1 问题速查表高频 Bug 现象、原因与修复方案现象可能原因快速定位方法修复方案影响范围列表时间显示比手机快 8 小时后端返回2023-05-20T12:00:00前端用DateTime.parse()解析设备在北京parse按本地时区解释为2023-05-20 12:00:00 0800再toLocal()又加 8 小时在解析后打印dt.toString()和dt.toLocal().toString()看是否重复偏移使用TimeConverter.parse()替换所有DateTime.parse()全平台高概率倒计时在 iOS 上正常Android 上跳变Android 低版本DateTime.parse()对毫秒处理不一致导致millisecondsSinceEpoch计算误差在倒计时逻辑中打印targetTime.millisecondsSinceEpoch和DateTime.now().millisecondsSinceEpoch的差值看是否为整数统一用fromTimestamp()创建目标时间避免parseAndroid 8~10中概率缓存失效相同时间戳在不同设备上生成不同缓存 key缓存 key 由DateTime.toString()生成而toString()输出包含时区信息北京和纽约设备输出不同检查缓存 key 生成逻辑打印dt.toString()和dt.toIso8601String()对比缓存 key 必须用toIso8601String()或millisecondsSinceEpoch生成全平台高概率“今天”按钮点击后筛选出明天的数据业务逻辑用DateTime.now().toLocal()获取“今天”但toLocal()在夏令时切换日行为异常在夏令时切换日前后打印DateTime.now().toLocal().day和DateTime.now().toUtc().day“今天”逻辑必须用DateTime.now().toUtc().toLocal()即先转 UTC 再转本地夏令时地区低概率但影响大后台接口报错“时间不能早于当前时间”前端用DateTime.now().millisecondsSinceEpoch生成时间戳但未.toUtc()后端按 UTC 解析发现时间晚于服务器时间抓包查看请求体中的时间戳与服务器当前时间戳对比所有发送给后端的时间戳必须DateTime.now().toUtc().millisecondsSinceEpoch全平台高概率5.2 排查技巧三步定位时间相关 Bug当遇到时间问题我们固定执行以下三步排查法90% 的问题能在 5 分钟内定位第一步打桩日志锁定源头。在所有时间相关变量赋值处添加日志final rawStr apiResponse.time; debugPrint([TimeDebug] Raw string: $rawStr); final parsed TimeConverter.parse(rawStr); debugPrint([TimeDebug] Parsed DateTime: $parsed); debugPrint([TimeDebug] Parsed ms: ${parsed.millisecondsSinceEpoch}); debugPrint([TimeDebug] Now ms: ${DateTime.now().toUtc().millisecondsSinceEpoch});重点观察Parsed ms是否符合预期如2023-05-20T00:00:00Z应为1684569600000以及与Now ms的差值是否合理。第二步时区快照验证一致性。在 App 启动时打印设备时区信息debugPrint([TimeDebug] Device timezone: ${DateTime.now().timeZoneName} (${DateTime.now().timeZoneOffset.inHours})); debugPrint([TimeDebug] UTC now: ${DateTime.now().toUtc()}); debugPrint([TimeDebug] Local now: ${DateTime.now()});这能快速发现设备时区设置异常如用户手动修改为 GMT0。第三步单元测试覆盖杜绝回归。为每个业务时间逻辑编写测试例如“活动开始时间解析”test(Activity start time parsing, () { // 给定后端返回的字符串 final backendStr 2023-05-20T00:00:00Z; // 解析 final dt TimeConverter.parse(backendStr); // 断言必须是 UTC 时间点 expect(dt.isUtc, isTrue); // 断言毫秒戳必须精确 expect(dt.millisecondsSinceEpoch, 1684569600000); // 断言北京时间显示应为 2023-05-20 08:00:00 final beijing dt.toLocal(); expect(beijing.year, 2023); expect(beijing.month, 5); expect(beijing.day, 20); expect(beijing.hour, 8); // 北京 UTC8 });5.3 实操心得那些文档里不会写的细节关于DateTime的比较DateTime的操作符比较的是时间点是否相等即millisecondsSinceEpoch是否相同与时区无关。所以DateTime.utc(2023, 5, 20) DateTime(2023, 5, 20, 0, 0, 0, 0, 0).toUtc()为true。但DateTime.utc(2023, 5, 20) DateTime(2023, 5, 20)为false因为后者是本地时间millisecondsSinceEpoch不同。这个细节在状态管理中很重要避免因时区不同导致setState未触发。DateTime的不可变性陷阱DateTime是不可变对象所有add()、subtract()方法都返回新实例。新手常写dt.add(Duration(hours: 1));忘记赋值导致dt未变。我们团队的代码规范强制要求所有DateTime操作必须赋值且 IDE 配置了avoid_unused_local_variableslint。intl包的DateFormat初始化开销DateFormat(yyyy-MM-dd)的构造函数是同步的但内部会做大量正则编译首次调用可能耗时 1~2ms。因此我们所有DateFormat实例都在类初始化时创建为static final绝不放在build或循环中。millisecondsSinceEpoch的最大值Dart 的int是 64 位millisecondsSinceEpoch最大可表示到公元 292278994 年远超业务需求。但要注意JavaScript 的Date.now()返回的是毫秒而某些老接口可能返回秒级时间戳10 位直接fromMillisecondsSinceEpoch会导致时间错乱 1000 倍。我们工具类中增加了fromSecondsSinceEpoch(int seconds)方法并在parse时自动检测 10 位数字。真机测试的必要性模拟器的时区行为与真机不同。我们有一个自动化脚本每天凌晨在 5 款主力机型华为 P50、小米 13、iPhone 13、三星 S22、Pixel 6上运行时间测试用