std::get_time无法解析RFC 3339因其不支持小数秒、带冒号时区偏移（如+08:00）和Z标识，解析会在小数点或冒号处截断；推荐使用Howard Hinnant的date库，其parse函数支持%E*S%Oz格式精确解析毫秒与带冒号偏移。
std::get_time 无法正确解析 RFC 3339，为什么？
RFC 3339 时间格式（如 2024-05-21T13:45:30.123Z 或 2024-05-21T13:45:30.123+08:00）包含毫秒、时区偏移（带冒号）、甚至可能有微秒，而 std::get_time 的标准格式符（如 %Y-%m-%dT%H:%M:%S）不支持解析小数秒，也无法处理带冒号的时区（+08:00），更不识别 Z。直接用它读取会停在小数点或冒号处，导致解析截断或失败。
推荐方案：用 Howard Hinnant 的 date 库（C++20 前事实标准）
date 库是目前最可靠、轻量、跨平台的 RFC 3339 解析方案，已被 C++20 的 <chrono> 部分吸收，但 C++20 原生仍不支持完整 RFC 3339（比如带毫秒和冒号的偏移）。date 库的 parse 函数可直接处理：
-
parse("%FT%T%z", t, s)支持+0800，但不支持+08:00 -
parse("%FT%T%Oz", t, s)中的%Oz才能匹配带冒号的偏移（如+08:00） - 毫秒/微秒需用
%E*S（S是小数秒，E表示可变精度）；例如%FT%T%E*S%Oz可解析2024-05-21T13:45:30.123456+08:00 - 对
Z，date 库自动映射为 UTC，无需额外处理
示例片段：
#include "date/date.h"
#include <string>
#include <iostream>
std::string s = "2024-05-21T13:45:30.123+08:00";
auto tp = date::parse("%FT%T%E*S%Oz", s);
// tp 是 std::chrono::time_point<date::utc_clock>，可转为 system_clock 或手动调整时区
如果只能用标准库（C++20）：有限支持 + 手动补位
C++20 的 std::chrono::from_stream 支持部分 RFC 3339，但仍有明显限制：
立即学习“C++免费学习笔记（深入）”；
- 支持
Z和+0800（无冒号），但不支持+08:00—— 必须先预处理字符串，删掉冒号（如把+08:00替换为+0800） - 不支持毫秒字段中的前导零省略（如
.1而非.100），需确保小数位数一致或自行截断/补零 - 必须指定精度：用
std::chrono::milliseconds读毫秒，std::chrono::microseconds读微秒，否则小数部分被丢弃
示例（需预处理）：
std::string s = "2024-05-21T13:45:30.123+08:00";
// 预处理：s.replace(":", "", 10, 1); // 简单删第一个冒号（实际需更严谨）
std::istringstream iss(s);
std::chrono::sys_seconds tp;
iss >> std::chrono::parse("%FT%T%zs", tp);
时区处理最容易被忽略的细节
RFC 3339 的核心是“带时区的时间点”，但很多解析结果默认落在 system_clock（本地时区）或未明确时区上下文。date 库返回的是 utc_clock 时间点，安全；而标准库解析后若未显式转为 UTC 或本地时间，后续计算（如差值、格式化）可能出错。
- 不要假设解析出的 time_point 就是 UTC —— 检查所用库的文档：date 库的
parse默认输出 UTC；C++20 的from_stream输出sys_time（即 system_clock，等价于本地时区 + offset） - 若需统一为 UTC，date 库可直接用
date::utc_clock::time_point；C++20 下需手动减去std::chrono::current_zone()->get_offset(tp) - 毫秒精度丢失常见于类型声明错误：用
std::chrono::seconds接收含小数秒的字符串，会导致截断
真正麻烦的不是解析本身，而是后续怎么用这个时间点——时区语义模糊、精度隐式降级、跨平台偏移解析差异，这些才是上线后才暴露的问题。
