Go go-colorful 颜色距离为何不同于RGB分量差

因为“颜色距离”必须先选定颜色空间和距离公式。go-colorful的 DistanceRgb 是RGB分量的欧氏距离，DistanceLab 先转换到Lab再计算距离，DistanceCIEDE2000 使用另一套感知色差公式。它们不是同一数字的不同写法，排序和阈值也可能不同。

比如从一组配色里挑最接近的替代色，直接相加RGB绝对差，和调用库的感知色差方法，可能给出不同候选。先明确比较目标，再选算法，比把所有结果都叫“色差”更容易排查。下文固定v1.2.0接口和实现作为示例依据，不将该标签称为最新版。

项目官方仓库：https://github.com/lucasb-eyer/go-colorful

RGB差与感知色差回答的是同一个问题吗

RGB分量差比较的是表示坐标的变化，不能直接当成人眼感知变化的均匀刻度。即使都叫RGB差，也可能分别指绝对差之和、欧氏距离或最大通道差；先对齐公式，才能比较结果。

库中的DistanceRgb使用平方和开方；DistanceLab使用Lab转换后的分量；CIEDE2000还包含针对亮度、彩度与色相关系的权重调整。因此，从一种方法切到另一种，不应该期待数值相等。依据：固定版本的距离方法实现。

怎样对同一对颜色做可解释的比较

先用Hex解析两个有效的sRGB颜色，再分别打印方法结果，不预设一个“通用合格阈值”。下面程序同时包含最近候选色的选择，输入颜色与候选列表均为本次原创示例。命令和代码供读者运行，本文未实际执行。

# 新建示例目录初始化；已有模块不重复执行
go mod init example.com/colordistance
# 固定本文源码依据对应版本
go get github.com/lucasb-eyer/go-colorful@v1.2.0
# 保存下方main.go后运行
go run .

package main

import (
    "fmt"
    "log"
    "math"

    colorful "github.com/lucasb-eyer/go-colorful"
)

func main() {
    // Hex按库约定解析sRGB，避免把0到255直接写进Color。
    target, err := colorful.Hex("#4F768C")
    if err != nil {
        log.Fatal(err)
    }
    candidate, err := colorful.Hex("#577A86")
    if err != nil {
        log.Fatal(err)
    }

    rgbDistance := target.DistanceRgb(candidate)
    labDistance := target.DistanceLab(candidate)
    de2000 := target.DistanceCIEDE2000(candidate)
    fmt.Printf("RGB=%.6f Lab=%.6f CIEDE2000=%.6f\n",
        rgbDistance, labDistance, de2000)
    // v1.2.0的CIEDE2000返回值乘100才对应常见未缩放数值。
    fmt.Printf("CIEDE2000常见尺度=%.4f\n", de2000*100)

    palette := []string{"#376D8A", "#66808C", "#5B6B7A"}
    bestIndex, bestDistance := -1, math.Inf(1)
    for i, text := range palette {
        c, err := colorful.Hex(text)
        if err != nil {
            log.Fatalf("候选%d无法解析: %v", i, err)
        }
        // 整个候选集始终使用同一算法、同一尺度。
        distance := target.DistanceCIEDE2000(c)
        if distance 

运行时应得到各方法的数值与按CIEDE2000选出的候选。它们是供读者观察的结果，本文不填入未经执行的浮点输出，也不预先宣布哪个候选必然更符合所有人的视觉判断。库的API与颜色表示约定可参阅go-colorful包文档。

为什么数值小了很多：先看输入和尺度

colorful.Color 的R、G、B使用0到1的sRGB数值，而不是0到255。如果已有8位通道，应先除以255，或者使用Hex解析。把原始整数直接放进去，会让后续转换偏离有效输入。

另一个容易混淆的点是返回值缩放。本文固定版本的CIEDE2000实现，先把库内部Lab坐标放大参与公式，最后将结果乘0.01。因此与常见未缩放Delta E 2000数值对照时，可将该方法返回值乘100；不要把外部文章里的阈值原样用于这里。这个换算针对本文所述实现，不是对任意颜色库的规则。

缩放不是“少算了颜色差”，而是数值约定不同。改变RGB输入范围、换公式、改变结果尺度是三件独立的事情，应分开处理。

算法和尺度要与阈值一起保存

上面的Hex输入和候选色集合，始终交给同一个距离算法。最近色排序只比较同一种度量，业务阈值则应跟随相同数值尺度。不要用RGB算法筛出“近邻”，却在没有说明的情况下用它的数值去判断CIEDE2000阈值。

业务记录可以同时保存算法名称、库版本、阈值尺度和输入颜色约定。选择阈值时，收集真实场景里“可接受”和“不可接受”的颜色对，再在同一处理条件下确定分界；不要把一个数字描述成适合所有屏幕、材质与用途的标准。

换方法前还要排除哪些误区

• 输入色彩空间不一致：示例把Hex按sRGB解释。其他来源的颜色需先明确其色彩空间，不能只因为同样有三个分量就直接比较。
• 透明度与背景未固定：Color只保存RGB三分量。比较半透明素材时，应先决定比较原始颜色还是在指定背景上的合成结果；不先规定背景，视觉相似没有唯一答案。
• 把色差当成文字对比度：色差小或大都不能直接代替可读性标准。选择文字与背景应使用相应的对比度规则。
• 把模型当成显示器测量：距离方法对数值进行计算，不会测量读者的显示器、环境光或印刷材料。

这些边界不意味着感知色差没有用，而是要求输入与目的明确。若只比较RGB数值本身，DistanceRgb有直接含义；若想做视觉近似选择，Lab或CIEDE2000更贴近这个目标，仍需结合使用场景评估。

常见问题

DistanceRgb和手算结果不同，一定是库有错吗？

先对齐0到1输入范围，以及是否使用平方和开方。绝对差之和与欧氏距离本来就不是一回事。

距离一定在0到1之间吗？

不要把它当成统一归一化分数。即使输入通道在0到1，RGB欧氏距离也可能大于1；其他方法有自己的定义和尺度。

换成CIEDE2000后，旧阈值还能沿用吗？

应重新确认。算法与数值约定改变后，保留旧阈值可能让筛选过松或过严；先用同一组业务样例对照，再决定是否调整。