IE兼容下按钮:active失效？用选择器前缀和条件注释彻底解决
2026/9/14 4:25:06
C语言鼠标RGB取色源码这段代码，最容易翻车的地方不在 GetCursorPos 拿坐标，也不在 GetPixel 拿颜色，而在最后那段 rgb2hsv：HSV 的色相是一个角度，红、绿、蓝三个分支里只要有一个边界写错，同一种颜色就能算出两个相差很大的 H 值。这种 C 语言颜色转换逻辑要验证，直接看代码比跑程序更快。我习惯把 Codex 接到 TaoToken 上做静态审查，Key 先去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 拿，让 Codex 走的 Base URL 填成 https://taotoken.net/api。接下来用几组已知 RGB 值逼着 Codex 一步一步算，把边界问题挑出来。
1. 从 GetCursorPos 到 rgb2hsv：颜色值拆出来了，色相却没想象中好算
1.1 原分享里那段主流程：取坐标、取像素、拆通道
原文这段代码做的事情一句话能说清：循环里先 GetCursorPos 拿鼠标坐标，再用 GetPixel 从整个屏幕的设备上下文里读那个点的 COLORREF，紧接着 GetRValue / GetGValue / GetBValue 把颜色拆成 0-255 的 RGB，喂给 rgb2hsv，最后用 printf 的 \r 原地刷新一行字。主循环里还有两个细节值得注意：一是按 ESC 退出用 GetAsyncKeyState(VK_ESCAPE) 判断，不需要额外做按键处理；二是 Sleep(50) 把刷新频率压到 20fps 左右，避免整颗 CPU 被这个取色循环占满。
真正需要跑起来才能发现的小毛病在 Windows 的取色环境本身。如果屏幕被其他窗口挡住，GetPixel 拿到的是挡在前面的窗口像素；如果当前会话是远程桌面或 UAC 安全桌面，GetPixel 可能直接取不到内容。也就是说，程序本身没问题，但“取到的颜色不符合预期”时，先检查的不是 HSV 算法，而是这次取色有没有拿到有效 COLORREF。
1.2 rgb2hsv 的三个分支，才是 HSV 验证的核心
下面这段是原分享 rgb2hsv 的注释重写版，分支逻辑保持一致。我把它单独抽出来，是因为后文要让 Codex 逐行核对的就是这个函数。
void rgb2hsv(int r, int g, int b, float *h, float *s, float *v) { float rf = r / 255.0f; float gf = g / 255.0f; float bf = b / 255.0f; float max_val = fmaxf(rf, fmaxf(gf, bf)); // 三通道里的最大值 float min_val = fminf(rf, fminf(gf, bf)); // 三通道里的最小值 float delta = max_val - min_val; *v = max_val; // V 就是最大值 *s = (max_val == 0) ? 0 : delta / max_val; // S 是极差占最大值的比例 *h = 0; if (delta != 0) { if (max_val == rf) { *h = (gf - bf) / delta; // 红色扇区 if (*h < 0) *h += 6; // 负角度回绕 } else if (max_val == gf) { *h = (bf - rf) / delta + 2; // 绿色扇区，对应 120° } else { *h = (rf - gf) / delta + 4; // 蓝色扇区，对应 240° } *h *= 60; // 归一化比例换成角度 } }这段函数和原分享的行为一致，但我调整了写法，把红色扇区的负值修正提前到乘 60 之前。原分享用的是 fmodf 和乘法后加 360，这里用 +6 再乘 60 等效；两种写法的目的都是把红色扇区落在负半轴的色相拉回 0°-360° 区间。最容易算错的地方也正是这里：如果只判断了 max_val == rf 就乘 60，忘了处理负值，(gf - bf) / delta 为负时会出现 -30° 这种非法角度；反过来，如果忘了乘 60，红色区域会得到 0 到 1 之间的小数，和绿蓝两个扇区的 120°、240° 完全对不上。另外，绿色扇区为什么 +2？因为色相环里绿色在红色逆时针 120° 的位置，归一化之后就是 2/6 圈；蓝色扇区 +4 同理，是 4/6 圈。把这三句分别乘以 60，其实就是在把色相环切成六段，每段管 60°。
饱和度和明度的计算相对直白，只有两个边界：max_val 为 0 时不能除 0；S 和 V 都以 0-1 的小数返回，主程序打印时乘 100。白色和黑色都会让 delta = 0，于是 H 被置成 0，这个行为本身没问题，但要记得它不是唯一答案——灰色没有色相。知道这一点，后面让 Codex 验证时，就不能只给彩色样本，还要把纯白、纯黑、灰色这些 delta = 0 的边界值放进去。
2. 给 Codex 配一条统一 API 通道：先拿 Key 再改 config.toml
2.1 第一步不是改代码，是去模型广场拿 Key 和模型 ID
要让 Codex 帮你核对这段 C 语言颜色转换逻辑，先得让它能真正发请求。TaoToken 提供的是统一 API 通道，把 Codex 请求转到对应大模型；你要做的第一件事是打开 TaoToken 注册，创建 API Key。Key 创建后通常只显示一次，建议先复制到本地临时文件。同时去模型广场记下你要用的模型 ID，后面 config.toml 里要用。这里有两个地址容易混：
- 浏览器里注册、建 Key、看模型广场、看用量，用的是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end
- 填进 Codex 的 Base URL，用的是 https://taotoken.net/api，末尾不要加 /v1。Codex 自己会往这个基础地址上拼路径，多一个 /v1 反而拼错。
2.2 config.toml 只改 model_provider 和 base_url，别带 ANTHROPIC_* 变量
Codex CLI 的配置文件在 ~/.codex/config.toml。打开它，替换成下面这份最小配置：
# ~/.codex/config.toml model = "YOUR_MODEL_ID" # 以模型广场实际显示的 ID 为准 model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY"配置完成后，先向终端导出环境变量，再启动 Codex：
export TAOTOKEN_API_KEY=YOUR_API_KEY codexYOUR_API_KEY 的占位含义是：你从落地页创建的那串 Key，不是拿 email 去登录。env_key 告诉 Codex 从哪个环境变量里读 Key，所以环境变量名必须和这里一致。注意一个容易踩的交叉点：如果你之前给 Claude Code 配过 ANTHROPIC_BASE_URL 或 ANTHROPIC_AUTH_TOKEN，那套变量是 Claude Code 的，和 Codex 无关；Codex 只认 model_provider、base_url、env_key 这三样。如果你用的是 IDE 里的 Codex 插件，不一定会读 config.toml，那就到插件的自定义供应商设置里，分别填 Base URL、API Key、模型 ID 三项，值跟上面完全一样。
与其在多个模型后台各申请一套密钥，不如在 TaoToken 里统一管理，拿到一个 Key 就能在 Codex 里切换模型广场里的不同 ID。后面 HSV 验证要是想换个更擅长数值推理的模型，只改 model 那一行，不需要动 config 的其他部分。
3. 让 Codex 对着测试向量手算 HSV：红色扇区、灰色边界一个都别放过
3.1 先准备一组带“危险值”的测试向量
要把 HSV 换算逻辑验证清楚，不能只测一个纯红色。我建议至少准备下面这几组：
| 输入 RGB | 期望 HSV | 为什么选它 |
|---|---|---|
| (255,0,0) | (0°,100%,100%) | 纯红，色相扇区起点 |
| (0,255,0) | (120°,100%,100%) | 纯绿，验证绿色扇区 +2 |
| (0,0,255) | (240°,100%,100%) | 纯蓝，验证蓝色扇区 +4 |
| (0,255,255) | (180°,100%,100%) | 青色，属于绿色扇区但偏中性 |
| (255,255,255) | (0°,0%,100%) | 白色，delta = 0 边界 |
| (128,128,128) | (0°,0%,50.2%) | 灰色，验证 S=0 不触发除零 |
| (255,128,0) | 约(30°,100%,100%) | 红橙，容易暴露红色扇区负值回绕 |
其中最后一行需要稍微算一下：rf = 1.0，gf ≈ 0.502，bf = 0，delta = 1.0，于是 (gf - bf) / delta ≈ 0.502，乘 60 约等于 30.1°，落在红色与黄色的交界。如果代码在红色扇区里漏掉负值回绕，这一行不会出问题；真正会出问题的是另一个反例：输入 (128,0,255)，rf ≈ 0.502，bf = 1.0，最大值是 bf，走蓝色扇区得到 (rf - gf) / delta + 4 = 0.502 + 4 = 4.502，乘 60 = 270.1°。可如果某版代码把蓝色扇区误写成 +2，就会输出 150.1°，差出一个大格，Codex 一眼就能看出来。我特意把“源代码实现”交给它，而不只是让它直接回答案，目的是让它按你的分支走一遍。
3.2 把函数和测试向量一起给 Codex，让它做静态验算
把上一节的 rgb2hsv 函数、测试向量贴进 Codex，然后用下面这种指令：
“这是一段 C 语言 RGB 转 HSV 的源码。请你不要执行程序，按源码里的分支手算下面几组 RGB 的 HSV 输出，并计算偏差。输出一张表：输入 RGB、期望 HSV、源码计算值、是否一致。重点检查 H 的红色扇区负值修正、绿色扇区 +2、蓝色扇区 +4 以及 delta == 0 时 S 和 H 的处理。如果哪一行和期望值不一样，指出具体在哪一行出错。”
Codex 不会真的跑去编译运行这段 Windows 代码，它能做的是用大模型能力把代码逻辑逐步推导一遍。这正是验证 C 语言颜色转换逻辑时最高效的姿势：不需要为每一次改动准备调试环境，先把静态计算错的地方抓出来。TaoToken 在这里的任务很简单，就是保证 Codex 发出去的请求能被大模型正常响应；请求能通，验证就能继续。若 Codex 返回中断，等几十秒重发一次即可，不用反复重启程序。
3.3 真正取色这一步，还是得在你自己的电脑上跑
Codex 再聪明也不建议让它直接去连你的屏幕和鼠标，毕竟它拿不到 Windows 的桌面上下文。所以本地这份 C 程序要你自己编译运行：
gcc -o rgb2hsv rgb2hsv.c -lm ./rgb2hsv把程序对准屏幕上几个颜色比较纯的位置，记下打印出来的 RGB、HSV。运行结果如果和 Codex 手算表格有出入，把实际输出贴回去，请它对照源码定位。注意这里不是让 Codex 远程操控你的机器，而是由你本地执行后把输出回贴到对话里，它只负责对照逻辑给结论。这条边界隔得清楚，排查起来也更快。
4. 验证对不上、请求报错时，先查 Base URL，再查 GetPixel
4.1 Codex 报错先看这三处，别急着改 C 代码
如果 Codex 一启动就提示 unknown model provider，多半是 ~/.codex/config.toml 里的 [model_providers.taotoken] 块名和 model_provider = "taotoken" 没对上，或者文件保存后 Codex 没重启。如果请求返回 401 Unauthorized，先确认环境变量是否真的导出：终端里执行 echo $TAOTOKEN_API_KEY，能打印出你创建的那串 Key 才算数；不要顺手复制成代码里的 YOUR_API_KEY 占位符。如果返回 404，十有八九是把 Base URL 写成了 https://taotoken.net/api/v1 或 https://taotoken.net/?utm_source=... 这类地址。Codex 会在 base_url 后面再拼自己的路径，v1 和 utm 参数都会让路由找错位置。把 Base URL 改回 https://taotoken.net/api 重启 Codex，这类问题通常立刻消失。
4.2 HSV 全 0 可能不是算法问题，而是 GetPixel 没取到有效像素
程序能编译能跑，但输出一直是 HSV: (0.0°, 0.0%, 0.0%)，这时不要先去怀疑 API 配置，先怀疑 GetPixel 拿到的 COLORREF 是不是 0。常见的触发条件：目标像素被当前窗口挡住、程序跑在安全桌面上、或者通过远程桌面会话取色。处理方法是把 printf 前面临时加一行打印 r/g/b，确认输入 rgb2hsv 的三个分量本身就不为 0；如果 RGB 也是 0，问题出在取色环节，跟 HSV 换算无关。把 RGB 分量贴回给 Codex，它会告诉你哪些场景下 GetPixel 返回无效值，但最终确认还是得在本地会话里做。
4.3 用一次真实调用核对用量，确认这条链路真的通了
以上都能跑通后，回到落地页去看一眼刚才的请求记录。具体路径是打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，登录后在用量页按时间排序，找到对应 Codex 会话的那条请求，确认模型 ID、请求时间和消耗 token 数都对得上。这一步相当于给整条链路盖个章：不是只看 console 不报错，而是确实从 Codex 发到了 API 通道，再由 TaoToken 把请求转给大模型。用量页上能看到这次 HSV 验证对话的上下文长度，以后换其他 C 语言源码让它审查，也能预估大概会吃掉多少 token。
整个流程走完之后你会发现，真正花时间的不是把 Codex 接到 https://taotoken.net/api 这一步，而是把 HSV 的测试向量选到点子上。纯红、纯绿、纯蓝只能证明三个扇区的主路径是通的；多放几组中间色和灰色进去，红色扇区负值回绕、delta == 0 这类隐藏边界才会现形。现在就可以去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建你的 API Key，回 Codex 里把这套 HSV 测试向量跑一遍。等看到表格里每个 RGB 的 H 值都落在预期角度，再回到取色程序里对着屏幕实测一轮，那份颜色监视器才算真正写完。