单独使用 >> 16 提取R分量会出错，因未清除高位干扰：有符号类型会符号扩展，无符号类型也可能含无关高位数据，必须先用掩码（如 & 0xFF0000）再右移。
右移操作本身不能直接提取 RGB 分量，必须配合按位与（
）清除高位干扰，否则会得到错误值。
为什么单独
取 R 分量会出错
RGB 像素通常以 32 位整数（如 0xFFAABBCC）或 24 位打包形式存储，R 在最高 8 位。但直接
会把符号位（若为有符号 int）或高位残留数据一并带入——比如 Java 中
是有符号的，0x80000000 右移后补 1，结果失真；C/C++ 若用
存颜色，同样面临符号扩展风险。
必须先用掩码清除无关位，再右移：例如
若 color 是无符号类型（如
），仍建议先掩码——避免依赖类型定义，提升可移植性
某些语言（如 JavaScript）无真正整型，
（无符号右移）才安全，
会按有符号处理
和
的顺序不能颠倒
先右移再 & 0xFF 看似省事，但存在精度丢失风险：比如 G 分量在中间 8 位（0x00FF00），若写成
是对的；但若 color 是 64 位值且高位非零（如 0x123456789ABCDEF0），
得到 0x123456789ABCDEF，再 & 0xFF 仍正确；可一旦你误用
（运算符优先级导致先算
再
），结果恒为 0。
务必加括号明确结合顺序：
记住位运算优先级：& 高于 >>，所以
等价于
→
不同语言优先级一致（C/Java/JS/Python 均如此），这不是风格问题，是语法铁律
常见内存布局与对应位移方案
RGB 打包顺序决定移位基数。最常见的是 0xAARRGGBB（ARGB）或 0xRRGGBB（RGB），但 OpenGL、BMP、某些 GPU 纹理可能用 BGR。不确认格式就硬套
必然翻车。
ARGB（A 最高 8 位）：
，
，
RGBA（A 最低 8 位）：
，
，
BGR（如 OpenCV 默认）：
，
，
永远检查源数据文档或打印一个已知像素（如纯红）的十六进制值来验证布局
真正容易被忽略的不是怎么移，而是“移之前那几位到底属于谁”——没有上下文的位运算毫无意义。拿到一个整数，第一件事不是写
，是用调试器或
看它长什么样。
&>> 16color >> 16intint(color & 0xFF0000) >> 16uint32_t>>>>>& 0xFF>> n(color >> 8) & 0xFFcolor >> 8color & 0xFF >> 8&>>(color >> 8) & 0xFFcolor & 0xFF >> 8color & (0xFF >> 8)color & 0>> 16R = (color >> 16) & 0xFFG = (color >> 8) & 0xFFB = color & 0xFFR = (color >> 24) & 0xFFG = (color >> 16) & 0xFFB = (color >> 8) & 0xFFR = color & 0xFFG = (color >> 8) & 0xFFB = (color >> 16) & 0xFF>> 16printf("%08x", color)