按位与&操作二进制位，逻辑与&&判断真值且短路；前者总计算两边，后者仅左为真时算右；混用会导致条件误判或位操作失效。
按位与 & 是逐位运算，逻辑与 && 是短路布尔判断
根本区别不在符号长短，而在语义层级：& 操作的是整数的二进制位，不管数值代表什么含义；&& 操作的是“真值”（非零为真，零为假），且只在左操作数为真时才求右操作数。这意味着 && 有执行顺序依赖和副作用控制能力，而 & 总是两边都算。
& 和 && 在表达式中混用会引发隐性 bug
常见错误是把条件判断写成 if (a & b)，本意是“a 和 b 都非零”，结果却做了按位与——比如 a = 2（二进制 10），b = 1（01），a & b 得 0，整个条件意外失败。反过来，若误用 && 做位操作（如掩码提取），比如 flag && 0x04，就完全得不到预期的位结果，因为 && 只返回 0 或 1。
- 判断多标志是否同时置位：用
&，例如if ((flags & (FLAG_A | FLAG_B)) == (FLAG_A | FLAG_B)) - 串联多个独立条件：用
&&，例如if (ptr != NULL && ptr->valid && ptr->len > 0) - 避免副作用被跳过：若右操作数含函数调用或自增，
&&可能不执行它，&则一定执行
整型提升和零值判定让 && 的行为更“智能”
&& 的左右操作数会被当作布尔值处理：任何非零值都转为“真”，零转为“假”；结果也只返回 0 或 1。而 & 严格按整型值运算，保留所有位，结果可能远大于 1（如 0xFF & 0xF0 得 0xF0）。这意味着：
-
if (x & y)真值取决于结果是否为零，不是“x 和 y 是否都非零” -
if (x && y)才真正等价于 “x ≠ 0 且 y ≠ 0” - 当变量是
char或short时，&会先整型提升再运算，但值仍保持位模式；&&提升后只看是否为零
宏定义或条件编译里误用 & 替代 && 极难调试
预处理器不理解 C 语义，#if (FLAG_A & FLAG_B) 是合法的，但若 FLAG_A 和 FLAG_B 是互斥位（如 1 和 2），这个表达式恒为假，导致分支被错误剔除。而 #if (FLAG_A && FLAG_B) 是非法的——预处理器不支持 &&，直接报错，反而暴露问题。
立即学习“C语言免费学习笔记（深入）”；
真正安全的位组合判断应写成 #if ((FLAGS & (FLAG_A | FLAG_B)) == (FLAG_A | FLAG_B))，靠括号和显式掩码确保意图清晰。
最易被忽略的是：在指针有效性检查、资源状态轮询、中断标志读取等场景下，一个符号之差可能让程序跳过关键校验，或意外触发未初始化内存访问。别依赖“看起来差不多”。
