c++14起chrono_literals需同时包含头文件并启用std::literals::chrono_literals命名空间，否则10s等字面量无法识别；其为编译期常量，类型精确且支持浮点，优于运行期构造的std::chrono::seconds(1)。
C++14 起，chrono_literals 是标准库自带的，不用额外安装、不用宏开关，但必须显式引入头文件并启用命名空间，否则编译直接报错。
为什么 10s 编译不过？头文件和命名空间缺一不可
常见错误现象：error: no match for 'operator*' (operand types are 'int' and 'int') 或更迷惑的 unknown type name 's'——其实编译器根本没识别出 s、ms 这些后缀。
- 必须包含
#include <chrono></chrono>（C++14 及以上） - 必须开启
std::literals::chrono_literals命名空间，推荐写法：using namespace std::literals::chrono_literals; - 不能只写
using namespace std::chrono;—— 字面量定义在子命名空间里，不传递 - 如果用在头文件中，避免
using namespace；改用显式前缀，比如10s写成std::literals::chrono_literals::operator""s(10)（不推荐，太冗长）
1s 和 std::chrono::seconds(1) 有啥区别？
表面一样，底层行为不同：字面量是编译期常量，构造函数是运行期调用。
-
1s是std::chrono::duration<long long std::ratio>></long>类型，即std::chrono::seconds的别名，但类型更精确（不依赖 typedef） -
std::chrono::seconds(1)会触发构造函数，哪怕优化后可能内联，语义上仍是运行期 - 模板推导场景下，字面量更安全，比如
auto d = 1.5s;推导为std::chrono::duration<double std::ratio>></double>，而std::chrono::seconds(1.5)编译失败（参数类型不匹配） - 性能差异几乎为零，但字面量在 constexpr 上下文中更可靠（如非类型模板参数、static_assert）
哪些单位能用？大小写、复数、浮点支持情况
标准只定义小写、单数形式： s、ms、us、ns、min、h、d（C++20 加入），没有 sec、secs、Sec 或 second。
立即学习“C++免费学习笔记（深入）”；
-
1.5s合法，推导为duration<double></double>；1.5ms同理 -
1min在 C++14/17 中不合法（C++20 才支持），误用会报undefined identifier 'min' -
2h同样是 C++20 特性，C++17 及以前只能手写2h = 2 * 60min = 120 * 60s - 没有
week、year等——chrono 不处理日历，只管线性时间间隔
跨平台或旧编译器踩坑：GCC 4.9、Clang 3.4、MSVC 2015 的兼容性
不是所有“支持 C++14”的编译器都完整实现了字面量。尤其 MSVC 2015 初版对 chrono_literals 支持不全，100ms 可能被当成整数字面量。
- GCC ≥ 5.1、Clang ≥ 3.5、MSVC ≥ 2015 Update 3 基本可用
- 若遇到
error: unable to find numeric literal operator 'operator""s'，先检查编译器版本和-std=c++14（或更高）是否生效 - 某些嵌入式 STL（如 newlib、picolibc）可能未实现字面量，此时只能退回
std::chrono::milliseconds(100) - CI 环境中建议加一行测试：
static_assert(std::is_same_v<decltype(1s), std::chrono::seconds>, "literals broken");
最容易被忽略的是命名空间——很多人记住了 #include <chrono></chrono>，却忘了 using namespace std::literals::chrono_literals;，然后花半小时查为什么 30min 报错。C++ 的字面量不是语法糖，是重载的用户定义字面量，少一个命名空间，它就只是个未声明的标识符。
