最可靠做法是用 std::chrono::system_clock 获取毫秒精度时间点后相减并转为带小数的秒数；避免混用时钟、错误截断或依赖非标准解析，UTC 时间需手动校准时区偏移。
用 std::chrono 做高精度时间差计算最可靠
直接用 std::chrono::system_clock 获取带毫秒精度的时间点，再相减转成秒——这是 C++11 以后唯一推荐的跨平台做法。别碰 time_t 或 struct tm，它们不带毫秒，且时区/闰秒处理极不可控。
常见错误是把两个 std::chrono::system_clock::time_point 直接相减后用 count() 得到纳秒或微秒值，却忘了除以 1000000.0 转成秒（含小数部分）。更糟的是用 duration_cast<seconds></seconds> 强制截断，会丢掉毫秒信息。
- 必须用浮点类型的
duration_cast<duration>></duration>或手动除法保留小数 - 确保两个时间点都来自同一时钟（
system_clock），混用steady_clock会导致未定义行为 - 如果日期来自字符串（如
"2024-03-15T14:23:45.678"），先用std::get_time+std::mktime解析为time_t，再转成system_clock::time_point；注意mktime默认按本地时区解析，UTC 时间需手动调整
解析 ISO 格式字符串时小心时区和精度截断
标准库不原生支持带毫秒的 ISO 8601 字符串解析，std::get_time 最多读到秒。想正确解析 "2024-03-15T14:23:45.678Z"，得手动拆分：先用 strptime（POSIX）或 std::get_time 解析前 19 位（到秒），再从剩余字符提取毫秒字段。
示例关键步骤：
立即学习“C++免费学习笔记（深入）”；
std::string s = "2024-03-15T14:23:45.678Z";
std::tm tm = {};
std::istringstream ss(s.substr(0, 19));
ss >> std::get_time(&tm, "%Y-%m-%dT%H:%M:%S");
auto tp = std::chrono::system_clock::from_time_t(std::mktime(&tm));
int ms = std::stoi(s.substr(20, 3)); // 提取 .678 中的 678
tp += std::chrono::milliseconds(ms);注意：std::mktime 会把 tm 当作本地时间处理，若原始字符串是 UTC（带 Z），需减去本地时区偏移，否则结果偏差数小时。
std::chrono::duration_cast 用错会导致毫秒丢失
这是最常踩的坑：写 auto diff = end_tp - start_tp; auto secs = std::chrono::duration_cast<:chrono::seconds>(diff).count();</:chrono::seconds> —— 这得到的是向下取整的整秒数，678 毫秒直接被扔了。
要保留毫秒级精度并转成带小数的秒数，必须：
- 用
std::chrono::duration<double>(diff).count()</double>，自动转成秒为单位的double - 或显式转成毫秒再除：
std::chrono::duration_cast<:chrono::milliseconds>(diff).count() / 1000.0</:chrono::milliseconds> - 避免用
long long接结果，否则隐式截断小数
性能上无差异，但语义清晰度差很多：前者明确表达“以秒为单位的浮点持续时间”，后者容易让人误以为在算整毫秒数。
Windows 下 GetSystemTimeAsFileTime 不推荐用于跨平台秒数计算
虽然它返回 100 纳秒精度的 FILETIME，但换算复杂（需减去 Windows epoch 偏移、除以 1e7）、不跨平台、且与 std::chrono::system_clock 的 epoch 不一致（后者基于 Unix epoch）。硬要用会导致 Linux/macOS 编译失败，或 Windows 上结果与标准库时间点不一致。
真正需要超高精度（如微秒级性能计时）才考虑 steady_clock，但它的值不能直接对应日历日期——如果你输入的是“2024-01-01”和“2024-01-02”这种可读日期，steady_clock 根本没法解析。
实际项目里，只要求毫秒级精度，system_clock + 手动解析字符串就足够稳；真有纳秒需求，得用第三方库（如 Howard Hinnant 的 date 库），标准库目前不支持纳秒级日历运算。
