C语言运算符与表达式深度解析：从优先级到未定义行为

1. 从一道面试题说起：为什么运算符和表达式是C语言的"分水岭"

我经常在面试里问候选人一个问题：int a = 5; printf("%d\n", a++ + ++a); 输出什么？这个问题没有标准答案，因为它在C语言标准里属于未定义行为。但有趣的是，几乎每个人都会先愣一下，然后开始掰手指算优先级。这说明什么？说明很多人在学运算符和表达式的时候，只是死记硬背了一张优先级表，根本没有理解背后的求值规则。

C语言的运算符和表达式，是这门语言真正拉开初学者和熟练开发者差距的地方。原因很简单：C语言的运算符极其丰富，有40多个，它们组合起来能写出非常简洁高效的代码，但同时也埋藏着大量的坑——优先级记错、类型隐式转换、副作用顺序不确定、短路求值忽略等等。很多线上bug，追到根上，就是一行表达式写得太"聪明"了。

这一章的内容，在经典教材里通常叫"运算符与表达式"，初看像是纯语法罗列，实际上它决定了你能否真正看懂别人的代码、能否写出可预测的代码。我见过太多人卡在指针和链表上，其实根源是运算符优先级没吃透——*p++ 到底先取指针还是先偏移？int *p[3] 是数组还是指针？这些问题全部指向同一块地基：运算符和表达式。

这篇文章不是教材的复述，而是我从实际项目、踩坑经历、以及多年带新人经验里提炼出来的一份"运算符与表达式深度拆解"。适合刚学完语法基础、想真正理解C语言的初学者，也适合那些写了好几年C但偶尔还被优先级坑一把的开发者。

2. 运算符全景图：C语言到底给你准备了哪些"工具"

2.1 按功能分类的运算符总表

C语言的运算符按功能大致可以分成以下几类，我直接给你一张整理好的总表。这张表我建议你收藏，比任何时候临时查书都方便。

这里特别提醒一句：位运算符和逻辑运算符千万别搞混。&& 是逻辑与，只关心两个操作数是否为真（非零即真）；& 是按位与，逐位运算。我第一次带项目时，有个同事写了一个 if (a & b)，他本意是想判断两个条件同时成立，结果因为 a 和 b 的值恰好特定位不同，整段逻辑在某个边界case下直接崩了。这就是基础概念不扎实导致的线上事故。

2.2 自增自减的前置与后置：一句话讲透

i++ 和 ++i 的区别，是面试官最爱考的，也是初学者最容易绕晕的。我的理解方式非常简单：

• i++：先返回 i 的当前值，再把 i 加1。
• ++i：先把 i 加1，再返回加完之后的 i。

所以：

c复制int i = 3;
int a = i++; // a = 3, i = 4
int b = ++i; // i = 5, b = 5

但要注意，这个"先返回"和"先加1"的顺序，仅在表达式中使用 i++ 或 ++i 的值时有意义。如果你单独写 i++; 或者 ++i;，两者完全等价，没有任何区别。

真正的坑在于：同一个变量在一个表达式中被多次修改，比如开篇那个 a++ + ++a。C语言标准规定，在两个序列点之间，同一个标量对象被修改超过一次，或者在修改值之外又使用它的旧值，行为是未定义的。也就是说，编译器想怎么算就怎么算，不同编译器、不同优化级别，结果都可能不一样。所以你在任何生产代码里看到这种写法，请毫不犹豫地重构掉。

2.3 逻辑运算符的短路求值：你可能一直在依赖它却毫不知情

&& 和 || 有个非常重要的特性：短路求值（short-circuit evaluation）。意思是，对于 a && b，如果 a 为假，那么整个表达式必为假，b 根本不会被求值；对于 a || b，如果 a 为真，整个表达式必为真，b 也不会被求值。

这个特性在实际项目里用得太多了。最典型的场景是：

c复制if (ptr != NULL && ptr->data > 10) {
    // 安全访问指针
}

如果 ptr 是空指针，ptr != NULL 为假，直接短路，后面的 ptr->data 根本不会执行，从而避免了空指针解引用崩溃。

另一个场景是简化边界判断：

c复制if (index < 0 || index >= size) {
    printf("索引越界\n");
    return;
}

index 等于 -1 时，第一个条件为真，直接短路，不会再判断 index >= size，避免了对 size 的无意义比较。

但短路也是一把双刃剑。如果你在表达式右边写了有副作用的调用，而左边短路了，那这个副作用就不会发生。比如：

c复制int a = 0;
if (a != 0 && foo() > 10) {
    // 如果 a == 0，foo 根本不会被调用
}

如果你误以为 foo() 一定会被调用，在这里初始化了什么全局状态，那就会踩坑。写代码时保持一个习惯：短路求值依赖的表达式，右边不要放有副作用的函数调用。

3. 优先级与结合性：一张表读懂，但要靠"场景"记住

3.1 优先级速查表：那些最容易记错的组合

C语言的运算符优先级有15个级别，从高到低排列。完整记住一张表不是不可能，但对大多数人而言，记住几个最容易搞错的组合，远比背全表更实用。我挑几个高频出错的场景：

最后一个 a & b == c 这个场景，我在代码review里见过不止一次。写的人本意是 (a & b) == c，判断按位与的结果是否等于 c，但因为优先级陷阱，实际执行的是 a & (b == c)。这种bug极难排查，因为语法完全合法，编译不报错，逻辑错误只在特定数值下暴露。

我的建议是：不要指望自己记得住所有优先级，写代码时只要涉及混合运算，一律加括号。括号不仅能让编译器按你的意图执行，更重要的是让读代码的人一眼看懂你想干什么。代码是写给人看的，顺便让机器能跑而已。

3.2 结合性：为什么 a = b = c = 3 能成立？

优先级解决的是"谁先运算"的问题，结合性解决的是"同级别的谁先谁后"的问题。

C语言的绝大多数运算符是左结合（从左到右），但赋值运算符和三目条件运算符是右结合（从右到左）。这就解释了为什么 a = b = c = 3 合法：因为 = 是右结合，所以先执行 c = 3，结果是3，然后 b = 3，最后 a = 3。

类似的还有 a <<= 1 之类的复合赋值，它们同样右结合。

结合性在实际中还有一个典型场景，就是链式比较。很多人刚从Python转过来会写 if (1 < x < 10)，这在C语言里是合法的，但逻辑完全不是你想象的那样。因为 < 是左结合，所以先算 1 < x，结果要么是0（假）要么是1（真），然后用这个0或1去跟10比。无论 x 是多少，0 < 10 和 1 < 10 都恒为真，于是这个条件永远成立。想要表达"x在1到10之间"，必须写成 if (x > 1 && x < 10)。

3.3 从项目实战中提炼的优先级记忆法

背表太枯燥，给你一个我当年学的时候用的场景记忆法——想象自己在写一段真实代码：

c复制// 场景1：解析网络包的工具函数
int len = packet->header.len & 0x0F;
// 这里 -> 先执行，然后取成员 len，最后 & 0x0F
// 实际等价于 (packet->header.len) & 0x0F

// 场景2：判断一个数是否是2的幂
if (n > 0 && (n & (n - 1)) == 0) {
    // 是2的幂
}
// 这里如果用 n & (n - 1) == 0，结果就完全错了
// 因为 == 优先级高于 &，会变成 n & ((n-1) == 0)

// 场景3：嵌入式寄存器操作
REG |= (1 << 3) & ~(1 << 2);
// 等价的完整加括号版本：REG = REG | ((1 << 3) & (~(1 << 2)))

每次你写一行混合运算符的表达式，先在脑子里过一遍：这里是不是要靠优先级才能正确？如果是，就加括号。久而久之，你会形成一种本能反应，根本不需要刻意背表。

4. 类型转换：隐式转换和强制转换的那些"隐秘角落"

4.1 整型提升与寻常算术转换：为什么都是int在作怪

C语言的类型转换有一个核心规则体系，叫"寻常算术转换"（usual arithmetic conversions），加上一个整型提升（integer promotion）前置步骤。

整型提升的意思是：凡是 char、short 这类比 int 小的整型，在参与表达式运算时，一律先提升为 int 再参与运算。如果 int 装不下，就提升为 unsigned int。这是C语言标准规定的。

这导致了一个经典坑：

c复制char a = 200;
char b = 100;
char c = (a + b) / 2;
// a 和 b 都被提升为 int，a + b = 300，除以2 = 150，赋回 char 没问题

char d = a + b; // 300，赋回 char（假设 char 是 signed char，范围 -128~127），溢出，结果不确定

再看一个面试常考的：

c复制unsigned int a = 10;
int b = -20;
// a > b ?

结果是 a > b 为真。为什么？因为当 unsigned int 和 signed int 混合运算时，有符号的 b 会被转换成无符号的 -20，也就是一个非常大的正整数（4294967276），所以 10 > 4294967276 为假？不对，10当然不可能大于那个数。等等，我重新说清楚：

在 a > b 这个比较中，b 被转换为 unsigned int，值变成 UINT_MAX - 20 + 1，即 4294967276，然后比较 10 > 4294967276，结果为假，所以整个表达式输出 0。

这里极容易判断错，我给面试者讲的时候，10个人里有7个人先说"10大于-20嘛，所以为真"。这就是C语言整型转换规则的隐秘角落。

4.2 强制类型转换什么时候该用，什么时候别用

强制类型转换的语法是 (类型)表达式。它在某些场景下是必要的，但滥用会掩盖bug。

该用的时候：

• 浮点数转整数时明确截断意图：int n = (int)3.99; 结果是3，不是四舍五入。
• 指针类型转换：void* 转具体类型指针，这在通用接口设计里很常见。
• 整数除法得到浮点数：double ratio = (double)a / b; 注意这里只用把 a 转成 double 就行，除法就是浮点除法了。

不该用的时候：

• 为了消除编译警告而强制转换，但不理解本质原因。比如把 int 强制转成 char，结果数据被截断，但你根本意识不到。
• 在指针和整数之间乱转，除非你很清楚自己在做什么（嵌入式底层开发除外）。

我有一个实操经验：如果你发现自己写了很多强制类型转换，大概率是前面的类型设计不够好。C语言的类型系统已经够原始了，尽量避免在业务逻辑层到处做强制转换，那只会让代码不可读、不可维护。

4.3 整数溢出：C语言里最容易被忽视的未定义行为

有符号整数溢出在C语言标准里是未定义行为（undefined behavior），意思是编译器可以认为这种情况永远不会发生，然后基于这个假设做各种优化。这会导致一个很诡异的现象：同一个代码在不同优化级别下结果不同。

一个经典例子：

c复制int a = INT_MAX; // 2147483647
printf("%d\n", a + 1); // 未定义行为，可能输出 -2147483648，也可能是别的

在 gcc 不开优化时，可能输出 -2147483648（回绕），但开了 -O2 优化后，编译器可能直接把整个表达式优化成它认为的"不可能发生"路径，结果完全不同。

应对策略很朴素：涉及用户输入、文件大小、网络报文长度等可能被人为构造的数值时，务必在运算前做溢出检查。简单的方式是把运算放到更大范围的数据类型里做：

c复制long long result = (long long)a + b;
if (result > INT_MAX || result < INT_MIN) {
    // 溢出，处理错误
}

还有一个常见的认知误区：无符号整数溢出是定义良好的（按模2的N次方回绕），有符号整数溢出是未定义行为。这个区别一定要记牢。

5. 表达式的求值顺序：别让"副作用"找你麻烦

5.1 序列点与副作用：未定义行为是怎么产生的

C语言里的"序列点"是一个顶层概念。简单说，序列点之前的操作必须先完成，之后的操作才能开始。常见的序列点包括：

• ; 分号处
• 短路求值的 && 和 || 处
• 逗号运算符处
• 函数调用时，所有参数求值完成、真正进入函数体之前的点

如果你的代码在两个序列点之间修改了一个变量的值，并且这个修改不是通过"取该变量的当前值"来完成的，那么行为就是未定义。

举几个典型坏代码：

c复制// 未定义行为：在两个序列点之间，i 被修改了两次
i = i++ + 1;

// 未定义行为：函数参数求值顺序不固定
printf("%d %d\n", i++, i++);

// 未定义行为：i 在表达式中被修改，同时也被读取旧值
a[i] = i++;

其中 printf("%d %d\n", i++, i++) 这个问题，经常出现在初学者调代码时想"顺便"看一下自增效果，结果打印出的顺序在不同编译器下完全不一样。

5.2 函数参数的求值顺序：不要依赖它

C语言标准规定，函数参数的求值顺序是unspecified（未指定），编译器可以自由选择从左到右、从右到左，或者其他顺序。所以：

c复制int x = 1;
printf("%d %d %d\n", x, ++x, x++);

这个表达式在不同编译器下的输出可能完全不同，甚至连碰都不要碰。

我做项目时的经验是：所有函数调用参数，如果可能产生副作用，就先算好放到临时变量里。

c复制int tmp1 = get_val(1);
int tmp2 = get_val(2);
printf("%d %d\n", tmp1, tmp2);

这样写虽然多两行，但结果确定，可读性也更好。

5.3 逗号运算符：冷门但偶尔有用的"顺序保证"

逗号运算符（不是函数参数里的逗号分隔符，而是一个真正的运算符）保证了从左到右的求值顺序，并且整个逗号表达式的值是最右边那个表达式的值。

c复制int a = (1 + 2, 3 * 4); // a = 12

// 典型用法：在 for 循环里一次更新多个变量
for (int i = 0, j = 10; i < j; i++, j--) {
    printf("%d %d\n", i, j);
}

注意区别：在变量声明里 int i = 0, j = 10; 中的逗号是声明分隔符，不是逗号运算符。在 for 循环的 i++, j-- 中，逗号才是真正的逗号运算符。

逗号运算符在实际开发中用得不多，但在宏定义里偶尔会有奇效。比如你想让一个复杂的宏按固定顺序执行多个操作，并返回最后一个结果：

c复制#define SAFE_FREE(ptr) (free(ptr), (ptr) = NULL)

这里 SAFE_FREE 先释放内存，然后把指针置空，整个宏的结果是 (ptr) = NULL 的赋值结果。不过这有个前提：ptr 必须是左值，且没有被重复求值的副作用问题。宏定义里参数被多次使用本身就有隐患，用逗号运算符可以在一定程度上控制求值顺序。

6. sizeof 与类型转换：静态世界和动态世界的交界

6.1 sizeof 是编译时运算符，不是函数

sizeof 是一个运算符，不是函数。它在编译阶段就能确定结果，不会在运行时执行任何代码。所以你可以写 sizeof(int)，也可以写 sizeof a（不加括号，因为它是运算符）。

需要特别注意的一个场景：

c复制int arr[10];
sizeof(arr) / sizeof(arr[0]); // 数组元素个数，经典用法

// 但下面的写法有陷阱
void func(int arr[]) {
    // arr 在这里是退化成了指针
    sizeof(arr); // 结果是指针的大小，不是数组的大小
}

这个"数组参数退化"导致 sizeof(arr) 在函数内部得到的是 sizeof(int*)，而不是整个数组的内存大小。很多新手在函数里用 sizeof(arr)/sizeof(arr[0]) 来算数组长度，得到的结果完全不对。正确的做法是在调用函数时，把数组长度作为参数传进去，或者定义成宏/结构体。

6.2 sizeof 与表达式：只查类型，不求值

sizeof 另一个冷门特性是：它只关心操作数的类型，不会对表达式进行求值。比如：

c复制int i = 0;
int size = sizeof(i++); // i 不会自增，size 是 sizeof(int)

这里 i++ 根本没有执行，因为 sizeof 只需要知道 i++ 的类型是 int 就够了。这个特性在某些极端场景下可以用来"测试类型"，但日常开发中很少有人刻意用。

7. 实战避坑指南：我在真实项目中踩过的运算符坑

7.1 位运算与逻辑运算混用的教训

有一次我接手一个网络协议解析模块，要把收到的数据包头解析成各种标志位。原代码大概是：

c复制if (flags & FLAG_A && flags & FLAG_B) {
    // 处理 A 和 B 同时置位的逻辑
}

这段代码在绝大多数情况下是正常的，因为 & 的结果要么非零要么零，&& 接收的就是这个结果。但问题是：如果在某个版本里，FLAG_A 定义为 0x80，FLAG_B 定义为 0x00？那 flags & FLAG_B 永远为0，这个条件永远为假，但逻辑上你可能希望"没有B标志时走另一个处理流程"。

这种bug不会让程序崩溃，但会让行为悄悄发生变化。排查的时候，第一反应是去看协议文档，第二反应是打日志，很少有人一眼发现是运算符混用造成的。我现在写这类代码的原则是：位判断一律用 (flags & FLAG_A) != 0 的完整写法，逻辑判断用 &&，绝不混着写。

7.2 移位运算的陷阱：移位数不能超过类型宽度

C语言标准规定，移位操作符右侧的操作数（移位的位数）必须小于左侧操作数的位宽。如果你写：

c复制int a = 1;
int b = a << 32; // 未定义行为，因为 int 是32位

在 x86 平台上，CPU 会把 32 对 32 取模，变成 a << 0，结果等于1。但这不是标准保证的，换到 ARM 平台或者不同的编译器，结果可能完全不同。更隐蔽的是：

c复制unsigned int mask = 1u << 31; // 合法，最高位是1
int sign = (int)mask; // 实现定义行为，可能是负数

如果左移导致符号位被置1，结果在标准中属于未定义行为（有符号整数）或实现定义行为（无符号转有符号）。写底层代码时，尽量用 unsigned 类型做位运算，不要在有符号类型上折腾。

7.3 浮点数比较：永远不要用 ==

这不是运算符本身的问题，而是浮点数在计算机里的表示方式决定的。0.1 + 0.2 的结果并不是 0.3，而是一个略大于或略小于 0.3 的二进制近似值。所以：

c复制double a = 0.1 + 0.2;
if (a == 0.3) {
    // 这个条件几乎永远不会为真
}

正确的比较方式是比较差值的绝对值是否小于一个阈值：

c复制if (fabs(a - 0.3) < 1e-6) {
    // 认为两者"足够接近"
}

同样，不要用 a != b 这种形式判断浮点数不相等。浮点运算的精度有限，每一步运算都可能引入舍入误差。

7.4 条件运算符嵌套：代码可读性的杀手

三目运算符 a ? b : c 用得好是简洁，用不好就是灾难。我看到过有人写这种代码：

c复制result = (a > 0) ? (b > 0 ? (c > 0 ? 1 : 2) : 3) : (c > 0 ? 4 : 5);

这个逻辑关系完全可以用嵌套的 if-else 清晰表达，写成三目嵌套除了炫技，对维护者没有任何好处。我的规矩是：三目运算符最多套一层，多于一层就改写成 if-else。这不算技术问题，纯属团队协作里的规矩问题。

8. 几种易混淆表达式的专项拆解与记忆锚点

8.1 指针相关的优先级组合

• int *p[3]：由于 [] 优先级高于 *，所以是"p是一个数组，数组里每个元素是 int*"，即 int 指针数组。
• int (*p)[3]：加括号改变优先级，p 是一个指针，指向"含有3个 int 的数组"，即数组指针。
• int *f(int)：f 是一个函数，返回 int*。
• int (*f)(int)：f 是一个函数指针，函数接受一个 int 参数，返回 int。

这四个定义看起来差不多，实际含义天差地别。我在带实习生的时候总结了一个判断口诀：先找变量名，再看优先级，谁先和变量名结合，谁就是变量的核心身份。

8.2 优先级与求值顺序不是一回事

很多人把"优先级"和"求值顺序"画等号，这是最大的误区。

优先级决定的是运算符的"结合关系"，也就是哪个运算符和哪个操作数组成一个子表达式。求值顺序决定的是一个表达式里各个部分谁先被计算。C语言里，除了少数几个运算符（如 &&、||、?:、逗号运算符）明确规定了求值顺序，其他运算符的操作数求值顺序都是未指定的。

举个例子：

c复制int a = f() + g();

这里 f() 和 g() 哪个先被调用？不知道。可能 f 先，也可能 g 先，完全看编译器的安排。如果你的 f 和 g 之间有共享状态的副作用，那结果就可能不稳定。

c复制int x = 0;
int f() { return ++x; }
int g() { return x * 2; }
int a = f() + g(); // 结果取决于 f 和 g 的调用顺序

这种代码一旦进入多线程环境，就更加不可控。解决方案很简单：显式安排顺序。

c复制int tmp_f = f();
int tmp_g = g();
int a = tmp_f + tmp_g;

8.3 表达式求值中的左值与右值

"左值"（lvalue）和"右值"（rvalue）是理解赋值、自增、指针等概念的基础。

简单理解：左值代表一块内存位置，可以被读写；右值代表一个数据值，没有明确的内存位置。

c复制int a = 10; // a 是左值，10 是右值
int b = a;  // a 被读取，此时它作为右值使用；b 是左值

++a 要求操作数必须是左值，因为它需要修改内存中的值。a++ 同样要求左值操作数，但它返回的是一个右值（旧值）。这就是为什么你不能写 ++10，因为 10 不是左值。

这个知识点在指针运算里尤其重要。p++ 能成立，是因为 p 是左值；*p++ 能成立，是因为 *p 也是左值（它代表一块内存）。理解了左值右值，你就能看懂为什么某些表达式合法、某些不合法。

8.4 学习工具的推荐：从语法树看表达式

如果你想真正理解一个复杂表达式的解析过程，与其死记硬背，不如用工具直接看"表达式分析树"。

• clang 提供 -Xclang -ast-dump -fsyntax-only 参数，可以输出完整的 AST（抽象语法树），把 a + b * c 是怎么分组的看得清清楚楚。
• 网页版的 C syntax analyzer 也能做类似的事，适合快速验证单个表达式。

我自己的习惯是：遇到一个不确定的表达式，直接丢给工具看AST，而不是靠猜。猜一次错了，以后就形成错误的直觉，影响很多年。

9. 运算符与表达式的高频考点与自测清单

整理一份我在招聘和辅导过程中反复使用的自测题，每道题背后都藏着一个容易忽视的C语言特性。建议你先自己做，再看答案和解析。

1. int a = 5; a += a *= 2; 最后 a 是多少？
2. int x = 3; printf("%d", x << 2 + 1); 输出多少？
3. char c = 0x80; unsigned int u = 1; if (c > u) ... 条件成立吗？
4. int a[5]; int *p = a; p + 3 和 &a[3] 是否相等？
5. int n = 0; int m = n++ || n++; 最后 n 和 m 是多少？
6. double d = 3.7; int i = (int)d; i 是多少？d 变了吗？

第1题：a *= 2 先执行，a = 10；然后 a += a 相当于 a = a + a，注意此时 a 已经被改成 10 了，所以 a = 10 + 10 = 20。

第2题：+ 优先级高于 <<，所以 x << (2 + 1)，即 3 << 3，结果是 24。如果写的是 (x << 2) + 1，结果就是 13。

第3题：成立。c 是 char，可能是 signed char，值 0x80 被解释为 -128。当 -128 与 unsigned int u 比较时，-128 先被转换为 unsigned int，变成 UINT_MAX - 127，也就是 4294967168，必然大于 1。

第4题：相等。数组名 a 在表达式里退化为指向首元素的指针，p + 3 指向第4个元素，&a[3] 也是一个指向第4个元素的指针。

第5题：m = 0 || 0 = 0（短路求职其实不会触发，因为第一个 n++ 返回0，为假，所以右边 n++ 仍会执行），两个 n++ 让 n 自增了两次，最终 n = 2，m = 0。

第6题：i = 3，d 依然是 3.7。强制类型转换会生成一个新值来保存转换结果，原变量不受影响。

这六道题如果全部一次性答对，你的运算符和表达式基础已经非常扎实了；如果错了三道以上，建议把本文前面几节再刷一遍。

10. 从入门到实战：构建你自己的"表达式安全"习惯

学了这么多，最后落地到工程实践，我认为真正重要的不是记住每一个运算符的优先级，而是建立一套"表达式安全"的编码习惯。分享几条我在代码review时会重点关注的原则。

第一，表达式里混合运算符超过两个，一律加括号。这不是说自己看不懂，而是为了保护未来接手这份代码的同事。人脑解析表达式的速度，远低于编译器。括号让编译器和人脑达成一致。

第二，绝不在同一个表达式里对同一个变量做多次自增自减或赋值。无论你用 gcc 测出来的结果是什么，都不要依赖它。未定义行为就是未定义行为，今天的编译结果不代表明天也是这个结果。

第三，所有有符号整数的运算，如果存在溢出可能（加法、乘法、左移），先想想输入范围。C语言不会替你检查整数溢出，它只保证按你写的代码执行，溢出后的行为是未定义的。

第四，位运算统一用无符号类型。有符号右移是算术右移还是逻辑右移，标准里是实现定义行为。虽然主流编译器都是算术右移，但你在 char、short 这些可能隐式转换的类型上折腾，很容易踩到符号扩展的坑。

第五，浮点数比较永远走阈值判断，不要用 == 和 !=。

第六，不要在条件判断里写带有副作用的表达式。if ((fd = open(...)) < 0) 这种写法虽然简洁，但在代码审查里总是会引起争议。折中方案是写成 int fd = open(...); if (fd < 0)，清晰且安全。

最后，我再分享一个小工具层面的经验：编译时开 -Wall -Wextra -Werror，让编译器帮你盯着。许多优先级和类型转换问题，编译器不是不能提醒，而是默认级别太低不提醒。开了这几个选项，很多容易栽的坑会在编译阶段就被拦截下来。

在实际项目里，这六条原则帮我挡住了无数潜在的线上事故。归根结底，C语言给了程序员极大的自由度，但这份自由必须以纪律来驾驭。运算符与表达式，正是体现这门纪律的第一个主战场。