为什么RGB转uint32的预处理宏输出的颜色码结果错误？

你的计算过程存在三处核心错误：

• 移位后的字节对齐完全错误，g << 8 对应的是倒数第二个字节，也就是三个存储字节的中间位置，而非你误以为的最高位字节，和b <<16的存储区间没有重叠
• 你在最后一步错误地将r左移了24位参与计算，按照题目要求r存储在最后一个（最低位）字节，不需要移位，直接放在最低8位即可
• 或运算时你错误对齐了所有操作数的二进制位，导致三个值的存储区间完全重叠，最终结果自然偏离正确值

正确计算过程拆解 #

我们先明确三个颜色值的存储规则：

三个8位数值从高到低（字节顺序）为：蓝 → 绿 → 红，对应偏移位数分别是16位、8位、0位，三个区间没有重叠，位或运算和直接加法结果等价。

以你给出的r=20、g=30、b=40为例：

1. 蓝值b=40，二进制8位为 00101000，左移16位后结果：
   00101000 00000000 00000000，对应十进制为 40 * 65536 = 2621440
2. 绿值g=30，二进制8位为 00011110，左移8位后结果：
   00000000 00011110 00000000，对应十进制为 30 * 256 = 7680
3. 红值r=20，二进制8位为 00010100，无需移位，结果：
   00000000 00000000 00010100，对应十进制为 20
4. 三次位或运算等价于三个值相加：2621440 + 7680 + 20 = 2629140，和你运行程序得到的结果完全一致。

理解位运算存多值的核心逻辑 #

你可以把每个8位的颜色值理解成独立的“抽屉”，左移的位数就是给抽屉安排位置：

• 每个抽屉占8位空间，互相之间没有重叠
• 位或运算的作用只是把三个抽屉的内容合并到同一个整数里，不会互相干扰，因为每个值的1都只出现在自己的抽屉区间里

如果要验证宏的正确性，也可以反过来拆分返回的long值：

• 取红值：color & 0xFF
• 取绿值：(color >> 8) & 0xFF
• 取蓝值：(color >> 16) & 0xFF
  拆分出来的结果和你传入的参数完全一致，就说明宏的逻辑是对的。

内容的提问来源于stack exchange，提问作者programme3219873