必须用&&而非&：逻辑判断需短路求值，如ptr!=NULL&&ptr->data>0避免空指针解引用；必须用&而非&&：位操作需保留位模式，如status&0x04检测特定位。
什么时候必须用 && 而不能用 &
当判断逻辑条件、需要短路求值时，&& 是唯一安全选择。比如 ptr != NULL && ptr->data > 0：如果 ptr 为 NULL，&& 会跳过右边表达式，避免非法内存访问；而 & 会强制两边都执行，直接触发段错误。
常见错误现象：if (x != 0 & y / x > 1) 在 x == 0 时仍会执行 y / x，导致除零异常。
-
&&是布尔逻辑操作符，操作数被隐式转换为_Bool（非零 → 1，零 → 0） -
&是整型位运算符，要求操作数是整数类型，不支持浮点或指针直接参与 - 在
if、while、for的控制表达式中，默认意图是逻辑判断，应无条件优先选&&
什么时候必须用 & 而不能用 &&
当需要提取、屏蔽或测试特定位时，& 不可替代。例如读取寄存器状态、解析协议字段、实现权限掩码：
uint8_t status = read_register();
if (status & 0x04) { /* 检查第2位是否置位 */ }使用场景包括：
立即学习“C语言免费学习笔记（深入）”；
- 位掩码检查（如
flags & READ_PERMISSION） - 清零特定位（如
reg &= ~0x08） - 从字节中提取低4位（
byte & 0x0F）
若误用 &&，比如 status && 0x04，结果只有 0 或 1，完全丢失原始位信息，且无法用于后续位操作。
&& 和 & 在表达式中的返回值差异
返回值类型和含义完全不同，直接影响赋值和嵌套使用：
-
&&返回int类型的 0 或 1，语义是“整体逻辑真/假” -
&返回与操作数类型一致的整数值，语义是“按位交集结果”
例如：
int a = 5, b = 3; // 二进制：101 & 011 int x = a && b; // x == 1（逻辑真） int y = a & b; // y == 1（001，按位与结果）
看起来结果相同，但本质不同：a && b 只关心“是否都非零”，a & b 计算的是具体位模式。一旦操作数变大（如 a=6, b=3 → 110 & 011 = 010 = 2），结果就明显分化。
容易被忽略的隐式类型转换陷阱
混合使用时，C 的整型提升规则会让问题更隐蔽。比如：
char flag = 0xFF;
if (flag & 0x80) { ... } // OK：0xFF & 0x80 → 0x80 ≠ 0但若写成：
if (flag && 0x80) { ... } // 危险：flag 被提升为 int 后仍是 -1（有符号 char），&& 结果为 1 —— 逻辑正确但掩盖了位意图更糟的是：
- 有符号数右移或参与
&时可能因符号扩展出错（建议统一用uint8_t等明确无符号类型） -
&&对浮点数虽合法（0.0 && 1.5→ 0），但语义模糊，应避免；而&完全不接受浮点操作数，编译报错invalid operands to binary & - 宏定义中误用（如
#define IS_SET(x, bit) ((x) & (bit))若写成&&就彻底失效
位操作的上下文里，哪怕看起来“结果一样”，也别用 && 替代 & —— 它们解决的根本不是同一类问题。
