因为std::chrono_literals不是默认开启的，必须显式包含<chrono>头文件并启用std::literals::chrono_literals命名空间，否则编译器无法识别s、ms等后缀，报错unknown type name 's'。
为什么 1s 在某些编译器里报错：unknown type name 's'？
因为 std::chrono_literals 不是默认开启的，必须显式引入命名空间。C++14 起才支持这种字面量，且依赖 using namespace std::chrono_literals; 或作用域限定。
常见错误现象：error: unknown type name 's' 或 use of undeclared identifier 's'，尤其在 Clang 或较新 GCC 上更严格。
- 必须包含头文件：
#include <chrono> - 必须启用 C++14 或更高标准（
-std=c++14或-std=c++17） - 不能只靠
using namespace std;——std::chrono_literals是独立内联命名空间，需单独引入 - 推荐写法：
using namespace std::chrono_literals;放在函数内或翻译单元顶部（避免污染全局）
10ms 和 10ms + 500us 的类型推导结果是什么？
所有 chrono 字面量返回的是对应精度的 std::chrono::duration 类型，而非 int 或 long long。类型由字面量后缀决定，且支持混合运算，但会自动升为更精确的公共类型。
例如：10ms 是 std::chrono::milliseconds，500us 是 std::chrono::microseconds；两者相加时，编译器会把 10ms 转成 microseconds 再计算，结果类型为 std::chrono::microseconds。
立即学习“C++免费学习笔记（深入）”；
-
1s→std::chrono::seconds -
100ms→std::chrono::milliseconds -
250us→std::chrono::microseconds -
123ns→std::chrono::nanoseconds - 混合运算（如
1s + 500ms）结果类型是std::chrono::milliseconds（因seconds可无损转为milliseconds）
在函数参数中直接传 30s 为什么有时不匹配？
因为字面量类型太“具体”，而函数可能声明了更宽泛的 std::chrono::duration<Rep, Period> 模板参数，或用了 auto 但调用点未推导出一致类型。常见于自定义等待函数、超时接口。
例如：函数接受 std::chrono::milliseconds，但你传了 30s —— 编译器不会自动转换（除非有隐式构造函数且允许），尤其当模板参数被固定时。
- 安全做法：显式转换，如
std::chrono::milliseconds{30s}或30s.count() * 1000ms - 更通用：函数参数改用模板，如
template<typename Rep, typename Period> void wait(std::chrono::duration<Rep, Period> d) - 注意：
std::this_thread::sleep_for(30s)是 OK 的，因为该函数模板能接受任意duration类型 - 调试技巧：用
decltype(30s)::rep和decltype(30s)::period::num查看底层表示
Windows MSVC 下 1h 编译失败怎么办？
MSVC（尤其旧版本如 VS2015/2017）对 h（小时）、d（天）字面量支持不完整或缺失，1h 会被当作未声明标识符。这是标准实现差异，不是你代码写错了。
C++14 标准只要求实现 s、ms、us、ns，h 和 d 是 C++17 扩展，但 MSVC 直到 VS2019 16.8+ 才完全支持。
- 兼容写法：
1h→std::chrono::hours{1}；1d→std::chrono::hours{24}或std::chrono::days{1}（需 C++20） - 检查编译器版本：
_MSC_VER >= 1929（VS2019 16.8）才可靠支持h/d - 跨平台项目建议：避开
h/d字面量，统一用std::chrono::hours构造，或封装一层适配宏
真正容易被忽略的是：字面量看似简单，但它绑定的是编译期类型和标准版本，而不是运行值——换一个编译器或标准级别，行为就可能不同。
