为何不始终使用assert？static_assert仅支持编译时求值为何不用assert？

问得太到位了！这绝对是C++开发者刚接触断言时都会犯的疑惑——既然assert好像能通吃编译和运行时，为啥还要搞static_assert？又为啥不能全靠assert走天下？咱们拆开说清楚：

首先，static_assert有assert替代不了的核心价值 #

static_assert是编译期断言，它的作用是在代码编译阶段就把错误揪出来，而不是等程序跑起来才炸。这带来了两个关键好处：

• 更早发现问题：比如你写了个模板类，要求模板参数必须是整数类型。用static_assert(std::is_integral_v<T>, "只支持整数类型")，只要有人用字符串或者浮点数实例化这个模板，编译器立刻就报错，根本轮不到代码运行。要是换成assert，只有当程序执行到创建这个模板对象的代码时才会触发，而且如果那个分支在测试时没走到，这个错误可能会被带到生产环境里。
• 零运行时开销：static_assert完全在编译阶段处理，不会生成任何运行时代码，对程序性能没有任何影响。而assert哪怕在Debug模式下，也会带来一点点检查的开销。

举个实际的例子对比：

// 用static_assert的正确写法
template<typename T>
class NumericCalculator {
    static_assert(std::is_arithmetic_v<T>, "NumericCalculator只支持算术类型");
public:
    T add(T a, T b) { return a + b; }
};

// 如果换成assert，隐患很大
template<typename T>
class BadCalculator {
public:
    T add(T a, T b) {
        assert(std::is_arithmetic_v<T> && "只支持算术类型"); // 编译期能确定的错误，却要等到运行时检查
        return a + b;
    }
};

用BadCalculator的话，要是有人用std::string实例化，只有当调用add方法时才会触发断言，而且Release模式下这个assert会被编译器彻底删掉，直接导致程序行为异常。

然后，assert本身有不可忽视的局限性 #

就算抛开static_assert不说，也不能全靠assert，原因有这几个：

• Release模式下会失效：默认情况下，当定义了NDEBUG宏（Release编译通常会开这个），所有的assert都会被预处理为空语句。这意味着，如果你把一些必须保留的关键检查放在assert里，Release版本就会失去这些防护。比如用户传入空指针、非法参数这类情况，Release里没有assert的话，程序可能直接崩溃或者产生诡异的结果。这时候你得用自己的错误处理逻辑，比如抛出异常、调用abort()或者返回错误码。
• 只能检查运行时状态：assert的表达式必须能在运行时求值，对于编译期就能确定的错误（比如类型不匹配、常量值错误），assert根本无能为力。比如assert(sizeof(long) == 8)，这个值编译期就知道，但assert要等到程序运行才会检查，完全是浪费时机。
• 语义模糊：如果啥检查都用assert，阅读代码的人没法区分你是在检查编译期的静态约束还是运行时的动态状态。用static_assert和assert各司其职，能让代码的意图更清晰，别人一看就知道哪些是编译时必须满足的条件，哪些是运行时需要保证的状态。

总结一下 #

static_assert和assert不是替代关系，而是互补的：

• 用static_assert处理编译期就能确定的约束（比如模板参数合法性、编译器版本、常量值检查），把错误扼杀在编译阶段；
• 用assert处理Debug模式下的运行时状态检查（比如函数参数合法性、中间状态正确性），帮助开发阶段快速定位问题；
• 对于Release模式下必须保留的关键检查，别用assert，自己写错误处理逻辑。

内容的提问来源于stack exchange，提问作者user8525715