C++20标准契约：翻译阶段、ODR、模块与约束重载

简介：这份ISO/IEC 14882:2020(E)第六版C++国际标准PDF，面向C++开发者、编译器与工具链实现者、高校教学人员及标准研究读者，用于系统查阅语言语法、语义边界与实现一致性要求。压缩包内共1个PDF文件，大小约7.86MB，内容为完整标准正文，适合按章节定位与长期收藏。已有1218人学习或下载，反映其在C++学习与工程参考中的持续需求。正文涵盖实现合规性、文档组织结构、EBNF语法表示法以及词法约定，并细分解翻译阶段、字符集、预处理标记、替代标记、令牌、注释等基础规则；读者可据此理解跨平台实现差异、识别不可移植写法，也能为解析器、编译器开发及教学资料编写提供权威依据，也可作为项目实现与课程设计的核对清单，适合深入掌握语言规则的读者反复查阅。

1. 契约而非教程：C++20 标准文档到底规定了什么

翻过 ISO/IEC 14882:2020(E) 的人大多有同一个困惑：这份 2020 年 12 月发布的第六版 C++ 标准，一千多页，几乎不教你怎么写代码。它真正规定的是编译器与程序之间的一份契约——一份符合标准的 C++ 实现，必须让程序表现出标准写明的「可观察行为」，其余一切（寄存器分配、内联决策、虚表布局、对象在内存里的字节排布）全部由实现自己决定。这个反直觉的边界，解释了为什么同一段 C++ 代码在不同平台上性能能差出十倍，却都算「合规实现」。搞不清这条线，你就没法判断一段代码是「标准保证可移植」，还是「碰巧在这台机器上能跑」。下面从翻译阶段开始，把这套契约一层层拆开。

2. 翻译阶段与两套词法：#include为什么只是文本搬运

C++ 的编译模型有一个很少被讲透的前提：标准并不把「编译」当成一个整体动作，而是把它切成编号的翻译阶段（phases of translation），并且严格规定阶段的先后顺序。顺序一旦被理解错，你对#include、宏、字面量编码、>>的所有直觉都会出错。

2.1 一个字符要搬几次家：源字符集到执行字符集

标准对字符的处理是分层映射，不是「文件里是什么就是什么」。物理源文件的字节先被解释成源字符集里的字符（这一步由实现定义，通常按 UTF-8 或本地编码读取），再经过可选的花式字符名转换，最终在字面量里映射到执行字符集。所以一个汉字在源码里出现，可能经历两次转码：读取时一次，生成字符串字面量时一次。这两次用的编码不一定相同，这也是「同一份源码在某个平台上字符串长度不对」的常见来源。

C++20 在这条链上加了一层破坏性的改动：u8"..."的类型从const char[]变成了const char8_t[]，同时引入char8_t这个基础类型。类型变了，重载决议的结果就全变了。

#include <cstddef> #include <string_view> // C++17: u8"..." 的类型是 const char[] // C++20: u8"..." 的类型是 const char8_t[]，sizeof 结果不变，但类型不同 static_assert(sizeof(u8"汉") == 4); // UTF-8 三字节 + 结尾 '\0' int main() { // C++20 起这行才合法：u8 字面量不能再隐式转成 const char* std::u8string_view sv = u8"汉"; return static_cast<int>(sv.size()); // 3，不含结尾 0 }

sizeof是 4、size()是 3，这两个数字分别对应「存储」和「逻辑长度」。把u8"汉"传给一个吃std::string的函数，在 C++17 下静默通过，在 C++20 下直接编译失败——这不是标准在找麻烦，而是把原本被隐式转换掩盖的编码假设暴露出来。血泪经验是：凡是在源码里写非 ASCII 字面量的地方，都要确认源文件编码与执行字符集是一条线，否则你调strlen得到的结果会随构建机器变化。

2.2 阶段顺序不能交换：宏展开为什么必须早于语法分析

标准把翻译过程编号，关键节点大致是：字符映射、行拼接（反斜杠后紧跟换行，注意中间夹空格就不算拼接）、把字符流分解成预处理 token 和空白序列、执行预处理指令与宏替换、字面量内的字符集映射、相邻字符串字面量拼接、真正的语法语义分析与模板实例化、链接。

这个顺序里有一处设计上不能动的硬约束：预处理必须早于语法分析。原因很直接——宏可以引入不平衡的括号和半个声明。#define BEGIN {这种写法在真实代码里存在过，如果先做语法分析，分析器面对一个孤立的{根本无法工作。所以标准选择「先做一遍纯 token 级的文本替换，再做解析」，代价是宏系统与语言自身的名字查找完全绝缘。

#define STR(x) #x #define XSTR(x) STR(x) #define VERSION 2020 // 单层 STR 不会展开 VERSION：因为 # 对参数做字符串化，且抑制参数展开 const char* a = STR(VERSION); // "VERSION" // 多一层间接才会展开：XSTR 的参数先被展开，再交给 STR 字符串化 const char* b = XSTR(VERSION); // "2020"

a和b的区别是「宏是 token 序列替换、不是文本替换」最直接的证据：#运算符作用于一个 token，被字符串化时不触发宏展开；想拿到展开后的值，必须绕一层。同一节里__LINE__的取值也依赖阶段顺序——它在行拼接之后才被确定，所以一个跨两行的宏调用，__LINE__报的是逻辑行号而不是物理行号。

2.3 最长匹配：a+++b、1e+5与头文件名

词法阶段有一条贯穿全局的规则：从当前位置出发，取「能构成一个预处理 token 的最长字符序列」。这条最长匹配规则解释了大量看起来像玄学的现象。

int a = 1, b = 2; int c = a+++b; // 最长匹配成 a++ + b，结果是 3，不是 a + (++b) // 预处理数字（pp-number）也是贪心的： // 1e+5 是一个完整的 pp-number token；1e + 5 才是三个 token #define E 2 double d = 1E+5; // 仍然是 1e+5，E 不会被展开成 2

最后一行是经典翻车现场：不少人以为#define E 2会把1E+5变成12+5，实际不会——1E+5在进入宏替换之前就已经是一个不可分割的 pp-number token 了，宏替换只在 token 边界上操作。同理，0x1p-3是十六进制浮点字面量，不是0x1减去3。

最长匹配还有两个著名的补丁。一是模板关闭：C++11 之前vector<vector<int>>必须写成> >，因为>>是单个 token；C++11 起专门给模板参数列表开了口子，允许>>当作两个>处理。二是<::的歧义：<:本身是[的替代拼写，于是vector<::std::string>里的<::会被吞成一个替代 token；标准为此加了特例——若<::后面既不是:也不是>，则开头的<单独成 token。这类补丁的本质，都是最长匹配规则与语法上下文打架之后的例外清单。

3. ODR、linkage 与 modules：头文件模型为什么必须被替换

C++ 用了几十年「文本包含」的复用方式，#include把被包含文件的 token 原样倒进当前翻译单元。这套模型的所有毛病——编译慢、宏污染、包含顺序敏感——根子上都指向同一条规则：单一定义规则（ODR）。

3.1 单一定义规则：同一份 inline 函数定义不同，链接器为什么不报错

单一定义规则允许某些实体在多个翻译单元里都有定义：类类型、inline函数、模板、枚举。但有一个前提条件——这些定义必须逐 token 相同，且名字查找的结果也必须相同。违反这条规则是未定义行为，且标准明确规定「不要求诊断」（no diagnostic required）。这就解释了那个最让人抓狂的现象：两个翻译单元里同名inline函数的实现不一致，代码能链接成功，运行时行为随机。

原因在链接模型上：inline函数和模板实例化产生的符号是弱符号，链接器看到多份定义时不会报冲突，而是随便挑一份留下。哪一份被挑中，取决于链接顺序、目标文件顺序，甚至增量构建的缓存状态。你看到的行为不一致，其实是「链接器替你做了选择」，而不是你的代码逻辑有问题。

比函数更危险的是类布局不一致：

// widget.h —— 如果两个翻译单元看到的是不同版本的这份头文件 struct Widget { int id; #ifdef EXTRA int tag; // 一个翻译单元有，另一个没有 #endif };

sizeof(Widget)在两个翻译单元里不同，new和delete、成员偏移、按值传参的拷贝大小，全部按各自的理解计算。结果就是堆踩踏，而链接器全程无感，因为符号只有一个，冲突在类型层面而不在符号层面。踩过这个坑的人一般会养成一个习惯：改了公共头文件里的类定义之后，全量重新构建，不信任增量编译。

3.2 linkage 三档：internal、external 与 module

标准把名字的链接性分成几档，它决定了一个名字在链接期是否有符号、符号是否跨目标文件可见。普通函数和全局变量是外部链接，全程序一个实体；加了static或在匿名命名空间里的名字是内部链接，每个翻译单元各一份；C++20 为模块新增了模块链接（module linkage），模块内未被导出的名字在模块外不可见。

// 头文件里的三种"全局"写法，语义完全不同 inline int g_inline = 0; // C++17 起可用：外部链接，全程序同一个实体 static int g_static = 0; // 内部链接：每个翻译单元各一份副本 namespace { int g_anon = 0; } // 同样内部链接，但不会与外部同名符号冲突 // 后果：&g_inline 在所有翻译单元里相同；&g_static 在不同翻译单元里不同

static版本能规避 ODR 冲突，代价是代码膨胀和「地址不唯一」——如果你把&g_static传出去做比较或者注册回调，行为会非常反直觉。内部链接的名字还影响模板非类型参数：不同翻译单元里&g_static是不同的值，所以它不能用作需要跨翻译单元一致的模板实参。

3.3 module purview 与 reachability：import为什么不搬运 token

C++20 第 10 章引入的模块，最本质的改动不是语法糖，而是把「复用」从文本层挪到了语义层。一个模块接口单元由模块声明切分成两段：声明之前是全局模块片段（global module fragment），只能放传统的#include；声明之后进入模块范围（purview），这里定义的名字默认只在本模块可见，只有标了export的才对外。

// math.cppm —— 模块接口单元 module; // 进入全局模块片段 #include <cstdint> // 传统头文件必须放在这里，内容不属于模块 purview export module math; // 模块声明，之后进入 purview export int add(int a, int b) { return a + b; } int helper() { return 42; } // 未 export：模块链接，模块外不可见 // main.cpp import math; // 只看到 export 的名字 int main() { return add(1, 2); } // helper() 在这里不可见

真正的收益有三条。第一，宏不再传播：import不复制 token，所以被导入模块里的#define不会污染导入方，这一条单独就能省掉大量#undef的补丁。第二，编译时间：模块接口只被编译器解析一次，产出的二进制模块接口（BMI）可以直接复用，而#include的每个翻译单元都要从头解析一遍头文件及其全部依赖。第三，也是最少被提到的一点——可达性（reachability）：标准规定只有「可及」的声明参与名字查找和重载决议，而不是像包含那样「文本出现过就算数」。这让「为什么这个重载在我的翻译单元里能看到」有了明确的判定依据，不再依赖包含顺序。

代价同样明确：模块需要构建系统配合，编译器要管理 BMI 的生成与失效；混用#include和import的过渡期，全局模块片段里的内容仍然是老规矩。很多项目在 C++20 落地时卡住，不是因为语言特性不会用，而是构建链没有把模块单元当成一等公民。

4. 约束与重载：concepts 凭什么让模板报错变短

模板的错误信息长，常被归咎于编译器不友好。但真正的根源是语言机制：替换失败不算错（SFINAE）这条规则，让编译器必须尝试每一个候选，然后把每一个失败原因都记下来。

4.1 SFINAE 的边界在 immediate context

规则原文的意思是：在模板实参替换期间，如果某个类型或表达式无效，且这个失败发生在「直接上下文」里，那么这个候选被静默从重载集中移除，不产生错误。超出这个范围就是硬错误。

#include <type_traits> // 失败点在返回类型（immediate context 内）：对没有 size() 的类型， // 这个重载直接被丢弃，不报错 template <class T> auto size_of(const T& c) -> decltype(c.size()) { return c.size(); } // 失败点在函数体：一旦这个候选被选中，函数体里的错误就是硬错误 template <class T> auto size_of_bad(const T& c) { return c.size(); }

把表达式挪到返回类型里，等于把「检查」提前到了替换阶段；挪到函数体里，检查就发生在实例化阶段，而实例化不在 SFINAE 的保护范围内。这就是为什么大量老代码依赖decltype或std::enable_if写返回类型——它们不是风格选择，而是把失败点强行搬进直接上下文的唯一手段。

代价是可诊断性。一个函数有二十个候选，编译器要把二十次替换的结果全部保留，最后一次性打印；错误信息里绝大多数字段描述的是「其他候选为什么不行」，而不是「你错在哪」。C++20 的 concepts 没有改变 SFINAE 的语义，但改变了候选的过滤时机：约束不满足的候选在重载决议之前就被剔除，不再逐条打印失败原因。

4.2 约束归一化与 subsumption：requires的偏序怎么算

当两个模板都符合条件时，标准不是靠「谁更特化」这种模糊直觉来选，而是靠约束的偏序关系（subsumption）。过程是：把requires子句归一化成原子约束的合取与析取范式，然后判断一个约束是否「包含」另一个。

#include <concepts> template <class T> concept Small = sizeof(T) <= 8; template <class T> concept SignedSmall = Small<T> && std::signed_integral<T>; // SignedSmall 的原子约束集真包含 Small 的，所以上面这个更受约束，优先选中 template <SignedSmall T> void pick(T) {} template <Small T> void pick(T) {} // pick(1); // 选第一个 // pick(1u); // 只有 Small 满足，选第二个

这里有个容易翻车的细节：偏序判断基于原子约束的「表达式是否相同」，而不是语义是否等价。所以两个写法不同但含义相同的requires子句不会互相排斥，反而会导致重载歧义。concept-id 在归一化时会被替换成它的定义体（同一个 concept 只展开一次，避免无限递归），所以concept A = Small<T>;与直接用Small<T>在偏序上是同一个原子约束。这也解释了为什么给已有 concept 起别名不会增加「更受约束」的程度。

还有一个必须记住的边界：requires表达式内部发生的失败是被当作「不满足」处理的，但那指的是原子约束求值时的替换失败；如果你在 requires 表达式里写了真正意义上的硬错误（比如访问不存在的成员且不在直接上下文里），编译依然会失败。这条边界经常被「约束里什么都能写」的说法误导。

4.3 重载解析的三级台阶

重载决议的比较对象是「隐式转换序列」，而隐式转换序列有一个明确的排序阶梯：精确匹配优于提升（promotion），提升优于转换（conversion）。

void f(int); void f(long); void f(double); f(0); // int：精确匹配 f(0L); // long：精确匹配 f(0.0f); // double：float -> double 是浮点提升，优于 float -> int 的转换

第三行最容易被误判：f(0.0f)明明有int和long两个整数候选，为什么选double？因为浮点提升（float到double）的等级高于浮点转整数（属于转换）。完整的决议流程要更细：先按实参的初始化序列筛选，再比较标准转换序列，最后才在用户定义转换之间比较第二标准转换序列。{}初始化列表还有额外优先级，这就是为什么给类加一个initializer_list构造函数会悄悄改变所有花括号调用的语义——它是重载集合里优先级最高的一档，很多「加了构造函数之后老调用行为变了」的 bug 都出在这里。

5. 排查现场：五个「标准说可以、编译器说不」的翻车记录

标准文本和实现行为之间的落差，基本上都在这一节里现形。下面五条都是现象、原因、解决三段式，能对上号就直接抄。

5.1 placement new 之后读出来还是旧值

现象：在固定缓冲区上用 placement new 构造一个新对象，通过旧指针访问，读到的仍是旧值，开启优化后甚至整段被优化掉。

原因：对象生命周期是标准里的硬概念。旧指针指向的是已经结束生命周期的对象，用它访问是未定义行为；编译器有权假设「这块存储上的对象没变」。即使新对象恰好放在同一地址，指针也必须经过std::launder才能合法地指向新对象——尤其是类型带const成员或引用成员时，重用了存储不等于指针自动「刷新」。

解决：能拿到 placement new 的返回值就用返回值；只能拿到旧指针时，统一包一层std::launder。同时确认新旧类型满足透明可替换的条件，否则launder也救不了。

5.2 加了移动构造，vector扩容还是拷贝

现象：类里明明写了移动构造函数，std::vector扩容时日志显示调用的却是拷贝构造，性能没有改善。

原因：vector扩容要保证强异常安全——扩容失败时原容器必须不变。标准的规定导致实现会在「移动构造可能抛异常」时退回到拷贝构造，因为拷贝失败可以丢弃新缓冲区，而移动失败会留下半移动的原元素。判断依据就是移动构造有没有标noexcept。

解决：给移动构造和移动赋值加noexcept（前提是它们确实不抛），并在移动后把源对象置为合法可析构状态。顺带检查成员里有没有std::string之外的、移动会抛的东西。

5.3 两个翻译单元里同一函数行为不同

现象：同一个inline函数，在 A 处调用和 B 处调用结果不一样；改了实现之后只有部分调用点生效。

原因：单一定义规则被违反，且不要求诊断。常见触发是头文件里的条件编译差异、不同模块的包含路径指向了两份同名头文件、或者增量构建留下了过期的目标文件。

解决：把所有inline函数的定义收敛到一个头文件里，禁止在头文件里写依赖宏的分支；CI 里加一步全量重建作为基线；开启链接器的重复符号检查和编译器的 ODR 检查选项。

5.4constexpr函数编译期算对，运行期出 UB

现象：同一个函数在static_assert里求值正确，运行期传入稍大的参数就崩溃或者结果荒谬。

原因：常量求值是一条严格受限的路径，标准明确禁止常量表达式里出现未定义行为，所以编译期会把有符号溢出、越界访问、空指针解引用全部拦下来。运行期没有这层保护，同样的输入直接踩进 UB，编译器的优化还会让表现进一步失真。

解决：把关键计算用consteval或强制常量求值固化下来，让不合法的输入在编译期就炸；运行期路径配上有符号溢出检查和地址检查工具，别指望「编译期没问题」等于「运行期没问题」。

5.5 迭代器与引用的失效规则被忽略

现象：遍历vector时对元素取引用，循环体里顺手push_back，结果引用指向已释放内存；unordered_map插入后旧迭代器失效导致崩溃。

原因：标准对每种容器都明确写出了插入、删除操作会让哪些迭代器、指针、引用失效。vector扩容会整体搬迁，全部失效；unordered_map的 rehash 会让迭代器失效但引用和指针保持有效；deque中间插入让全部迭代器失效。这些规则不是实现细节，是标准承诺。

解决：循环里避免结构性修改，需要就先reserve；无法预估规模时用索引而不是迭代器；对「引用必须稳定」的场景选节点型容器。把失效规则当成接口契约的一部分来读，比事后调试省事得多。

6. 设计取舍：把自由度留给实现，把复杂度写进标准

读完这份标准，最值得带走的一个判断是：它在「规定什么」和「不规定什么」之间划了一条非常刻意的线。这条线的位置，决定了 C++ 今天的性能与生态。

对内存布局放权，换来的是编译器可以按目标平台对齐、填充、重排，也换来了不同编译器之间对象不兼容这个长期代价；对复杂度收紧，是因为复杂度是算法契约的一部分，不写进标准，用户就无法依赖push_back的摊销常数来设计代码。所以标准在容器复杂度上的规定异常具体，而在「虚函数怎么调用」上几乎一片空白——前者影响可移植的算法选择，后者只影响二进制接口，而二进制接口从来不在标准的管辖范围内。

未定义行为是这条线最激进的一端。标准不定义它，等于授权编译器假设它永远不会发生：空指针检查可以被删掉，有符号溢出可以按不溢出推导，越界访问可以被判定为不可达。这不是编译器「不听话」，而是契约本身就这么写的。理解这一点之后，看那些「加了-O2就崩、-O0就好」的 bug，判断路径会清楚很多——它们几乎都不是优化器的错，而是代码先违反了契约。

我的习惯是：凡是要跨翻译单元、跨编译器、跨版本传递的东西，先把「这是标准保证的，还是实现碰巧这么做的」问一遍。标准保证的部分写进接口契约，实现相关的部分要么封装隔离，要么在构建时显式检查。手边这份第六版文档的价值就在这儿——它不是用来从头读到尾的，而是当你要判断某段代码到底站在契约的哪一侧时，能翻到对应章节，找到那句写死的规则。从那以后我每次动公共头文件和inline定义，都会强制把 ODR 和链接性过一遍再提交，省下来的调试时间远比翻书多。希望帮到你。

本文还有配套的精品资源，点击获取