static_assert必须写在函数外，因它是编译期检查，c++标准仅允许其出现在命名空间、类定义或模板内部等翻译单元顶层位置，函数体内会报错。
static_assert 为什么必须写在函数外？
因为 static_assert 是编译期检查，而函数体内属于运行时作用域（哪怕函数是 constexpr），C++ 标准只允许它出现在命名空间、类定义或模板内部等“翻译单元顶层”位置。写在函数里会直接报错：error: static_assert declaration not allowed here。
常见误用场景：想在某个工具函数开头做类型校验，结果把 static_assert 塞进函数体——它不认。
- 正确位置：头文件顶部、类定义中、模板函数定义外层
- 若需函数级约束，改用
requires（C++20 概念）或 SFINAE +std::enable_if - 模板内可放函数体外 + 函数体内（C++17 起允许在 block scope，但仅限模板实例化上下文）
字符串字面量不能当 static_assert 的失败消息？
可以，但必须是字符串字面量（"..."），不能是 std::string、变量、宏展开结果（除非该宏最终展开为字面量）。否则触发 error: non-type template argument is not a constant expression。
典型翻车点：用 BOOST_STRINGIZE 或自定义日志宏拼接消息，结果宏没被完全展开成字面量。
立即学习“C++免费学习笔记（深入）”；
- ✅
static_assert(sizeof(int) == 4, "int must be 4 bytes"); - ❌
static_assert(..., std::string("bad").c_str()); - ❌
#define MSG "size check"; static_assert(..., MSG);（某些旧编译器不认） - ⚠️ C++20 起支持更灵活的字符串常量表达式，但主流项目仍建议用纯字面量保兼容
模板推导失败时，static_assert 怎么避免“SFINAE 友好性丢失”？
如果在模板定义里直接写 static_assert，且断言条件依赖模板参数，一旦失败就会导致硬错误（hard error），而不是安静地从重载集中剔除——这破坏了 SFINAE 行为，让泛型代码无法 fallback。
比如你写了个通用序列化函数模板，想限制只接受 POD 类型，但用 static_assert(std::is_pod_v<t>, "...")</t>，那所有非 POD 类型调用都会编译失败，而非静默跳过。
- ✅ 改用
requires（C++20）：template<typename t> void serialize(T&& t) requires std::is_pod_v<:decay_t>> { ... }</:decay_t></typename> - ✅ 或传统方式：
template<typename t std::enable_if_t>>, int> = 0></typename> - ❌ 不要在模板参数推导路径上放无条件
static_assert - 注意：
static_assert在模板特化体内部（如全特化函数体）是安全的，因不参与推导
跨平台编译期断言要注意哪些隐式类型陷阱？
不同平台对内置类型宽度、对齐、符号扩展的默认约定不同，static_assert 容易在 Windows/MSVC 和 Linux/Clang 上行为不一致。最常见的是指针与整数转换、sizeof(void*)、alignof 值。
比如 static_assert(sizeof(size_t) == sizeof(void*), "...") 在 LLP64（Windows 64）下成立，在 LP64（Linux/macOS）下也成立，但若换成 long 就不一定——MSVC 的 long 是 4 字节，Clang/GCC 在 64 位下是 8 字节。
- 优先用标准固定宽度类型：
uint64_t、intptr_t，而非long或size_t（后者虽常用，但语义依赖 ABI） - 涉及指针运算的断言，用
std::uintptr_t替代裸unsigned long - 对齐检查别只信
alignof(T)，某些平台（如 ARM）对结构体有额外 padding 规则，实际布局需用offsetof验证
