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