C++ Concepts：别再让模板报错像拆盲盒了

写过模板的人，大概都经历过这种时刻：改完一行代码，编译器甩给你两百行错误，从 std::vector 一直追溯到你写的 foo<T>，中间夹着七八个 enable_if_t<...> 和一串 type_traits 嵌套。你盯着屏幕，不是在 debug，是在考古——试图从错误信息的断壁残垣里，拼出自己到底哪里没满足模板的隐性契约。

C++20 的 concepts 不是给模板加个“漂亮外衣”，它是把这套隐性契约白纸黑字写进接口里，让约束可读、可查、可复用。

比如，你想写一个只接受“能相加且结果类型一致”的类型的函数：

template<typename T>
T add(T a, T b) { return a + b; }

它看似简单，但传入 std::string？没问题；传入 std::unique_ptr<int>？编译失败——但失败原因藏在 SFINAE 的层层展开里，你得手动点开十几层模板实例化才能看到 operator+ 未定义。而用 concepts，你可以直接说：

template<std::regular T>
T add(T a, T b) { return a + b; }

这里 std::regular 是标准库提供的 concept，它打包了 std::equality_comparable<T> + std::semiregular<T>，背后其实还隐含了“支持拷贝、移动、默认构造”等要求。重点不在它多高级，而在它把一组语义相关的约束，压缩成一个可命名、可组合、可传递的单元。

很多人初学 concepts，习惯把它当成“更酷的 static_assert”，于是写出这样的代码：

template<typename T>
T process(T x) {
    static_assert(std::is_integral_v<T>, "T must be integral");
    // ...
}

这本质上还是在模板体内部做兜底检查，错误发生得晚，信息依旧模糊。真正发挥 concepts 价值的方式，是把约束前移到模板参数声明处：

template<std::integral T>
T process(T x) { /* ... */ }

这时，如果你传入 double，编译器会立刻告诉你：error: no matching function for call to 'process' — constraint not satisfied: std::integral<double> is false。没有推导、没有展开、没有“候选函数太多”的干扰项——它直指核心：你传的类型，不满足这个接口的基本门槛。

更实用的是自定义 concept。比如你正在写一个序列处理库，需要区分“支持随机访问”和“仅支持前向遍历”的容器。与其每次写 requires (std::random_access_iterator<decltype(std::declval<T>().begin())>) 这种绕口令，不如定义：

template<typename T>
concept RandomAccessContainer = requires(T t) {
    t.begin();
    t.end();
    { t.size() } -> std::same_as<std::size_t>;
    typename std::iterator_traits<decltype(t.begin())>::random_access_iterator_tag;
};

注意这里用了 requires 表达式，但它不是运行时检查，而是编译期谓词。requires 块里的每一行，都是对类型能力的最小化提问：它有没有这个成员？返回类型是否匹配？标签类型是否存在？ 它不关心实现细节，只认契约本身。

实际开发中，我们常遇到“一个函数要适配多种策略”的场景。比如日志模块支持不同后端：文件、网络、内存缓冲。传统做法是靠模板特化或策略类继承，但调用方得记住每个策略的构造要求。用 concepts，可以这样设计：

template<typename Sink>
    requires WritableSink<Sink>
class Logger {
    Sink sink_;
public:
    template<typename Msg>
    void log(Msg&& msg) { sink_.write(std::forward<Msg>(msg)); }
};

只要用户传入的 Sink 类型满足 WritableSink（比如有 write() 成员函数，参数可接受字符串视图），就能无缝接入。你不用教用户“必须继承 ISink 接口”，也不用让他翻头文件找 enable_if 条件——约束就写在模板名旁边，像函数签名一样自然。

有个容易被忽略的细节：concepts 支持逻辑组合。std::integral && std::signed_integral 是合法的，std::default_constructible<T> || std::move_constructible<T> 也没问题。但要注意，|| 组合在约束失败时，错误信息可能退化为“不满足 A 且不满足 B”，不如单独拆成两个重载清晰。真正推荐的做法，是用 concept 分层建模：先定义基础能力（如 Writable），再叠加语义（如 ThreadSafeWritable），让约束像乐高一样可插拔。

最后提醒一点：concepts 不是银弹。它不能替代单元测试，也不能保证算法逻辑正确。它解决的，是“类型能不能进这个门”的问题，而不是“进门后会不会算错”。但正是这个“进门检查”，把大量编译错误从“事后追凶”变成了“事前拦截”。

下次当你再看到模板报错堆成山，不妨停下来问一句：这个函数，到底想从参数那里“要什么”？把这句话翻译成 concept，比补十个 static_assert 更省力，也更接近人脑的表达习惯。

模板不该是猜谜游戏。把契约亮出来，大家才好好好说话。