C++26 contracts 是编译期可配置的契约检查机制，不替代异常或断言；前置条件应优先用[[expects:…]]（调用方义务），其表达式须为consteval上下文；Clang 18需-std=c++2b -fcontracts -fcontract-control=on启用，但标准未冻结、支持不完善，生产环境暂不可用。
C++26 的 contracts 并不会替代异常或断言，它只提供编译期可配置的前置/后置/断言检查入口，且目前标准尚未冻结，主流编译器（GCC、Clang）仍处于实验性支持阶段，[[expects: ...]] 等语法在实际项目中暂不可用于生产环境。
前置条件标注用 [[expects: ...]] 还是 [[assert: ...]]？
二者语义不同：[[expects: ...]] 表示调用方必须满足的契约（caller obligation），违反时行为由实现定义（可能中止、忽略或抛出）；[[assert: ...]] 是函数内部断言（callee responsibility），更接近传统 assert()。若你希望把参数校验逻辑“推给调用方负责”，并让接口契约显式暴露在签名附近，优先选 [[expects: ...]]。
注意：[[expects: x > 0]] 中的表达式必须是常量求值上下文（consteval-compatible）——不能调用非常量函数、不能访问非静态成员、不能有副作用。常见误用如 [[expects: !vec.empty()]]（vec 不可见）或 [[expects: log(x) > 1]]（log 非 consteval）都会导致编译失败。
Clang 18 如何启用实验性 Contracts 支持？
Clang 18 默认不启用 contracts，需显式开启，并配合特定语言模式：
立即学习“C++免费学习笔记（深入）”；
- 使用
-std=c++2b（不是c++26，后者尚无标准定义） - 添加
-fcontracts编译选项 - 通过
-fcontract-control=on/=off/=audit控制检查级别（audit仅生成诊断不中止）
例如：
clang++ -std=c++2b -fcontracts -fcontract-control=on contract_example.cpp
若漏掉 -fcontracts，所有 [[expects:...]] 将被静默忽略，连警告都没有——这是最容易踩的坑。
[[expects: ...]] 和传统 if (!condition) throw ... 的关键差异
核心区别不在“是否检查”，而在于“谁控制检查时机与开销”：
- 传统
if检查永远执行，无法在发布版中剥离 -
[[expects: ...]]可被编译器整体禁用（-fcontract-control=off），零运行时成本 - Contracts 允许分层：调试版启用
on，测试版用audit记录但不停机，发布版关掉 - Contracts 不参与重载决议，不影响 SFINAE 或模板推导
但也要注意：目前 Clang 对 contracts 的诊断信息极其简陋，报错常为 error: expected expression，而非指出契约表达式哪里非法——需要人工逐段注释排查。
为什么现在就写 [[expects: ...]] 很可能白忙活？
C++26 标准文本仍在修订中，Contracts 的语法、语义和 ABI 影响都未稳定。例如：
- 是否允许在模板中使用
[[expects: T::value > 0]]？目前 Clang 拒绝，但提案曾讨论放宽 - 当基类函数带
[[expects]]，派生类重写时是否继承？标准未规定 - 链接时多个 TU 含不同 contract 级别（
onvsoff）是否 ODR-violation？尚未明确
除非你在做编译器开发或标准草案验证，否则当前阶段把精力放在清晰的文档注释（如 // Requires: x != nullptr）和单元测试覆盖上，比硬塞实验性 contracts 更可靠。