企业官网建设流程全解析

1. 从一次“不可能复现”的崩溃说起

我调过最憋屈的一个bug，线上服务偶发性崩溃，日志里连崩溃点都对不上号。排查了一整天，内存踩踏、并发竞态、编译器优化嫌疑都轮了一遍，最后被老同事一句话点醒——“这个指针在调用时还活着吗？”回头翻接口文档，白纸黑字写着“调用方负责保证指针在调用期间有效”，而调用方早在上一轮循环里就把那块缓冲区释放了。Debug构建下它侥幸幸存，Release构建由于优化与内存布局不同，恐怖故事终于浮出水面。

这类问题在C++项目里实在太常见。我们习惯把锅甩给“内存问题”“并发问题”，但刨根问底，很多事故的本质是同一件事：调用方与实现方之间对接口语义的共识被单方面打破。这个共识，在设计方法学里有一个专门的名字——契约（Contract）。以契约为核心的开发方法叫Design by Contract，中文常译作契约式设计，也有人直接叫契约编程。

契约编程不是一个新语法，也不是某个框架的专利。它最早由Eiffel语言的创始人Bertrand Meyer系统化提出，核心主张是：接口不只是一组函数签名，还包括三个可以被验证的条款——前置条件、后置条件和类不变量。调用方承诺满足前置条件，实现方承诺兑现后置条件，类自身承诺在生命周期内维持不变量。任何一方违约，错误必须在第一时间变得可见，而不是潜伏到万米深的海底再爆炸。

在C++生态里，契约编程尤其值得认真对待，原因很硬核：

• C++默认不做边界检查，vector::operator[]越界是未定义行为，而不是自动抛异常；
• 裸指针、引用、迭代器、生命周期这类“隐式约定”比任何主流语言都多；
• 模板、虚函数、继承让接口的语义约束远比“参数类型正确”复杂得多。

这篇文章会从原理讲到落地，覆盖前置条件、后置条件、类不变量三个核心概念，梳理现阶段C++实现契约的几种流派与工具，再用一个连接池案例完整演示如何把契约“焊”进接口。最后是我在实际项目里踩过的坑和几条真正能帮你活下来的建议。不管你是写底层库、业务服务，还是维护一个几百万行的老项目，这套方法论都能帮你砍掉一大部分“玄学bug”。

2. 契约三件套：前置条件、后置条件与类不变量

2.1 前置条件：接口的安检门

前置条件（Precondition）是调用方在调用接口之前必须满足的条件。它划定了实现方的责任边界：只要前置条件成立，实现方就必须保证函数正常完成；如果前置条件被违反，实现方可以不做任何保证——标准库称之为“未定义行为”。

标准库就是前置条件的重度使用者。std::vector<int>::operator[]要求索引小于size()，std::sort要求迭代器有效且落在同一容器范围内，std::mutex::lock要求当前线程没有持有该锁。这些要求写在标准文档里，但代码层面往往没有任何检查。一旦违反，典型表现不是“温和报错”，而是静默的内存破坏或诡异的逻辑错乱。

自己写接口时，我建议把前置条件变成可执行的守卫，而不是留在注释里当摆设。最简单的做法是这样：

double safeRoot(double x) { // GSL 的 Expects 宏，语义上明确表达"这是接口的前置条件" Expects(x >= 0.0); // 或者用自定义宏，见第 3 节 CONTRACT_PRE(x >= 0.0); return std::sqrt(x); }

这里有一个很多新手会混淆的点：前置条件 ≠ 输入校验。两者面对的错误来源完全不同。

• 输入校验处理的是“外部不可信输入”——比如用户传了一个负数给“转账金额”，这属于预期行为，应当返回错误码或抛异常，让上层有机会恢复；
• 前置条件处理的是“调用方违反了接口协议”——比如调用方把已经释放的指针传进来，或者违反“余额必须充足”的约束。这类违约意味着程序已经处于逻辑错误状态，最理智的应对是尽快失败（fail fast），而不是收拾残局继续跑。

打个比方。输入校验像商场保安查证件，查出来顶多不让进门；前置条件像工地上的安全绳——你不系绳就上高空，安全绳的作用不是挽回你，而是让你在最显眼的地方暴露风险、立刻止损。

2.2 后置条件：实现方写给调用方的承诺书

后置条件（Postcondition）描述函数成功返回后，系统状态应当满足的性质。它是对调用方的承诺，也是调用方可以放心依赖的行为保证。

举一个日常到几乎被忽略的例子：std::vector::push_back。调用之前，容器满足size() <= capacity()；调用之后，size()恰好增加1，最后一个元素是新值，且size() <= capacity()依然成立。这个“操作前后size() <= capacity()恒成立”的约束既是vector自身的类不变量，也是push_back这条后置条件的一部分。

后置条件里有一个很容易被忽视的细节：验证它往往需要“调用前的状态”。比如检查“容量增加1”，你得先记住调用前的size()。Boost.Contract里把这个机制叫old值，函数实现里可以这样表达：

auto old_size = container.size(); // 保存调用前状态 container.push_back(item); Ensures(container.size() == old_size + 1);

后置条件与实现策略的耦合，是非常容易踩坑的地方。我给过自己一个惨痛教训：早期实现一个缓存模块时，接口承诺“返回的迭代器在下次修改前保持有效”。后来为了优化，我把底层数据结构从std::vector换成了std::unordered_map，迭代器失效规则完全变了，结果一周后线上出现奇怪的悬垂迭代器问题。教训很沉重：改变内部实现时，必须逐条审视它是否还能兑现对外公开的后置条件。后置条件本质上是接口与实现之间的一份长期契约，实现可以换，契约不能悄悄违约。

2.3 类不变量：对象的宪法

类不变量（Class Invariant）是对象从构造完成到析构开始前的整个生命周期内，始终为真的性质。构造函数负责建立不变量，析构函数负责安全退出，所有公有成员函数在执行前和返回后都必须维持不变量。

最经典的例子仍然是std::vector：size() <= capacity()、迭代器语义正确、内部缓冲区要么为空指针要么指向有效堆内存。std::shared_ptr的控制块引用计数正确性，也是一种不变量。

类不变量和封装是深度绑定的。为什么我们强调字段要private？不是因为“封装是良好习惯”，而是因为private是实现不变量的物理屏障。如果hours_和minutes_是公有字段，任何外部代码都能直接把它们改成非法值——比如minutes_ = 90，类不变量被瞬间砸碎，后续所有方法的行为都不可信。让我用一个简单类来说明：

class TimeOfDay { public: TimeOfDay(int h, int m) noexcept : hours_(h), minutes_(m) { // 构造函数的后置条件：对象不变量成立 Expects(h >= 0 && h < 24); Expects(m >= 0 && m < 60); } int hour() const noexcept { return hours_; } int minute() const noexcept { return minutes_; } // 违反不变量先例：如果允许直接修改分钟数 // void setMinute(int m) { minutes_ = m; } // 应加入守卫检查 private: int hours_; int minutes_; };

类不变量还有一个和C++对象模型相关的隐蔽陷阱：构造函数内调用虚函数。基类构造期间，虚函数绑定到基类版本，派生类成员尚未初始化，此时基类的不变量可能尚未建立。如果你在构造函数里调用一个虚函数，而这个虚函数的后置条件依赖派生类状态，结果就是契约在尚未生效时就被违约了。正确的做法是：构造期间不调用虚函数，或者把初始化逻辑拆到派生类构造之后显式调用。

3. C++中落地契约的四种流派与选型思路

3.1 断言派：把合约写成可控的守卫

最直接的方式就是assert。它简单、零依赖、几乎所有C++程序员都认识。但裸assert有三个硬伤，任何一个都足以让它在严肃项目里失职。

第一，assert在定义了NDEBUG时会被整体剥离。也就是说，发布构建（Release）下所有契约检查全部消失，典型的后果是“Debug跑得好好的，Release一上线就崩”。

第二，assert无法区分“这是接口的前置条件”和“这只是实现细节的临时检查”。代码可读性变差，别人也不知道哪些断言可以安全移除。

第三，裸assert的条件表达式在Debug下被求值，在Release下不被求值。如果条件里不小心带了副作用，比如assert(next() != -1)，那么Debug和Release的程序行为会不一致。

我的做法是封装一个分级宏，把“检查级别”显式化：

// contract.hpp #pragma once #include <cassert> #include <stdexcept> enum class ContractMode : unsigned char { off, debug, always }; #if !defined(CONTRACT_MODE) # if defined(NDEBUG) # define CONTRACT_MODE ContractMode::always # else # define CONTRACT_MODE ContractMode::debug # endif #endif #define CONTRACT_CHECK(cond) \ do { \ if constexpr (CONTRACT_MODE != ContractMode::off) { \ if (!(cond)) { \ if constexpr (CONTRACT_MODE == ContractMode::always) \ throw std::logic_error("contract violated: " #cond); \ else \ assert(false && #cond); \ } \ } \ } while (0) #define CONTRACT_PRE(cond) CONTRACT_CHECK(cond) #define CONTRACT_POST(cond) CONTRACT_CHECK(cond)

这个宏的核心价值在于三个地方：

• 条件只求值一次，避免assert(expr)在Debug模式下被求值两次的副作用问题；
• off / debug / always三档策略可以由团队在构建配置里统一指定，而不是被NDEBUG隐式绑架；
• CONTRACT_PRE和CONTRACT_POST两个宏的名字，让“这是契约检查”写进了代码本身的语义层。

需要注意，这个方案需要C++17的if constexpr。如果团队还在用C++14，可以把枚举判断改成普通if，但静态优化就会少一些。

3.2 类型派：把契约塞进类型系统

运行时的契约检查再完善，终究是“事后补救”。更优雅的路子是把一部分契约编码进类型里，让编译器在编译期就把违约挡在门外。

最典型的是gsl::not_null，它把“指针不能为空”从前置条件变成了类型约束：

void process(gsl::not_null<int*> p) { // 不需要再写 if (!p) return; 编译器已经保证 p 非空 int v = *p; }

只要调用方试图传一个可能为空的指针，代码在编译阶段就会失败。这一类工具的哲学是：能靠类型系统表达的契约，就不要等运行时检查。因为运行时检查只能发现问题，类型约束可以直接消灭问题。

同类的还有std::span。它把“裸指针 + 长度”这个隐式约定封装成单一类型：

// 旧的隐式契约：调用方必须保证 values 非空、长度是 count long long sum(const int* values, size_t count); // 类型化契约：span 自己携带长度与边界语义 long long sum(std::span<const int> values);

调用方传std::vector、std::array或C数组都可以隐式构造span，长度信息不再依赖人为记牢。

C++20的Concept就是更高维度的编译期契约。它把模板参数的前置条件从注释里的“类型必须支持XXX”提升为编译器可验证的约束：

template<typename T> concept SortableContainer = requires(T& t) { { t.begin() } -> std::sortable; { t.end() } -> std::sortable; std::same_as<decltype(t.begin()), decltype(t.end())>; }; template<SortableContainer T> void mySort(T& container) { // 编译器保证 T 满足排序所需的所有要求 }

如果传入的类型不满足SortableContainer，报错发生在编译期，而不是运行时，成本最低的契约就是这么产生的。

3.3 异常派：什么时候该抛，什么时候该崩

关于契约违约，我常被问到一个问题：“契约检查失败，应该抛异常还是直接终止程序？”

我的原则非常明确：契约违约是程序缺陷，不是可恢复的运行期错误。绝大多数情况下应该fail fast，而不是让异常传播出去。

为什么？因为前置条件被违反，通常意味着程序状态已经不可信。如果你在这个状态下继续执行、捕获异常、试图恢复，极大概率只是把崩溃从这一层推迟到更远的地方。就像地基已经裂了，你非要在上面继续加盖三层楼，最后塌方时只会损失更大。

但有一个例外：接口的外部使用者可能因为不可控的外部输入而违约。典型场景是库的公开API，调用方可能根据不完整的外部配置来调用接口。这时候用异常把违约错误抛出去，让调用方有机会恢复，反而比直接std::terminate对用户更友好。

因此我建议的划分是：

异常还有一个容易被忽视的坑：在noexcept函数里抛异常会直接触发std::terminate。如果你的接口被标记为noexcept，那么契约检查失败后的“优雅抛异常”路径根本不存在。标记noexcept之前，务必想清楚契约检查失败后到底走哪条路。

3.4 工具派：Boost.Contract与GSL的现实定位

Boost.Contract是C++里实现契约编程最“正统”的第三方库，它把前置条件、后置条件、类不变量用宏和RAII对象包装起来，在函数进出时自动检查。代码大概长这样：

int add(int x, int y) { int result; boost::contract::check c = boost::contract::function() .precondition([&] { // 前置条件… }) .postcondition([&] { // 后置条件… }); result = x + y; return result; }

说实话，我在实际项目中很少看到团队真正用Boost.Contract。原因有三个：

• 它改变了函数的书写结构，代码侵入性强，学习成本高；
• 引入了额外的RAII和闭包开销，在热路径上性能敏感；
• 很多团队评估后认为“投入产出比不如自定义宏 + 类型约束”。

相比之下，微软的GSL（Guidelines Support Library）要轻量得多。Expects和Ensures本质上是宏，代价可以忽略，配合not_null、span这些类型，基本覆盖了日常80%的契约需求。我的默认选型就是GSL，只有在某个模块的契约复杂度远超“几个条件检查”时，才会考虑Boost.Contract。

3.5 C++26的Contracts机制：语言级支持还会远吗

经常有朋友问：“C++是不是很快就有语言级别的契约支持了？”这个话题在WG21（C++标准委员会）确实讨论了很多年。从最初的属性式方案，到后来提出的pre/post关键字方案，目标是让前置/后置条件成为函数声明的一部分，能被编译器理解、检查和优化。例如提案中设想的形式类似：

int divide(int a, int b) [[expects: b != 0]] [[ensures result: a / b * b + a % b == a]];

但目前这个提案还没有正式落入C++26标准，主流编译器也没有稳定的完整实现。我的看法是：在语言级契约普及之前，先把手头的assert、GSL、类型约束用好，远比等一个“完美的C++26”有价值。设计方法论先进二十年，工具落后一点没关系，关键是理念要落地。

我把上面的几种流派汇总成一张对比表，方便选型：

4. 实例重构：把连接池的隐含假设全部显式化

4.1 需求现状：一个到处是“暗雷”的连接池

理论讲再多，不如一个完整案例来的实在。我虚构一个贴近实战的模块：连接池。

连接池的需求本身不复杂——维护一组连接对象，调用方从池子“借”一个连接，用完再“还”回来。难的是它内部的隐含假设多得惊人：

• 借连接时，池里必须有空闲连接，不能借空；
• 归还的连接必须是池子曾经借出去的，不能是外部凭空构造的；
• 同一个连接不能重复归还两次；
• 借出去的连接在池里必须被标记为“已占用”，不能同时借给两个人；
• 归还后，连接要重新变为空闲，计数必须与真实状态一致。

任何一条假设被打破，都可能导致连接泄漏、重复使用同一连接、计数漂移。这些bug在日志里往往表现为“连接被关闭后仍在使用”或“池容量神秘变小”。没有契约保护的版本，几乎必然会在某个深夜爆雷。

4.2 定义契约：让每条假设都有名有姓

在写实现之前，我先把合同条款写清楚，贴到代码注释最上方：

// 前置条件： // - acquire：池中至少存在一个空闲连接 // - release：传入的连接确实是本池曾经借出的连接，且当前处于"已借出"状态 // 后置条件： // - acquire：返回的连接在池中被标记为"已借出"，空闲计数减一 // - release：该连接在池中重新变为空闲，空闲计数加一 // 类不变量： // - 每个连接要么空闲、要么已借出，不会出现第三种状态 // - free_count_ 等于池中空闲连接的真实数量 // - 借出的连接一定可以通过 acquire 追溯到合法来源

这段注释不是形式主义。它把模糊的“连接池应该没问题”变成了一组可验证、可测试、可争论的条款。之后所有检查和测试，都围绕这些条款展开。

4.3 实现代码：把契约逐条焊进去

下面是我会落地的方式。为了简洁，我用GSL的Expects/Ensures，实际项目中你完全可以换成第3.1节的自定义宏：

#include <gsl/gsl> #include <vector> #include <utility> #include <stdexcept> class Connection { public: Connection() = delete; int id() const noexcept { return id_; } private: explicit Connection(int id) noexcept : id_(id) {} int id_{-1}; // -1 表示无效/已移走 friend class ConnectionPool; }; class ConnectionPool { public: explicit ConnectionPool(size_t capacity) : pool_(capacity), used_(capacity, false), free_count_(capacity) { Expects(capacity > 0); for (size_t i = 0; i < capacity; ++i) { pool_[i] = Connection(static_cast<int>(i)); } Ensures(size() == capacity); Ensures(available() == capacity); } Connection acquire() { Expects(available() > 0); // 前置条件：池中有空闲连接 for (size_t i = 0; i < pool_.size(); ++i) { if (!used_[i]) { used_[i] = true; --free_count_; Connection out = pool_[i]; pool_[i] = Connection(-1); // 清空槽位，防止悬垂复用 Ensures(available() == free_count_); return out; } } // 理论上不可达：前置条件已经保证至少有一个空闲连接 throw std::logic_error("ConnectionPool::acquire: unreachable"); } void release(Connection&& conn) { // 前置条件：连接来自本池，且当前处于已借出状态 Expects(conn.id() >= 0); Expects(static_cast<size_t>(conn.id()) < pool_.size()); Expects(used_.at(static_cast<size_t>(conn.id()))); // 不能重复归还 const size_t idx = static_cast<size_t>(conn.id()); used_[idx] = false; pool_[idx] = std::move(conn); conn.id_ = -1; // 把移后对象置为无效 ++free_count_; Ensures(available() == free_count_); Ensures(!used_[idx]); } size_t size() const noexcept { return pool_.size(); } size_t available() const noexcept { return free_count_; } private: std::vector<Connection> pool_; std::vector<bool> used_; size_t free_count_; };

这段代码的关键设计点有三个：

第一，Connection的构造函数是私有的，只有ConnectionPool可以创建连接对象。这就堵死了“外部凭空构造一个假连接来归还”的路子——契约的漏洞从根源上被类型系统堵住了一部分。

第二，release接收的是Connection&&，也就是右值引用，强制调用方用std::move显式表达“我放弃这个连接”。归还接口拿走对象后，立即把内部id_重置为-1。这样即使调用方手滑再release一次同一个对象，也会在第一条前置条件上当场失败，而不是静默地破坏池状态。

第三，所有Ensures都放在函数返回前，它们是承上启下的“回头检查”，确保实现没有悄悄违约。这里要特别说明：Ensures在GSL中的行为是断言式检查，如果失败会直接终止。对于ConnectionPool这种内部模块，这个策略是对的——违约就是严重缺陷，不值得恢复。

4.4 用测试证明：违约时它真的会当场暴露

光有检查还不够，还要有能触发违约的测试用例。我写测试时的思路是：先证明正常路径走得通，再故意走几条断路，确认契约守卫真的在起作用。

void test_normal_usage() { ConnectionPool pool(3); assert(pool.available() == 3); auto conn = pool.acquire(); assert(conn.id() == 0); assert(pool.available() == 2); pool.release(std::move(conn)); assert(pool.available() == 3); assert(conn.id() == -1); // move 之后的对象已被置为无效 } void test_violation_acquire_when_empty() { ConnectionPool pool(1); auto conn = pool.acquire(); // 此时池已空，再 acquire 应触发前置条件失败 // 在 Debug 构建下会被 assert 拦住 } void test_violation_double_release() { ConnectionPool pool(1); auto conn = pool.acquire(); pool.release(std::move(conn)); // 第二次 release 同一个对象：conn.id() 已经是 -1，前置条件失败 pool.release(std::move(conn)); }

这组测试的价值不在于“正确”，而在于“错误会被立刻看见”。没有契约保护的连接池，第二种和第三种违约可能潜伏到很久以后才导致池计数错乱；有了契约以后，错误在发生的那一行就暴露了，这对调试来说是质变。

5. 继承场景下的契约变体：虚函数与里氏替换原则

5.1 虚函数重写时，契约应该怎么变

关于契约编程，还有一个经常被忽略但又极其重要的场景：继承和多态。Bjarne Stroustrup在《C++程序设计语言》里专门讨论过“虚函数的前置条件和后置条件必须遵守一定的约束”，这条约束被后人概括成契约版的里氏替换原则：

• 派生类重写虚函数时，前置条件只能比基类更宽松，不能更严格；
• 后置条件只能比基类更严格，不能更宽松；
• 类不变量至少与基类一样强。

为什么是这个方向？因为调用方通过基类指针/引用调用虚函数时，他唯一知道的契约就是基类注释里写的那份。如果派生类把前置条件加强了，比如基类允许x >= 0，派生类偷偷要求x > 0，那么调用方传x = 0时，基类契约说没问题，派生类却默默违约。反之，如果派生类把后置条件加强了，比如基类承诺“返回值非负”，派生类承诺“返回值大于0”，这对调用方是安全的——调用方可以根据更弱的基类契约编写代码，而实际运行得到的是更强的保证。

这里的关键认知是：调用方只依赖基类契约编写代码，因此派生类必须“接得住”基类的全部契约。任何对基类契约的削弱，都是对调用方的背叛。

5.2 违反继承契约的真实案例

最经典的案例是矩形与正方形。假设有这样一个基类：

class Rectangle { public: virtual void setWidth(double w) noexcept { width_ = w; } virtual void setHeight(double h) noexcept { height_ = h; } double area() const noexcept { return width_ * height_; } private: double width_ = 0.0; double height_ = 0.0; };

它的隐式后置条件至少包括两条：

• setWidth只修改宽度，高度不变；
• area()恒等于width_ * height_。

现在定义一个Square继承Rectangle，为了维护“正方形”不变量，它必须重写setWidth，让高度跟着宽度一起变：

class Square : public Rectangle { public: void setWidth(double w) noexcept override { Rectangle::setWidth(w); Rectangle::setHeight(w); // 强行同步高度 } void setHeight(double h) noexcept override { Rectangle::setWidth(h); Rectangle::setHeight(h); } };

看起来“正方形”这个不变量保住了，但Square::setWidth偷偷修改了高度，破坏了基类Rectangle::setWidth的“高度不变”后置条件。调用方如果持有一个Rectangle引用，调用setWidth后理所当然地认为高度没变，结果发现宽高同步变了——基类契约被违反。

这个案例的教训是：在基类契约不匹配的情况下，继承本身就是错误的建模。正方形和矩形的关系在数学上是“is-a”，在契约编程里却未必是“is-a”，因为正方形对矩形有一个不可调和的不变量冲突。遇到这种情况，更应该考虑组合而不是继承。

5.3 把继承契约写进文档与测试

C++目前没有编译器强制虚函数继承时的契约约束，所以我们必须用文档和测试来兜底。我在团队里推广过一个做法：

在基类虚函数注释里明确列出前置条件、后置条件和类不变量，然后在派生类重写函数的地方，用静态断言和单元测试确保派生类契约不弱于基类。比如基类有“前置条件：w > 0”，派生类测试里就故意传w = 0，确认基类契约允许、派生类也不崩溃。这些测试的代码可能有点“自证清白”的味道，但它们像安全绳一样，能在代码评审阶段拦住大量不显眼的违约。

6. 实战心得：让契约真正存活在团队代码里的建议

6.1 契约检查不是日志，更不是错误处理

我见过不少团队把assert和日志混为一谈：既想检查契约，又想在Release下“记录一下然后继续跑”。这其实是两件不同的事——日志是观测手段，契约是正确性约束。契约违约后继续跑，就像汽车仪表盘报警了你把灯泡抠掉继续开，车子迟早要散架。

正确的姿态是：契约违约就让它响亮地失败。Debug下断言崩，Release下根据策略抛异常或终止，然后由测试和监控系统把问题暴露出来。宁可一周崩一次，也不要让隐患在线上潜伏三个月后爆一个大的。

6.2 Release构建不能无脑全关

如果说断言的NDEBUG陷阱是“Release全关”的默认行为，那我的建议是：核心模块的契约检查在Release下至少要保留一定级别。全部关闭省下的那点性能，往往不够一次线上事故的排查成本。你可以在构建系统里定义：

• 核心库模块：CONTRACT_MODE设为always；
• 普通业务模块：CONTRACT_MODE设为debug；
• 热路径性能敏感函数：单独用off或直接不写契约，用单元测试替代。

说白了，契约检查也是一种“保险”，关键地方不能省。如果你心疼性能，优先做的是用类型契约在编译期解决问题，而不是关闭运行时的检查。

6.3 契约条件里坚决不带副作用

这是我在代码评审里反复强调的一条铁律：契约检查的表达式，必须是无副作用的纯判断。像assert(pop() == expected)这种写法，等于是把业务逻辑偷偷塞进了检查代码。一旦某个构建模式关闭了检查，pop()就不会被执行，程序行为瞬间漂移，而且这种漂移极难定位。

如果你真的需要“先做某个操作再验证”，请把操作拆到检查之外：

auto item = pop(); CONTRACT_POST(item.hasValue()); // 检查的是已经拿到的结果

6.4 跨模块接口，契约要写进文档并配测试

同一团队内部的接口，契约靠代码评审就能维持。但跨模块、跨团队、跨部门的接口，契约必须成为“接口文档的一部分”，否则任何一方的离职或快节奏迭代都可能导致契约被无意识变更。

我的习惯是：对每个跨模块接口，在头文件里写一个“契约块”，明确列出前置条件、后置条件和不变量，并配套一个契约测试文件。这些测试不一定都要跑，但在架构评审时，它们是最好的“共同语言”——让争论从“我觉得应该这样”变成“你违反了这条契约”。

6.5 不是所有接口都需要满配契约

最后一点，也是我吃过亏才总结出来的：不要矫枉过正。给每一个两行的小函数都写满前置条件、后置条件、不变量，只会让代码变得臃肿，团队成员也会对契约产生抵触。我的粒度判断标准是：

• 非平凡函数（超过10行、有状态变更、返回复杂结果）——建议写；
• 跨模块公开接口——必须写；
• 模板和虚函数——必须写；
• 一眼看到底的纯查询函数——可以不写，用类型约束就够。

我个人在实际操作中的体会是，契约编程最大的价值不在于“写出永远不会坏的程序”，而在于强迫你在一开始就把接口的方向盘握稳：调用前的世界长什么样，调用后的世界长什么样，对象活着的时候什么绝对不能变。这三个问题想清楚了，代码通常都简洁不少，因为很多含糊的分支根本不需要存在。

如果现在再遇到“不可能复现”的崩溃，我不会先怀疑编译器，而是会先去找那个没有写进代码里的前置条件。多半，它就在那安安静静地等着下一次被违约。