企业官网建设流程全解析

从“编译不过”聊起：为什么我会单独为const写一篇深度解读

如果你写过一段时间的C++，一定见过这类报错：error: passing 'const Foo' as 'this' argument discards qualifiers，或者no matching function for call to '...'，再或者模板实例化时冒出一长串跟const相关的晦涩信息。说白了，就是const没写对、没写全、或者写错了位置。我刚入行那几年，遇到这类错误基本靠猜，改一处试一次，浪费时间不说，还经常把一个地方改好了、另一个地方又炸了。

后来在某个跨平台系统项目和某图像处理Demo的开发中，我被const折磨的次数多了，才下决心把它彻底搞清楚。const这东西在C++里属于“基础中的基础”，但恰恰因为太基础，绝大多数人只是“会用”，远没到“懂”的程度。const的规则并不复杂，但它涉及修饰变量、指针、引用、函数参数、返回值、成员函数等多个维度，每个维度都有自己的一套语义，组合起来就容易乱。

这篇博客不打算按教科书的方式从头到尾讲一遍，而是以我在实际项目里踩过坑、排查过报错、重构过接口的真实经验为主线，把const的完整知识图谱理清楚。无论你是刚接触C++的新手，还是写过几年但一直没系统梳理过const的老手，这篇文章都能让你在下次遇到const相关报错时，不再靠猜，而是直接定位问题。

1. 先搞清楚const存在的意义：它到底在保护谁

1.1 常量的本质：不只是“不能改”这么简单

大多数人对const的第一印象是“这个变量不能被修改”。这句话本身没错，但它只描述了现象，没有解释本质。const真正做的事情，是在编译期给变量加上一道约束，让所有试图修改它的代码都无法通过编译。

这意味着什么？意味着const的约束力是编译期的，不是运行期的。它没有在内存里做任何特殊处理，没有加锁，没有写保护，纯粹靠编译器来把关。你用const修饰一个变量，本质上是在告诉编译器：“这个变量在我的设计里不应该被改变，如果你发现哪里尝试改变它，请直接报错。”

这一点很关键，因为它引出了一个重要推论：const的安全性只存在于源代码层面。如果有人通过const_cast强行去掉const，或者在内存层面直接篡改，编译器拦不住，运行期也不会崩溃。就像一道门上的锁，防的是君子，不是强盗。

另外，const还承担着“表达设计意图”的责任。我见过不少代码，所有变量、所有参数都不加const，功能确实能跑通，但读代码的人根本分不清哪些值是会被修改的、哪些是不会被修改的。加上const之后，接口的语义边界立刻清晰了——调用者看一眼函数签名，就能知道这个参数是“只读输入”还是“可修改的输入输出”。这对团队协作、代码审查、后期维护都是巨大的帮助。

1.2 const与宏定义的区别：不要混为一谈

很多老C语言程序员习惯用#define MAX_SIZE 100来定义常量，然后在C++里也沿用这个习惯。const并不是宏定义的替代品，两者有本质差别。

宏定义发生在预处理阶段，是纯文本替换。#define MAX_SIZE 100意味着代码里所有MAX_SIZE都会被替换成字面量100，它没有类型，没有作用域，不遵守C++的类型检查规则。而const变量是一个真正的变量，有明确的类型，遵守作用域规则，参与重载决议，并且可以被取地址、传引用。

举个例子，const int maxSize = 100;你可以写const int* p = &maxSize;取其地址，但#define MAX_SIZE 100你就没法对宏取地址。另一个实际场景是，如果你在头文件里定义一个宏，它会污染所有包含这个头文件的源文件；但const变量遵循内部链接规则（在命名空间作用域下），不会产生这种污染。

那constexpr呢？它和const又有不同。constexpr强调的是“编译期求值”，它修饰的变量必须能在编译期计算出结果。const强调的是“运行期不可修改”，它的值可以是运行期才确定的，比如const int n = getUserInput();这在C++里是合法的，但如果是constexpr int n = getUserInput();就编译不过。简单理解：constexpr是比const更严格的约束，它天然具备const的特性，但反过来不一定成立。

2. const修饰变量：从基础规则到内存视角

2.1 const变量初始化：必须初始化，这是一条铁律

const修饰的变量必须在声明时就初始化，这个规则没得商量。const int a;直接编译报错，因为编译器不允许一个“永远不能被赋值但初始值也没定义”的变量存在。

这里有一个容易踩的坑：初始化不等于赋值。const int a = 5;这是初始化，没问题。但如果你先声明int a;然后const int a = 5;或者对已经初始化的const变量再赋值，都是编译错误。赋值发生在变量生命周期中的某个时间点，但const变量的修改窗口在初始化那一刻就已经关闭了。

还有一种特殊情况：类的const成员变量。它必须在构造函数初始化列表里完成初始化，不能在构造函数体里赋值。原因是构造函数体执行的时候，对象已经被认为构造完成了，而const成员变量在进入构造函数体之前就需要有确定的值。

2.2 顶层const与底层const：两个最容易混淆的概念

谈到const修饰变量，必须区分顶层const和底层const。这两个概念在C++ Primer里有详细讲解，但很多人看完就忘了，因为概念本身有点抽象。

顶层const指的是const修饰的是指针本身，也就是这个指针变量的值（即它存的地址）不能修改。底层const指的是const修饰的是指针指向的对象，也就是通过这个指针不能修改它指向的内容。

用一个具体的例子说明：

int a = 10; int b = 20; int* const p1 = &a; // 顶层const：p1本身不能修改，即不能指向别的对象 // p1 = &b; // 错误，p1是顶层const const int* p2 = &a; // 底层const：不能通过p2修改a的值 // *p2 = 30; // 错误，p2指向的是const int p2 = &b; // 合法，p2本身可以重新赋值 const int* const p3 = &a; // 既顶层又底层：p3不能改，*p3也不能改

判断方法很简单：看const和*的相对位置。const在*的右边，就是顶层const，修饰指针本身；const在*的左边（包括const int*和int const*两种写法），就是底层const，修饰指针指向的对象。

这个区分为什么重要？因为它直接影响赋值和函数参数类型匹配。顶层const会被忽略，比如int* const作为函数参数时，和int*表示的是同一个类型；但底层const是不能被忽略的，const int*和int*是两种完全不同的类型，涉及底层const的赋值规则非常严格：不允许把const int*赋值给int*，但允许反过来把int*赋值给const int*。这个“只允许增加const，不允许去掉const”的原则是C++类型系统的重要基石。

2.3 const变量的内存表现：不是你想的那种“只读区”

很多人以为const变量会被放到只读存储区，比如ROM或者专门的只读数据段。这个理解对全局const变量部分成立，但实际上没那么简单。

对于内置类型的const变量，如果初始值是编译期常量，编译器通常会把它当作常量处理，可能直接在编译期就替换掉所有使用它的地方，根本不分配内存，或者分配在只读数据段。这取决于优化选项和变量的实际使用方式。

对于非内置类型的const对象（比如const修饰的类对象），情况就复杂了。编译器通常会为它分配内存，因为它有析构函数需要调用，对象生命周期需要管理。这块内存是否真的只读？不一定。如果你用const_cast去掉const再修改它，在大多数平台上“可能”能改成功，但这是未定义行为，编译器完全可以假设这个对象不会变，然后基于这个假设做各种优化，最终导致诡异的行为。

我在实际开发中就遇到过这样一个案例：某跨平台系统里定义了一个全局const结构体，里面存着一组配置项。后来有人在某个模块里用const_cast修改了它，结果在某些编译优化级别下，其他模块读到的配置项时而正常、时而异常，排查了整整两天。最后定位到是const_cast修改全局const对象导致的未定义行为。教训就是：别用const_cast修改真正const的对象，尤其是编译期初始化的全局对象。编译器会按照“这个对象不会变”的前提做优化，你强行改，后果全看编译器心情。

3. const与指针、引用：组合规则里藏着的大量编译错误

3.1 const与指针的完整组合：一口气把规则理清

指针和const组合起来，一共有三种基本形态，外加一种双重const的形态。我把它们列成一张表，方便对照：

注意const int*和int const*是等价的，两种写法都能见到。我个人更推荐int const*这种写法，因为从右往左读非常顺畅：先读p，遇到*说“p是个指针”，遇到const说“指向的对象是const”，遇到int说“对象类型是int”。而const int*按从右往左读会变成“p是指针，指向的是int，然后const呢？const哪去了？”反而是int const*在逻辑上更顺畅。不过这只是个人偏好，两种都合法，最重要的是团队里统一写法。

还有一个常见误区：const int* p指向的必须是const int吗？不需要。它完全可以指向一个普通的int变量，只是你不能通过p去修改它。这个“不能通过这条路径修改”的语义，跟被指向对象本身是不是const完全独立。

3.2 const与引用：引用本身就是不能改的，那const还修饰什么

引用在C++里一旦绑定到某个对象，就不能再重新绑定到另一个对象。从这个角度看，引用天然自带“顶层const”的属性。所以const int&里的const修饰的是被引用对象，效果是：不能通过这个引用修改被引用的对象。

这里有一个非常重要的知识点：const引用可以绑定到临时对象和字面量，非const引用不行。比如：

const int& ref = 10; // 合法，临时量延长生命周期 int& ref2 = 10; // 错误，非常量引用不能绑定字面量 const double& ref3 = 42; // 合法，发生隐式转换，临时量绑定

这个规则在函数参数传递中有巨大的实用价值。函数参数写成const T&，你既可以传左值，也可以传右值、传字面量、传临时对象；但如果写成T&，调用时传一个临时量或字面量就直接编译报错。我有一次给某图像处理Demo设计接口时，把一个参数从std::string&改成了const std::string&，原本一些连接临时字符串的调用点立刻就能编译通过了，非常直观地感受到了这个规则的价值。

另外要说一个和生命周期相关的细节：const引用可以延长临时对象的生命周期，这个延长会一直持续到该引用变量离开作用域。这个机制是C++里为数不多的“引用存续期干预”手段，知道的人很多，但真正理解的人不多。它的实现原理大概是这样：当一个临时对象被绑定到const引用时，编译器会保证这个临时对象不会被立即销毁，而是存活到引用变量析构为止。

3.3 函数参数里的const：值传递和引用参数要区别对待

函数参数是const应用最频繁的场景，但很多人对“什么时候该加const”没有清晰的判断标准。

对于值传递的参数（int a、std::string s这类，按值传参），函数内部加不加const不影响调用者，因为传进来的是副本。值传递时在参数类型前加const，比如void foo(const int a)，表示这个参数在函数体内不能被修改，但它不影响调用方的任何行为。这个const可加可不加，主要是给自己看的，防止函数体内部不小心改了参数值。

真正重要的是引用参数：void foo(const std::string& s)。这里的const价值在于：（1）告诉调用者，这个函数不会修改传入的对象，语义上更安全；（2）允许传入临时量和字面量，提升接口的适用性；（3）避免拷贝开销，对于大对象性能影响显著。

那什么时候应该用const T&，什么时候用T&？我的判断标准很简单：如果函数只需要读取参数对象的内容，不希望也不能修改它，就用const T&；如果函数确实需要修改传入的对象，就用T&；如果函数不仅要修改，还希望调用者能意识到这个修改会影响传入对象，就不能加const。还有一个容易忽视的点：如果参数是右值引用（T&&），它本身就可以绑定临时对象，但右值引用和非const左值引用之间是另一套规则，跟const没有直接冲突。

4. const与函数：重载、返回值、和默认参数的纠缠

4.1 参数为const引用的函数可以参与重载吗

在C++里，函数重载要求参数的类型不同。void foo(int)和void foo(const int)不能构成重载，因为顶层const会被忽略，这两个函数的参数类型被认为是相同的。同理，void foo(int*)和void foo(int* const)也不能构成重载。

但void foo(int&)和void foo(const int&)可以构成重载，因为这里const修饰的是引用指向的对象，属于底层const，底层const参与类型识别，因此这两个是不同的重载版本。

这个性质有什么实际用途？它可以做“读版”和“写版”接口分离。一个经典例子：

class Data { public: int& at(size_t index) { return data[index]; } // 非const版本 const int& at(size_t index) const { return data[index]; } // const版本 private: std::vector<int> data; };

调用方如果持有对象的是const引用或const指针，就只能调用const版本，拿到const引用不能修改；如果是非const对象，调用非const版本，拿到可修改的引用。这套机制保证了“const对象不允许改，非const对象可以改”的语义能够在编译期被强制执行。

4.2 返回值加const：什么时候有用，什么时候是多余的

返回值加const的情况需要分场景讨论。对于返回的值类型，比如const int foo()，这种几乎是没意义的。调用者拿到的是一个右值，它本身就不能被赋值（int a = foo(); a = 10;这个是a的赋值，跟返回值没关系），在大多数编译器中，顶层const甚至会被忽略。

对于返回引用的情况，const就有意义了。const T& foo()表示返回的是一个const引用，调用者不能通过这个引用来修改底层的对象。这经常用于getter方法，返回内部成员但不希望外部修改它。与之对应，T& foo()返回非const引用，外部可以修改内部数据。

这里有一个隐藏的坑：如果你返回的是const T&，但函数内部返回的是一个局部变量，那就是悬挂引用，局部变量函数返回时已经销毁，这个引用指向的是已销毁的对象。这个错误即使用了const修饰也无法避免，一定要记住：永远不要在函数里返回局部对象的引用，无论是const还是非const。

4.3 默认参数与const：一个容易忽视的规则

默认参数值必须是编译期常量，这一点跟constexpr有关。你写void foo(int a = 10)，10是字面量，没问题。但如果你写：

const int defaultVal = getConfig(); void foo(int a = defaultVal); // 错误，defaultVal不是编译期常量

就编译不过。但如果constexpr int defaultVal = 10;就没问题。我在某跨平台系统里遇到过类似问题，配置文件里定义的默认值想作为函数默认参数用，结果编译报错，当时没反应过来，查了好一会儿才想到是编译期常量的限制。

5. const与类成员函数：浅拷贝、const对象、和mutable的配合

5.1 const成员函数的核心规则：this指针的类型

类的成员函数默认有一个隐式的this指针。非const成员函数的this类型是ClassType*，而const成员函数的this类型是ClassType const*。也就是说，const成员函数里，用this访问成员时，所有成员都被视为const的，不能修改。

这个差异带来的结果是：const成员函数不能修改非static成员变量，不能调用非const成员函数。因为修改非static成员变量相当于通过const this指针去写数据，编译器不允许；调用非const成员函数相当于把const this指针传给一个需要thisType*的函数，类型不匹配。

所以const成员函数的设计目标很明确——它承诺：调用这个函数不会修改对象的可见状态。这对接口设计意义重大：const对象只能调用const成员函数，非const对象既可以调用const版本也可以调用非const版本（如果有重载的话）。

5.2 mutable：const世界里的“后门”

有时候你确实需要在一个const成员函数里修改某个成员变量，但这不违反对象对外表现出的“不可变性”。典型的场景是缓存、日志统计、锁状态等。mutable关键字就是为这个场景准备的：用mutable修饰的成员变量，即使在const成员函数里也可以修改。

我记得在某跨平台系统中有个类，内部存了一张缓存表，懒加载填充。getter方法被设计成const，因为调用者视角里这个操作不该改变对象的核心数据，但实现却需要更新缓存。用mutable修饰缓存成员，问题就完美解决了。

这里要提醒一句：mutable是工具，但也可能成为滥用接口的突破口。在设计类时，尽量把mutable成员控制在“不影响对象逻辑状态”的范围内。如果一个mutable成员被修改后，外部能够观察到对象行为的变化（不是性能差异，而是逻辑差异），那你用它就是设计上出问题了。

5.3 const成员函数与拷贝构造：浅拷贝的陷阱

类的拷贝构造、拷贝赋值函数如果要处理const对象，需要区分几个场景。拷贝构造函数通常写成Foo(const Foo& other)，这个const表示“从other对象拷贝数据到当前对象，但不会修改other”。这没问题，实现的时候用other的成员去初始化当前对象的成员。

但赋值运算符通常会提供两个版本：

Foo& operator=(const Foo& other); // 从const对象赋值 Foo& operator=(Foo&& other); // 移动赋值，从非const右值

如果类内部有裸指针成员，默认的浅拷贝方式在赋值时会发生“双指针指向同一块内存”的危险，析构时会double delete。const在这里并不会直接导致这个问题，但它会影响你写深拷贝时的参数类型：如果你写Foo& operator=(Foo& other)而不是const Foo&，调用方传一个const对象过来就编译不过，接口的适用性大打折扣。所以参数写成const引用是惯例，不光是风格问题，还是接口吞吐能力问题。

5.4 static成员函数不能用const修饰

static成员函数没有this指针，它不属于某个具体对象。因此不能用const修饰——const修饰成员函数本质上是给this指针加const限定，static成员函数连this都没有，加const毫无意义，编译器直接报错。这个规则和“const成员函数不能修改static成员”是一致的逻辑：static成员属于类而非某个对象实例，不需要也不能通过this来访问。

6. const在实战里的应用技巧：重构、排查、避坑

6.1 从“编译器报错”到“秒定位”的排查思路

遇到const相关编译报错时，先别急着改代码，按照以下顺序排查：

1. 看报错信息里是不是出现了discards qualifiers，如果是，说明你在某个const对象上调用了非const成员函数。检查这个对象是不是应该是const的——如果是，说明调用方传进来是const，你要么把函数改成const成员函数，要么修改调用方式。
2. 看报错是否和类型不匹配有关，比如传了const T*给T*参数。这种情况通常发生在函数接收const指针但内部需要修改数据的场景。检查函数到底是应该接收const还是非const。
3. 检查是不是顶层const和底层const混淆了。比如声明了int* const p但后续给p重新赋值（错误），或者声明了const int* p但尝试通过p修改指向内容（错误）。
4. 检查const成员函数内部是否修改了非mutable成员。C++标准允许const成员函数修改mutable成员，但绝对不能修改普通成员。
5. 如果报错是“表达式必须是可修改的左值”，检查你是不是对一个const变量进行了赋值操作。
6. 如果报错和初始化相关，检查const变量是否没初始化，或者const成员变量是否在初始化列表里漏了。

在实际项目中，有相当大比例的const报错来自“调用了一个未加const的接口，但传入的对象是const类型”，这个时候思考的重点应该是“这个接口本身的签名是否有问题”，而不是盲目地在调用处加const_cast。

6.2 接口设计里的const规范：团队协作的约定

在一个多人协作的代码库中，const的使用如果没有统一约定，很快就会乱套。我这里分享几条我在团队里推行的规范，都是踩过坑总结出来的：

• 所有只读接口（getter、查询类接口）的成员函数默认加const。String类的length()不加const，那是反模式。
• 所有不需要修改参数的函数参数，优先考虑const T&而不是T。这既是性能优化，也是接口语义说明。只有需要对副本进行修改时才用按值传参。
• 返回内部成员引用时，默认返回const T&，除非调用方确实需要修改。这样做能避免很多意外修改带来的bug。
• 输入参数如果是指针，用const T*，输出参数用T*。不要用同一个指针既当输入又当输出，这种风格容易引发误用。
• 类的成员函数里，能加mutable解决的问题优先加mutable，不要用const_cast绕开const语义。const_cast应该留给极少数特殊场景（比如和旧C库交互、序列化框架等）。

6.3 const_cast的正确打开方式（以及什么时候绝对不能碰）

const_cast的用途只有一个：在我们明确知道某个对象实际上不是const的情况下，去掉const限定。比如：

void legacyApi(char* buffer); void wrapper(const char* readOnlyBuffer, size_t len) { // 我们知道readOnlyBuffer实际指向的内存是可以修改的 // 比如它来自一个内部可写缓冲区，只是这里以const形式传入 legacyApi(const_cast<char*>(readOnlyBuffer)); }

这种使用是合理的——旧C接口需要char*，但业务层传入的是const接口，而我们知道底层内存其实可写。

但下面这些场景绝对不能碰const_cast：

• 修改真正定义成const的对象（包括全局const对象、const成员变量、const局部变量）。这是未定义行为，编译器可能把这些对象放到只读内存，也可能做常量替换优化。
• 给const_cast的结果赋值一个原本不是const的对象。const_cast不能把一个本身是const的对象变成非const来修改，这是一个极其危险的误用。
• 用于函数重载选择。const_cast不影响重载决议的结果，它只是类型转换，不会让一个const版本调用变成非const版本调用。

我在某跨平台系统里曾经review到一句代码：const_cast<Data*>(&getConfig())->update(42);——getConfig返回const引用，调用方用const_cast绕过限制去修改配置。当时立刻拦下来了，这种代码后期维护时几乎无法追踪，而且一旦编译器对配置对象做了常量优化，运行结果就变得不可预测。

6.4 性能视角：const与编译器优化

const对性能的影响主要在两方面：一是编译器优化，二是代码表达。

编译器优化方面，const告诉编译器“这个值不会变”，编译器可以把它当作常量使用，进行常量传播、简化、死代码消除等优化。但这只对真正的编译期常量有意义（constexpr更精确）。如果一个const变量的值在运行期才能确定，编译器同样无法在编译期做太多事情。

另外，const T&传参避免拷贝，这个优化效果非常直接。举个实际数据：在一个图像处理Demo里，某个函数把std::vector<Pixel>参数从按值传递改成const引用传递，处理1000张图的耗时从原来的约800ms下降到约150ms左右。原因很简单，按值传递每调用一次就要拷贝一次内存，1000张图的向量加起来拷贝开销非常可观。

但要注意，const本身不是银弹。加了const之后编译器并不一定会优化得更好，甚至在某些情况下（比如过度使用const引用传递小类型），反而引入了间接访问的开销。比如const int&传参，虽然避免了拷贝，但多了一层指针间接访问，对于int这种4字节的小类型，直接按值传往往更快。所以const引用不是所有场景都优于按值传，对于小类型（内置类型、指针、迭代器），按值传仍然是最佳实践。

6.5 一个容易忽视的坑：const对象调用非常量重载的意外选择

重载决议在选择版本时，会根据对象的const属性来选择。对于非const对象，如果同时存在const版本和非const版本，会优先选择非const版本。对于const对象，只能调用const版本。

但有一个隐蔽的情况：如果你只提供了非const版本，const对象调用它就会编译报错。反过来，如果你只提供了const版本，非const对象也可以调用它，因为非const对象可以绑定到const引用参数。所以“只提供const版本”比“只提供非const版本”在接口上更宽容，但代价是失去了修改能力。

在设计类的时候，如果你的对象既需要能修改、又需要能只读访问，建议两个版本都提供。如果你只需要只读访问，提供一个const版本就够了。如果你只需要可修改访问，但你预期这个接口未来要被const对象使用，最好从一开始就同时提供const版本，避免后期大规模回调。

6.6 const与模板、通用代码的特殊交互

在模板编程中，const有一个额外的复杂性：模板参数推导会保留const限定，但在某些情况下自动移除顶层const（比如按值传参推导时）。这意味着模板函数接收const T和T可能推导为不同的T。我之前在写一个通用算法时遇到过：模板参数推导时，传const int会推导出T = int（顶层const被忽略），但传const int*会推导出T = const int*（底层const被保留）。这个差异如果不留意，很容易写出不符合预期的代码。

另外，在类型萃取方面，可以用std::remove_const、std::add_const这些类型工具来操作const限定，这在模板元编程中很常用。如果你不知道这些工具，在模板里想去除const会非常痛苦。

对于auto和decltype，const的推导规则也很容易掉坑。auto会忽略顶层const和引用（除非显式加auto&或const auto&），而decltype会完整保留表达式的类型和const限定。比如：

const int a = 5; auto b = a; // b是int，顶层const被丢弃 decltype(a) c = 5; // c是const int，decltype保留了const

这个差异在编写通用代码时影响很大。如果你希望保留const限定，用decltype；如果你想要一个可修改的副本，用auto就对了。

6.7 常见问题速查表

我把平时遇到频率最高的const相关问题和解决方案整理成一个速查表：

这张表基本能覆盖日常开发中九成以上的const编译问题。还有一些更偏的规则，比如volatile和const组合、const与多态的交互，因为使用频率不高，暂时不展开。真到用的时候，查标准文档比记规则靠谱得多。

7. 写在最后：const是一个态度，不只是语法

我见过不少开发者把const当装饰品，能加不加，懒得写。但代码写多了你会发现，const其实是代码设计质量的一面镜子。一个接口把const标注清楚，等于直接告诉使用者：这个操作对对象状态的影响是什么样的。这种信息传递，比任何文档都准确。

我自己在项目里经历过一次“补const”重构：把某跨平台系统的核心数据类所有没加的const都补齐，期间修复了十几个因为const缺失导致的编译错误和逻辑隐患。重构完成之后，整个代码库的接口清晰度提升了一个量级，再也没出现过“不知道这个getter会不会改内部状态”的困惑。

最后分享一个判断习惯：拿到一个函数签名，先看它的const标注，两个信息天然就浮现了——这个函数会不会修改对象？这个参数是只读还是可写的？有了这两个信息，阅读代码的速度和理解代码的准确度都会大幅提升。如果你想让自己的C++水平从“能跑”走到“写得好”，从认真对待每个const开始。