1. 常量这件事为什么值得单独拎出来讲写C有些年头的人都有一个共同体会变量好理解常量反而容易写歪。原因不复杂——C给常量提供的写法实在太多了字面常量、const、constexpr、enum、#define五种方式摆在面前新手第一反应往往是能跑就行随手挑一个用。结果就是同一个项目里五种写法混着出现代码风格割裂更麻烦的是某些写法在特定场景下会埋下难以排查的坑。这篇笔记要解决的就是这个问题。我会把C里定义常量的五种主流方式逐一拆开讲清楚每种写法背后的机制、适用边界、编译期行为差异以及在实际工程里到底该选哪个。内容覆盖从最基础的字面常量到const、constexpr、enum、#define的完整对比适合刚接触C常量的初学者建立体系认知也适合有一定经验但没系统梳理过的开发者查漏补缺。需要先明确一个核心判断标准常量到底是在编译期确定还是在运行期确定。这一条几乎决定了所有选型决策。编译期常量能被编译器直接替换、能用于数组长度、能作为模板参数运行期常量则只是不可修改的变量本质还是变量。把这条线抓住后面五种写法的取舍就顺了。另外提前说一句#define虽然是C语言遗留的宏定义方式在C里依然能用但它的行为和其他四种完全不在一个层面上——它是预处理阶段的文本替换不参与编译器的类型检查。这个差异是很多诡异bug的源头后面会专门用一节讲。2. 字面常量最原始也最容易被忽视的一类2.1 字面常量到底是什么字面常量literal constant指的是直接写在代码里的固定值比如42、3.14、A、hello、true。它们不需要任何关键字修饰编译器看到就知道这是个常量。很多人觉得字面常量太简单不值得讲但实际上它的类型推导规则、后缀写法、进制表示都是容易出错的地方。举个最常见的例子int a 10; // 10 是 int 类型字面常量 double b 3.14; // 3.14 是 double 类型字面常量 float c 3.14f; // 加 f 后缀才是 float long d 100L; // 加 L 后缀才是 long如果你写float c 3.14;编译器会先把这个3.14当成double处理再隐式转换成float中间可能损失精度某些严格编译选项下还会报警告。这就是字面常量后缀的实际意义——显式告诉编译器这个值的类型避免隐式转换带来的精度问题和警告。2.2 进制与字符字面常量的细节字面常量支持多种进制写法这一点在底层开发、位运算场景里很常用写法进制示例十进制值无前缀十进制2552550前缀八进制03772550x前缀十六进制0xFF2550b前缀二进制C14起0b11111111255八进制这个坑要特别提一下。int x 010;看起来像十进制的10实际是八进制的8。我在实际项目里见过有人写端口号、权限位的时候忘了这回事排查半天才发现是进制问题。只要数字以0开头就是八进制这个规则从C语言继承下来C没有改。字符字面常量也有讲究。A是char类型值是65\n是转义字符\0是空字符值为0。字符串字面常量hello的类型其实是const char[6]末尾有个隐藏的\0不是const char*这一点在模板推导、sizeof计算时会有体现。sizeof(hello)的结果是6而不是5就是这个原因。2.3 字面常量的局限字面常量最大的问题是没有名字。同一个魔法数字如果在代码里出现十几次改起来就是灾难。比如某个缓冲区大小写死成1024散落在十几个文件里哪天要改成2048你得全局搜索替换还得小心别误伤其他恰好也是1024的地方。这就是为什么我们需要给常量起名字——也就是后面要讲的const、constexpr这些方式。提示字面常量适合用在只出现一次、语义极其明确的场景比如int arr[10]里的10。一旦某个值需要重复使用或语义不够直观就应该考虑具名常量。3. const 定义常量用得最多但误解也最多3.1 const 的本质是只读const是C里定义常量最常用的关键字但它的准确含义是只读read-only而不是严格意义上的编译期常量。这两个概念经常被混为一谈导致很多人在需要编译期常量的地方误用const。const int a 10; // 编译期就能确定可以当常量用 int b 20; const int c b; // 运行期才确定只是不可修改上面两个const int行为完全不同。a在编译期就已知编译器可以直接把它内联替换c依赖运行期的变量b它只是承诺后续不能改c但值本身是运行时算出来的。如果你拿c去定义数组长度比如int arr[c];在标准C里是非法的变长数组是C99特性不是标准C。3.2 const 修饰指针的三种位置const和指针结合是经典难点三种写法含义完全不同const int* p1; // 指向的内容不可改指针本身可改 int* const p2 x; // 指针本身不可改指向的内容可改 const int* const p3 x; // 两者都不可改记忆方法是从右往左读p1是指向const int的指针p2是const的指针指向intp3是const的指针指向const int。这个规则在面试和实际代码审查里出现频率极高写错了轻则编译报错重则逻辑出错。3.3 const 在函数参数和成员函数中的价值const用在函数参数上是接口设计的重要工具void printInfo(const std::string name); // 承诺不修改name传引用避免拷贝加const避免误改这是C里传递大对象的标配写法。如果参数不加const调用方无法确认函数会不会改动传入的对象接口的语义就不清晰。在类成员函数末尾加const表示这个函数不会修改对象的成员变量class Point { public: int getX() const { return x_; } // 常量成员函数 private: int x_; };常量成员函数可以被const对象调用非const成员函数不行。这个规则在设计不可变对象、编写线程安全代码时非常关键。3.4 const 常量的初始化时机陷阱const变量必须在定义时初始化这是硬性要求。但初始化的值来自哪里决定了它是编译期常量还是运行期常量。全局const变量如果初始值来自另一个编译单元的变量还会涉及静态初始化顺序问题——不同编译单元的全局变量初始化顺序是不确定的可能导致某个const变量在初始化时读到了未初始化的值。这类问题排查起来极其痛苦通常的规避方式是用函数内的局部static const或者干脆用constexpr。4. constexpr真正意义上的编译期常量4.1 constexpr 解决了什么问题C11引入constexpr核心目的就是明确表达这个值在编译期就能算出来。它和const最大的区别在于const只保证只读constexpr保证编译期可求值。constexpr int a 10; // 编译期常量 constexpr int b a * 2 1; // 编译期就能算出21 int arr[b]; // 合法b是编译期常量如果用const int b a * 2 1;虽然大多数编译器也能优化但标准层面不保证b是编译期常量用它定义数组长度在严格模式下可能不通过。constexpr则从语言层面给了保证。4.2 constexpr 函数编译期计算的利器constexpr还能修饰函数表示这个函数在参数是编译期常量时可以在编译期求值constexpr int square(int x) { return x * x; } constexpr int result square(5); // 编译期算出25 int runtime_val 7; int r2 square(runtime_val); // 运行期计算也合法constexpr函数的妙处在于双重身份参数是编译期常量时它编译期算参数是运行期变量时它当普通函数用。这让同一份代码既能用于编译期优化又能处理运行期数据。C14之后constexpr函数放宽了限制可以包含循环、条件分支、局部变量等写起来更接近普通函数。C17又引入了if constexpr可以在编译期做条件分支模板元编程的写法因此大幅简化。4.3 constexpr 与 const 的选型建议实际工程里的判断标准很简单如果这个常量必须在编译期确定用于数组长度、模板参数、static_assert、case标签等用constexpr。如果只是运行期不可修改用const即可。如果拿不准优先用constexpr——它能覆盖const的所有场景且约束更强编译器能帮你发现更多问题。有一个细节要注意constexpr变量隐含const所以constexpr int x 5;里的x本身就是常量不能再加const修饰加了也不报错但冗余。注意constexpr要求初始值必须是编译期常量表达式。如果写成constexpr int x someRuntimeFunc();编译直接失败。这个失败其实是好事它帮你把我以为这是编译期常量的误解当场暴露出来。5. enum 定义常量被低估的整型常量方案5.1 enum 作为常量集合的天然优势enum枚举本质上是给一组整型常量起名字。它最典型的用法是定义一组相关的常量enum Color { RED, // 0 GREEN, // 1 BLUE // 2 };不指定值时枚举成员从0开始依次递增。也可以显式指定enum HttpStatus { OK 200, NOT_FOUND 404, SERVER_ERROR 500 };用enum定义常量的好处是语义清晰、类型安全、便于调试。相比散落的#define枚举成员有作用域、有类型调试器里能看到名字而不是数字。5.2 传统 enum 与 enum class 的关键差异C11引入的enum class强类型枚举解决了传统enum的几个老问题对比项传统 enumenum class作用域成员泄漏到外层作用域成员限定在枚举内隐式转换可隐式转int不可隐式转int底层类型由编译器决定可显式指定前向声明受限支持传统enum的成员会污染外层命名空间两个不同的枚举如果有同名成员就会冲突。enum class把成员关在枚举内部用的时候必须写Color::RED避免了命名冲突。同时它不能隐式转成整数减少了误用。enum class Color { RED, GREEN, BLUE }; Color c Color::RED; // int x c; // 错误不能隐式转换 int x static_castint(c); // 必须显式转换5.3 enum 定义常量的适用边界enum适合定义一组相关的整型常量比如状态码、选项标志、类型标识。它不适合定义单个孤立的常量也不适合定义非整型的常量比如浮点数、字符串。如果你只需要一个constexpr double PI 3.14159;用enum就没意义了。另外enum的底层类型在传统写法里是不确定的可能是有符号也可能是无符号跨平台时可能出问题。enum class可以显式指定底层类型比如enum class Flag : uint8_t { ... };这在需要精确控制内存布局的场景如协议解析、硬件寄存器映射里很重要。6. define 定义常量能用但要清楚代价6.1 define 的本质是文本替换#define是预处理指令在编译之前由预处理器做纯文本替换。它不理解类型、不理解作用域、不参与编译器的语义分析#define MAX_SIZE 1024 #define PI 3.14159预处理器会把代码里所有MAX_SIZE直接替换成1024就像用文本编辑器的查找替换一样。这个机制带来了一系列问题。6.2 define 的经典陷阱陷阱一没有类型检查。#define PI 3.14159没有类型参与运算时可能触发意外的类型转换。而constexpr double PI 3.14159;有明确的double类型。陷阱二宏展开的括号问题。这是最经典的坑#define SQUARE(x) x * x int r SQUARE(2 3); // 展开成 2 3 * 2 3 11不是25正确写法要给参数和整体都加括号#define SQUARE(x) ((x) * (x))。但即便如此带副作用的参数仍会出问题比如SQUARE(i)会自增两次。陷阱三作用域失控。#define没有作用域概念一旦定义从定义点到文件末尾或#undef都有效容易和其他头文件里的同名宏冲突。陷阱四调试困难。调试器看到的是替换后的值看不到宏名排查问题时缺少线索。6.3 什么时候还该用 define尽管问题多#define在某些场景下仍不可替代头文件保护#ifndef XXX_H这类用法是预处理器的专属功能没有替代品虽然#pragma once更简洁但#define方式兼容性更好。条件编译#ifdef DEBUG这类跨平台、跨配置的编译开关只能用预处理器。字符串化与拼接#和##运算符是宏独有的能力用于生成代码或日志。但对于定义常量值这个用途现代C里基本没有理由再用#define。constexpr能提供类型安全、作用域控制、调试友好全面优于宏。我在代码审查里看到用#define定义数值常量的基本都会建议改成constexpr。7. 五种方式横向对比与选型决策7.1 一张表看清差异方式编译期确定类型安全有作用域可调试典型场景字面常量是是无是一次性使用的固定值const不一定是有是运行期只读变量constexpr是是有是编译期常量、模板参数enum是较强有enum class是一组相关整型常量define是文本替换无无差条件编译、头文件保护7.2 选型决策路径实际写代码时可以按这个顺序判断需要条件编译或头文件保护用#define这是它唯一不可替代的领域。是一组相关的整型常量用enum class语义清晰、类型安全。需要编译期确定的值用constexpr用于数组长度、模板参数、static_assert等。只是运行期不可修改用const。只用一次且语义明确直接用字面常量不必强行具名。7.3 几个容易踩的坑坑一用const当编译期常量。前面提过const int不保证编译期可求值用在需要编译期常量的地方可能编译失败。需要编译期常量就用constexpr。坑二#define和constexpr混用。同一个项目里两种风格并存维护时容易混乱。统一用constexpr只在预处理场景保留#define。坑三enum成员重名。传统enum的成员会泄漏到外层作用域两个枚举有同名成员就冲突。用enum class规避。坑四忽略constexpr函数的限制。C11的constexpr函数只能有一条return语句C14才放宽。如果项目还在用C11标准写复杂constexpr函数会受限。8. 我在实际项目里的使用习惯说点实在的。经过这些年写C我现在的习惯基本固定下来了数值常量一律用constexpr不管它是不是真的需要在编译期用。理由很简单——constexpr约束更强编译器能帮我发现更多问题而且它天然是const不会比const差。只有在初始值确实依赖运行期数据时才退而用const。一组相关的常量比如状态码、错误码、配置项枚举用enum class。它比一堆constexpr int更有组织性调试时能看到名字还能防止不同类型之间误赋值。#define只留给预处理相关的场景头文件保护、条件编译、平台相关的宏开关。定义数值常量这件事我已经很多年没用过#define了。还有一个细节值得分享constexpr变量在头文件里定义时每个包含它的编译单元都会有一份副本但因为它是编译期常量通常不会造成实际的存储开销编译器会内联替换。如果确实需要一份共享的存储可以用inline constexprC17起或者放在.cpp里配合extern声明。这个细节在写库的时候要注意普通应用开发基本不用操心。最后提一个排查技巧如果某个常量相关的代码行为诡异先确认它到底是编译期常量还是运行期常量。用static_assert测试一下比如static_assert(MAX_SIZE 1024);如果编译通过说明是编译期常量不通过就说明它是运行期的。这个手段比盯着代码猜要快得多。