最直接判断奇偶的方式是用 % 运算符：n % 2 == 0 判偶数，n % 2 != 0 判奇数；它语义清晰、对有符号整数行为确定，且编译器会优化为位运算，性能与 n & 1 等价。
用 % 运算符判断奇偶是最直接的方式
绝大多数场景下，n % 2 == 0 就是判断偶数、n % 2 == 1（或 != 0）判断奇数的标准写法。它语义清晰、可读性强，且对有符号整数（int、long 等）行为确定：C++ 标准规定，当被除数为负时，% 的余数符号与被除数一致，所以 -3 % 2 是 -1，-4 % 2 是 0，仍能正确区分奇偶。
注意点：
- 不要写成
n % 2 == -1来判断奇数——虽然对负奇数成立，但会漏掉正奇数（如3 % 2 == 1），应统一用n % 2 != 0 -
%对浮点数不合法，必须用于整型；若变量是double，先转int要小心截断误差 - 编译器对
% 2通常会自动优化为位运算，实际性能和位运算是等价的（见下条）
用 & 位运算判断只适用于无符号或非负整数
表达式 n & 1 的结果是 1（真）表示奇数，0（假）表示偶数。原理是二进制最低位决定奇偶：偶数末位必为 0，奇数必为 1。
但这里有个关键限制：
立即学习“C++免费学习笔记（深入）”；
- 对
unsigned int、size_t等无符号类型，n & 1安全可靠 - 对
int等有符号类型，若n为负，在二进制补码表示下n & 1依然能正确返回0或1（因为补码的最低位定义不变），所以实践中也常可用 - 真正危险的是：如果
n是char或short，参与&时会整型提升（promoted）为int，但只要原值在范围内，结果不受影响
所以效率上，n & 1 和 n % 2 在现代编译器（如 GCC/Clang 启用 -O2）下生成的汇编指令几乎完全相同——编译器早就把 % 2 优化成了 and 指令。手动写 & 1 并不会更快，只是少打几个字符。
什么时候 & 1 可能出错？
问题不在运算本身，而在类型隐式转换和边界理解偏差：
- 若
n是bool类型，n & 1永远是n自身（因为true提升为1，false为0），看似“工作”，但语义错乱——bool本就不该被当作数值奇偶判断 - 若
n是用户自定义类型并重载了&，行为完全不可控；而%通常未被重载，更安全 - 最隐蔽的坑：
std::vector<bool>::reference</bool>是代理类型，v[i] & 1可能触发未定义行为或编译失败，而v[i] % 2直接报错，反而更容易暴露问题
别为“位运算更快”过早优化
除非你在写嵌入式裸机代码、或对每纳秒都敏感的 HPC 内核循环，否则没必要纠结这个。真实瓶颈从来不在这里：
- 分支预测失败（比如在随机奇偶混合的数据上频繁
if (n & 1)）比运算本身耗时多得多 - 缓存未命中、内存访问模式、函数调用开销，都比
& 1vs% 2的差异大几个数量级 - 可读性优先：团队里新来的同事看到
n & 1要停顿半秒反应，看到n % 2 == 0一眼就懂
真正值得花时间的地方，是确认你的数据类型是否真的需要奇偶判断、是否可能为空、是否涉及线程安全——这些地方出的 bug，远比选哪个运算符难查得多。
