直接拼接字符串比位运算更慢是因为现代 js 引擎已深度优化字符串拼接，而错误位运算会触发隐式装箱或慢路径；真正提效需确保输入为0–255整数、批量处理、合成24位整数后一次性转hex并补零。
为什么直接拼接字符串比位运算更慢
很多人以为位运算是“高性能”的代名词，但 RGB 转 #RRGGBB 时，盲目套用位运算反而容易出错且不提速。核心在于：现代 JavaScript 引擎对字符串拼接（r.toString(16) + g.toString(16) + b.toString(16)）做了深度优化；而手动位运算若没处理好补零、符号位、类型转换，会触发隐式装箱或慢路径。
真正能靠位运算提效的场景，是已知 RGB 值为整数（0–255）、需批量转换、且目标环境对 toString(16) 调用敏感（如 WebGL 着色器预处理、嵌入式 JS 引擎）。
-
r、g、b必须是无符号 8 位整数，否则>> 0或& 0xFF是必须的预处理 - 十六进制两位补零不能靠
padStart——它创建新字符串，破坏性能优势；得用查表或位移+掩码组合生成单字节 hex 字符 - 最终结果是 6 位十六进制，本质是把三个 8 位数打包成一个 24 位整数再格式化，而非逐通道操作
用位运算打包 RGB 并转成 6 位 hex 字符串
最简可行的高性能路径：先合成一个 24 位整数，再一次性转 hex 并补零。关键不是“每个通道单独位运算”，而是减少字符串操作次数和中间对象。
正确做法：
function rgbToHex(r, g, b) {
// 确保输入是 0–255 整数
r = (r & 0xFF);
g = (g & 0xFF);
b = (b & 0xFF);
// 打包：r
<p>注意：<code>packed.toString(16)</code> 在 <code>packed === 0</code> 时返回 <code>"0"</code>，所以 <code>padStart(6, '0')</code> 不可省；若追求零分配，可用查表法替代 <code>padStart</code>，但对绝大多数场景得不偿失。</p>
<h3>查表法绕过 toString(16) —— 真正的零开销路径</h3>
<p>当你要在循环中每秒转换数万次 RGB 值，且已确认输入严格在 0–255，查表法是唯一能稳定压倒 <code>toString(16)</code> 的方案。原理：预先生成长度为 256 的 hex 字符串数组，索引即数值，查表即得两位 hex。</p>
- 构建表：
const HEX2 = Array.from({length: 256}, (_, i) => i.toString(16).padStart(2, '0'))（仅执行一次） - 转换函数：
return '#' + HEX2[r] + HEX2[g] + HEX2[b] - 比位运算打包 +
toString(16)快约 20–30%，因为完全规避了数字→字符串的解析逻辑 - 内存代价极小（256 × 2 字符 ≈ 512 字节），且所有主流引擎都会将
HEX2内联优化
常见错误：用位运算硬拆字节却忽略符号扩展
有人尝试这样还原：(color >> 16) & 0xFF 提取 R，但若 color 来自 parseInt(hex, 16) 且未做无符号处理，在某些引擎中可能被当作有符号 32 位整数，导致高位为 1 时 >> 16 带来符号扩展错误（例如 0xFF0000 变成 0xFFFFFFFF）。
安全写法永远带 >> 0 或 & 0xFFFFFF 截断：
// 错误（可能溢出） const r = (color >> 16) & 0xFF; // 正确（确保是 24 位无符号） const r = (color >> 16) & 0xFF; const g = (color >> 8) & 0xFF; const b = color & 0xFF;
更稳妥的是一开始就用 color >>> 0 归一化，尤其当你从 CSS getComputedStyle 或 canvas getImageData 拿到的值可能带符号时。
位运算本身不慢，慢的是想当然地跳过数据校验和类型归一化。真正影响性能的从来不是 | 和 ，而是隐式转换、临时字符串、以及你以为“高级”实则多余的操作。
