企业官网建设流程全解析

这次我们来看一个很典型的 Python 图色实战题目：怎么用条件运算符，在“不使用大漠插件”的前提下，面向游戏窗口截图做颜色状态识别，再配合多线程把监控逻辑跑起来。标题里的演示对象是《永恒之塔》塔2某岛地图，但这篇文章的重点并不在具体打怪或寻路，而是把一套可以复用的 Python 图色代码思路沉淀下来：截窗口、找颜色、算比例、用条件运算符做状态分支、用 threading 同时处理截图与日志。

先说结论，这个项目属于“零基础到实战”教程系列中的第 1.10 节，前面如果已经掌握 Python 基础语法、Pillow 基本操作和 window 窗口枚举，那么这一节可以轻松跟完。本节最关键的三件事是：第一，用纯 Python 方案替代大漠插件完成“区域截屏与颜色匹配”；第二，理解条件运算符在图色状态判断里的正确写法与容易踩的坑；第三，把单线程识别改成多线程监控，验证 Event、Lock、共享字典这些并发工具在真实截图场景中的表现。

需要提前说明的是，游戏自动化有明确的使用边界。本文只做“窗口截图 + 颜色统计 + 状态输出”，不提供任何后台绑定、自动战斗、绕过反作弊机制的实现。如果要把这套代码用在在线游戏环境中，请先确认是否符合游戏用户协议和相关法规，否则只能用于本地 UI 自动化学习、自动化测试或自建训练环境。这一点会在后面单独展开。

1. 核心能力速览与技术选型

在动手之前，先用一张表把项目基本情况说清楚。这样你看完就知道这一节要不要继续跟。

从项目标题可以推断，作者强调“非大漠插件”，说明这个系列并不打算依赖付费组件或第三方图色 DLL。大漠插件在旧版图色脚本里确实很常见，很多老教程会直接用 Dm.FindColor、Dm.GetColor 这类接口，但它的免费版有功能限制，商业版需要授权，而且实现原理偏黑盒，并不适合零基础学习者建立图色识别的底层认知。

换成 Pillow + numpy 之后，图色识别的逻辑变得透明：我们能看到截图数据是一张 RGB 图像，找色本质是在二维像素数组里做数值匹配，条件运算符负责把匹配结果转成业务状态。这种思路换到任何窗口、任何 UI 控件、任何自动化测试项目里都能复用。缺点是纯 Python 截图方案很难处理 DirectX 或硬件加速渲染的游戏后台窗口，这一点后面会重点讲。

2. 环境准备与依赖安装

这一节我们先把运行环境准备好。本机需要安装 Python，然后安装四个库：Pillow 负责截图和图像读取，numpy 负责像素批量计算，pywin32 负责枚举窗口和获取窗口矩形，opencv-python 是可选的，如果后续要做“找图”模板匹配，可以一并装上。

在命令行中执行：

pip install pillow numpy pywin32 opencv-python

如果命令行提示 pip 不是内部命令，说明 Python 没有加入 PATH，需要重新运行 Python 安装包勾选“Add Python to PATH”，或者使用python -m pip：

python -m pip install pillow numpy pywin32 opencv-python

安装完成后，检查 Pillow 和 numpy 是否能正常导入：

python -c "from PIL import Image; import numpy; print('ok')"

Windows 高分屏也要处理。很多程序在 DPI 缩放不是 100% 时，win32gui 拿到的窗口坐标和 ImageGrab 截到的图像会产生偏移，截出来的区域会错位。所以在做窗口截图之前，建议把当前进程设为 DPI 感知。

在 Python 脚本顶部写入：

import ctypes try: ctypes.windll.shcore.SetProcessDpiAwareness(1) except Exception: ctypes.windll.user32.SetProcessDPIAware()

需要注意，这段代码必须在创建任何窗口和截图之前执行，并且只在 Windows 上有意义。如果你运行的是普通桌面应用或者远程桌面，DPI 设置还可能不一样，截图前最好先用一个小程序把目标窗口的坐标打印出来确认。

3. 不用大漠也能做图色：截屏、找色、区域统计

大漠插件被很多老脚本使用，是因为它把“截屏、找色、找图、OCR、绑定窗口”等能力打包成一个 DLL，调用简单。但它的缺点也很明显：不同版本兼容性差异大，在 Win10/Win11 下经常出现绑定窗口失败；免费版本功能受限；部分安全软件会把它当作潜在风险程序处理。

换成 Python 原生方案之后，我们要自己完成三件事。

3.1 获取指定窗口的客户区坐标

图色脚本最常见的操作是绑定一个窗口，然后只截取窗口内部区域。不使用大漠时，我们可以通过 win32gui 找到窗口句柄，再转换成屏幕坐标。

下面的函数先获取当前前台窗口的客户区矩形，再通过 ClientToScreen 把客户区坐标转换成屏幕坐标：

import win32gui def get_foreground_client_bbox(): hwnd = win32gui.GetForegroundWindow() if hwnd == 0: raise RuntimeError("没有获取到前台窗口") # GetClientRect 返回的是客户区左上角(0,0)到右下角的相对坐标 left, top, right, bottom = win32gui.GetClientRect(hwnd) # 把客户区左上角和右下角转换成屏幕坐标 left, top = win32gui.ClientToScreen(hwnd, (left, top)) right, bottom = win32gui.ClientToScreen(hwnd, (right, bottom)) return hwnd, (left, top, right, bottom)

这里的核心是理解 Windows 的坐标体系：GetWindowRect 返回的是整个窗口在屏幕上的矩形，包括标题栏和边框；GetClientRect 返回的是绘图区域的大小，不包括标题栏和边框。如果截图只需要客户区，就必须用 ClientToScreen 换算。

如果目标窗口没有出现在前台，我们也可以先枚举所有窗口，再按标题匹配：

import win32gui def find_window_by_title(title_part: str): result = [] def callback(hwnd, extra): if win32gui.IsWindowVisible(hwnd): title = win32gui.GetWindowText(hwnd) if title_part.lower() in title.lower(): result.append(hwnd) win32gui.EnumWindows(callback, None) return result

用标题匹配窗口时，不要只匹配一次，因为同名窗口可能有多个。图色脚本更稳妥的做法是先让用户拖拽选择窗口，或者列出候选窗口列表，再让用户指定其中一个。本节为了保持代码简洁，采用前台窗口作为默认演示对象。

3.2 用 ImageGrab 截取窗口区域

拿到窗口矩形之后，可以直接调用 ImageGrab.grab 截图：

from PIL import ImageGrab def capture_client_region(): hwnd, bbox = get_foreground_client_bbox() img = ImageGrab.grab(bbox=bbox).convert("RGB") return hwnd, img

ImageGrab.grab 的 bbox 参数必须接收屏幕坐标，并且这个窗口必须处于可见状态。如果窗口被其他窗口完全遮挡、最小化或处于 DirectX 独占全屏模式，ImageGrab 通常只能截到其他窗口或空白内容，这是不依赖大漠做“后台截图”的首要限制。

对于常见桌面程序、窗口化游戏和 UI 自动化测试，只要窗口保持在前台，这种截图方案就足够稳定。如果确实需要后台截图并且目标程序使用普通 GDI 绘制，后续可以尝试 win32ui 配合 CreateCompatibleDC 的方案，但复杂度明显更高，放在后续章节再展开。

3.3 用 numpy 做颜色匹配

对图色脚本来说，“找色”并不是把每个像素用 for 循环遍历一遍，尤其是截图区域有几十万像素时，Python 纯循环会很慢。更高效的做法是把图片转成 numpy 数组，然后用向量化运算统计颜色。

下面的函数会统计一张截图里接近指定颜色的像素数量：

import numpy as np def count_near_color(img, target_color, tolerance=30): """ img: PIL Image 对象，RGB 模式 target_color: (r, g, b) 元组 tolerance: 每个通道允许的误差 """ arr = np.array(img).astype(np.int16) target = np.array(target_color, dtype=np.int16) diff = np.abs(arr - target) mask = ( (diff[:, :, 0] <= tolerance) & (diff[:, :, 1] <= tolerance) & (diff[:, :, 2] <= tolerance) ) return int(mask.sum())

这里用 int16 是为了防止做减法时出现负数溢出。如果 arr 是 uint8，减去一个较大的 target 值可能变成很大的正数，导致 abs 判断失效。

“找色”在实际项目里经常不是只找一个点，而是找一条状态条的占比。例如一个血量条由左到右从空到满，满了之后红色区域占 80%，残血时红色区域只占 10%。通过统计红色像素数量占区域总像素数量的比例，就能判断当前状态。

区域统计代码如下：

def count_color_ratio(img, target_color, tolerance=30): arr = np.array(img).astype(np.int16) target = np.array(target_color, dtype=np.int16) diff = np.abs(arr - target) mask = ( (diff[:, :, 0] <= tolerance) & (diff[:, :, 1] <= tolerance) & (diff[:, :, 2] <= tolerance) ) total = img.size[0] * img.size[1] return int(mask.sum()) / total

4. 条件运算符的图色写法与易错点

基础图色函数已经准备好，接下来看这一节的主角：条件运算符。

4.1 条件运算符基础语法

Python 的条件运算符也叫三元表达式，语法为：

值1 if 条件 else 值2

执行逻辑是：条件成立时整个表达式取值 1，条件不成立时取值 2。

在图色项目中，最常见的是把识别结果转成状态字符串。例如统计到血条区域红色像素比例超过 0.1，就认为需要危险提示：

danger_ratio = 0.15 status = "danger" if danger_ratio > 0.1 else "safe" print(status)

4.2 用条件运算符压缩多状态分支

条件运算符可以嵌套使用，用于处理多状态。图色脚本经常会遇到类似逻辑：红色比例高是“危险”，蓝色比例高是“警告”，绿色比例高是“安全”。

嵌套写法如下：

def decide_status(red_ratio, blue_ratio, green_ratio): return ( "danger" if red_ratio > 0.1 else "warning" if blue_ratio > 0.1 else "safe" if green_ratio > 0.1 else "unknown" )

这个写法可以运行，但可读性一般。如果状态分支超过三层，更推荐用判断表或 if/elif 结构，而不是强行嵌套。条件运算符适合“二选一”或“三选一”的场景，超过三个状态时，代码维护成本会明显上升。

4.3 图色脚本里常见的错误写法

初学者在写图色脚本时，容易把条件运算符写成传统的condition and a or b，这是历史遗留写法。在 Python 2 时代，因为缺少三元表达式，有人会用a and b or c来模拟，但当 b 是 0、空字符串、空列表等假值时，结果会出错。

例如：

hp_ratio = 0.0 action = (hp_ratio > 0.1) and "喝药" or "正常输出" print(action) # 正常输出

这段代码在 hp_ratio 小于 0.1 时会得到“正常输出”，看似没问题。但如果把两个分支对调：

action = (hp_ratio <= 0.1) and "喝药" or "正常输出" print(action)

当第二个分支是空字符串或其他假值时，逻辑就会出错。所以图色状态判断不要使用and/or组合冒充条件运算符，直接写a if condition else b。

另一个容易错的是条件优先级。条件运算符的优先级非常低，如果和比较运算符混在一起，最好用括号包裹：

status = ("danger" if red_ratio > 0.1 else "safe") + "_" + str(int(red_ratio * 100))

不包裹时，字符串拼接的优先级会先执行，导致状态判断结果和后面的内容拼接到一起，运行结果可能变成0_danger，并不符合直觉。

5. 实战一：单线程窗口状态颜色监控

前面内容偏基础，现在写一个完整可运行的单线程版本。这个程序会每 0.5 秒截取一次当前前台窗口客户区左上角的 200x10 区域，统计红色、绿色、蓝色像素占比，并用条件运算符输出当前状态。

先看完整代码：

import ctypes import time import numpy as np import win32gui from PIL import ImageGrab ctypes.windll.shcore.SetProcessDpiAwareness(1) REGION_WIDTH = 200 REGION_HEIGHT = 10 RED = (40, 40, 240) GREEN = (30, 220, 80) BLUE = (30, 180, 230) def get_foreground_client_bbox(): hwnd = win32gui.GetForegroundWindow() if hwnd == 0: raise RuntimeError("没有获取到前台窗口") left, top, right, bottom = win32gui.GetClientRect(hwnd) left, top = win32gui.ClientToScreen(hwnd, (left, top)) right, bottom = win32gui.ClientToScreen(hwnd, (right, bottom)) return hwnd, (left, top, right, bottom) def count_near_color(img, target_color, tolerance=30): arr = np.array(img).astype(np.int16) target = np.array(target_color, dtype=np.int16) diff = np.abs(arr - target) mask = ( (diff[:, :, 0] <= tolerance) & (diff[:, :, 1] <= tolerance) & (diff[:, :, 2] <= tolerance) ) return int(mask.sum()) def analyze_foreground_status(): hwnd, bbox = get_foreground_client_bbox() img = ImageGrab.grab(bbox=bbox).convert("RGB") # 在客户区左上角截取一小块区域作为测试条 test_region = img.crop((0, 0, REGION_WIDTH, REGION_HEIGHT)) total = REGION_WIDTH * REGION_HEIGHT red_ratio = count_near_color(test_region, RED) / total green_ratio = count_near_color(test_region, GREEN) / total blue_ratio = count_near_color(test_region, BLUE) / total return red_ratio, green_ratio, blue_ratio def decide_status(red_ratio, green_ratio, blue_ratio): return ( "danger" if red_ratio > 0.1 else "warning" if blue_ratio > 0.1 else "safe" if green_ratio > 0.1 else "unknown" ) if __name__ == "__main__": for i in range(10): red, green, blue = analyze_foreground_status() status = decide_status(red, green, blue) print( f"[{i}] red={red:.2f} green={green:.2f} blue={blue:.2f} status={status}", flush=True, ) time.sleep(0.5)

这段代码没有做任何后台绑定，也没有模拟键鼠操作，只是一个前台窗口颜色采样器。运行后，把目标窗口切换到前台，比如打开一个显示红、绿、蓝状态条的窗口或测试页面，控制台会持续输出颜色占比和状态。

验证时可以先打开一个窗口，把目标区域左上角故意显示成接近红色，观察输出是否从 safe 变成 danger。如果一直是 unknown，说明截取到的区域颜色和三种预设颜色都不接近，可以通过打印某个像素值来调试：

print(np.array(test_region)[0, 0])

运行到这里，可以发现这个思路本质上并不复杂：截图数据是数组，颜色判断是数组统计，条件运算符负责把统计结果映射成业务状态。真正的难点在于窗口区域定位、颜色阈值调整和多线程状态同步。

6. 实战二：多线程截图与状态消费

单线程版本里，截图、颜色统计、打印输出都在同一个循环中完成。如果颜色统计耗时长，打印和状态展示就会被阻塞。为了模拟真实的“边截图、边读取状态”场景，下面引入 threading。

多线程版本设计如下：一个线程专门负责截图和颜色统计，另一个线程负责读取共享状态并打印日志，主线程负责控制程序运行时长和退出。

这里使用 threading.Event 作为停止信号，使用 threading.Lock 保护共享字典。因为 ImageGrab 和 win32gui 的调用要在同一个线程里串行执行，避免多个线程同时调用 Windows GDI 接口引发不稳定，所以这里只有 capture_worker 线程会操作句柄和截图。

完整代码：

import ctypes import threading import time import numpy as np import win32gui from PIL import ImageGrab ctypes.windll.shcore.SetProcessDpiAwareness(1) REGION_WIDTH = 200 REGION_HEIGHT = 10 RED = (40, 40, 240) GREEN = (30, 220, 80) BLUE = (30, 180, 230) def get_foreground_client_bbox(): hwnd = win32gui.GetForegroundWindow() if hwnd == 0: raise RuntimeError("没有获取到前台窗口") left, top, right, bottom = win32gui.GetClientRect(hwnd) left, top = win32gui.ClientToScreen(hwnd, (left, top)) right, bottom = win32gui.ClientToScreen(hwnd, (right, bottom)) return hwnd, (left, top, right, bottom) def count_near_color(img, target_color, tolerance=30): arr = np.array(img).astype(np.int16) target = np.array(target_color, dtype=np.int16) diff = np.abs(arr - target) mask = ( (diff[:, :, 0] <= tolerance) & (diff[:, :, 1] <= tolerance) & (diff[:, :, 2] <= tolerance) ) return int(mask.sum()) def decide_status(red_ratio, green_ratio, blue_ratio): return ( "danger" if red_ratio > 0.1 else "warning" if blue_ratio > 0.1 else "safe" if green_ratio > 0.1 else "unknown" ) def capture_worker(stop_event, shared_state, state_lock, interval=1.0): while not stop_event.is_set(): try: hwnd, bbox = get_foreground_client_bbox() img = ImageGrab.grab(bbox=bbox).convert("RGB") test_region = img.crop((0, 0, REGION_WIDTH, REGION_HEIGHT)) total = REGION_WIDTH * REGION_HEIGHT red_ratio = count_near_color(test_region, RED) / total green_ratio = count_near_color(test_region, GREEN) / total blue_ratio = count_near_color(test_region, BLUE) / total status = decide_status(red_ratio, green_ratio, blue_ratio) with state_lock: shared_state["red_ratio"] = red_ratio shared_state["green_ratio"] = green_ratio shared_state["blue_ratio"] = blue_ratio shared_state["status"] = status shared_state["last_update"] = time.time() shared_state["error"] = None except Exception as exc: with state_lock: shared_state["error"] = str(exc) time.sleep(interval) def log_worker(stop_event, shared_state, state_lock): while not stop_event.is_set(): with state_lock: if shared_state.get("error"): print("error:", shared_state["error"], flush=True) else: print( "status=", shared_state.get("status"), "red=", round(shared_state.get("red_ratio", 0), 2), "green=", round(shared_state.get("green_ratio", 0), 2), "blue=", round(shared_state.get("blue_ratio", 0), 2), flush=True, ) time.sleep(0.5) if __name__ == "__main__": stop_event = threading.Event() state_lock = threading.Lock() shared_state = {"status": "unknown", "last_update": 0.0} t1 = threading.Thread( target=capture_worker, args=(stop_event, shared_state, state_lock, 1.0), daemon=True, ) t2 = threading.Thread( target=log_worker, args=(stop_event, shared_state, state_lock), daemon=True, ) t1.start() t2.start() try: time.sleep(10) finally: stop_event.set() t1.join(timeout=3) t2.join(timeout=1) print("已停止")

运行这个程序会出现两个输出规律不同的事件流：capture_worker 每 1 秒刷新一次共享状态，log_worker 每 0.5 秒读一次并打印。即使某个时刻截图耗时变长，log_worker 也不会被截图过程卡住，因为它读取的是上一次截图完成后保存的状态。

多线程方案的核心收益是“职责分离”。截图线程只关心画面采集和颜色统计，日志线程只关心状态展示，主线程负责整体退出。后续如果要把状态写到队列、写到数据库或者通过 HTTP 接口暴露，只需要再加一个消费线程即可，不需要改动截图逻辑。

但也要注意，多线程不是只有好处。共享状态如果不上锁，多个线程同时读写字典时可能读到半个写操作的结果。日志线程如果负责动作执行，而动作执行本身需要窗口在前台，那么不同线程抢窗口焦点会产生严重冲突。这里建议在图色脚本中用 Windows 消息或队列机制串行化所有需要操作窗口的动作，不要在多个线程里同时调用前台键盘鼠标操作。

7. 资源占用、常见问题与排查方法

图色脚本除了看功能能不能跑通，还要看资源占用是否可控，以及出问题时怎么定位。

7.1 截图频率和 CPU 占用

ImageGrab.grab 在每次调用时都会从屏幕读取整块像素，截图区域越大，耗时越长。本节代码只截取前台窗口客户区的一部分，实际 CPU 占用会明显低于全屏 1080p 截图。但不同机器性能差异很大，并不能给一个通用数字。

更稳妥的判断方法是先提高循环间隔。第一次测试时把 interval 设为 2 秒或 3 秒，观察 CPU 占用和输出是否连贯。如果程序长时间运行仍然稳定，再逐步缩短间隔。颜色统计使用 numpy 向量化后，耗时主要集中在图片截取和 RGB 转换，而不是 for 循环遍历。

如果需要进一步降低占用，可以限制识别区域，不要在整张窗口上做颜色统计。比如血条只出现在固定坐标区域，就只截那个区域。截图前先确认区域大小，比截图后裁剪更高效。

7.2 常见问题排查

下面是本节代码运行中比较容易遇到的问题以及排查思路：

图色脚本里最值得重视的是“窗口后台截图”的边界。ImageGrab 依赖 Windows GDI 从屏幕画面取数据，对许多现代游戏和硬件加速渲染的窗口，前台窗口可能没问题，但后台窗口大概率截不到真实画面。有些游戏还会使用反作弊保护，禁止外部程序读取窗口绘制内容。遇到这种情况，不建议继续尝试做后台绑定，因为除了技术难度高，还可能违反软件使用协议。

7.3 批量监控区域的扩展思路

本节代码只监控了一个 200x10 的区域。实际项目里，一个窗口可能同时有血量、蓝量、目标状态等多个颜色区域。批量处理时，不要为每个区域各开一个截图线程，因为多个 ImageGrab 并发执行会重复占用 GDI，反而更慢。

更合理的方案是把所有监控区域配置成一个列表：

monitor_regions = [ { "name": "hp_bar", "rect": (0, 0, 200, 10), "target_color": (40, 40, 240), "threshold": 0.1, }, { "name": "mp_bar", "rect": (0, 15, 200, 10), "target_color": (30, 180, 230), "threshold": 0.1, }, ]

截图线程只截一次整个窗口，然后根据配置项分别裁出不同区域做统计。这样可以显著减少截图次数，颜色统计也能并发执行。虽然 Python 的 GIL 会影响纯计算线程的真实并行，但由于 numpy 底层会释放 GIL，多个 numpy 统计任务在适当拆分后仍能获得一定加速。

8. 合规使用边界与最佳实践

图色脚本是一个非常敏感的技术方向，因为同样一套代码，用在自动化测试里是效率工具，用在在线游戏里就是外挂脚本。本文给出的所有示例只完成了“读取颜色状态”这一层，没有编写自动键鼠动作，也没有尝试绕过硬件的窗口绑定限制。

如果你是在学习 Python 图色，最安全的练手窗口是记事本、浏览器页面或自建的 PyQt 测试程序。只要窗口里能渲染出不同颜色的区域，就能验证截图、找色、条件运算符和多线程逻辑，不需要真的打开游戏。等代码逻辑稳定后，再决定是否把识别结果接入自己的合法 UI 测试流程。

对于在线游戏，我建议直接认定为高风险场景。原因有两个：第一，多数游戏用户协议明确禁止使用第三方工具执行自动操作；第二，使用按键模拟或内存读取可能违反平台规则，甚至带来账号安全风险。本文不提供任何绕过游戏保护机制的内容，也不鼓励读者把“多线程非大漠插件”理解成用来做自动战斗的高可用外挂方案。

工程实践上，图色脚本项目应该遵守几个基本原则：识别和动作分离，截图线程只负责状态分析，动作执行必须独立排队并经过人工确认；权限最小化，只截图和保存日志，不读取与业务无关的数据；保留审计日志，每一次识别结果和动作来源都要可追溯；定期检查道德边界，不要把图色能力用于未经授权的人脸识别、验证码绕过、批量注册或侵犯他人隐私的活动。

如果要把这套代码接入自动化测试平台，建议再加上日志文件输出、异常重试、配置文件隔离。代码里的窗口标题、监控区域、阈值颜色都不应该硬编码在函数里，而是放到配置文件或命令行参数里，便于不同环境下切换。

9. 总结与下一步

这一节从零写完了两个版本：单线程窗口颜色监控和多线程截图状态消费。核心收获有三个：一是知道不用大漠插件也能做图色识别，底层就是“截屏 + numpy 数组统计 + 条件运算符判断”；二是熟悉了条件运算符在 Python 里的正确写法，避免使用 and/or 这种历史遗留写法导致逻辑出错；三是理解了 threading 中 Event 和 Lock 怎么配合，保证共享状态在截图线程和日志线程之间安全传递。

如果你准备继续深入这个系列，下一步最值得验证的是两件事：第一，把颜色统计改成“区域平均颜色”或“模板匹配找图”，让识别不再依赖固定的 RGB 阈值；第二，把共享状态从普通字典换成 queue.Queue，让截图线程产生的状态变更按顺序进入队列，日志或动作线程按队列消费。这样能解决更复杂的“多监控点 + 多动作”任务调度问题。

最容易踩的坑是随意缩短截图间隔。刚跑通代码时，建议先从 1 秒到 2 秒间隔开始，确认 CPU 占用可接受后再逐步提高频率。不要在没做区域裁剪的情况下把整块屏幕都读进来，否则后面加再多颜色逻辑也容易卡在截图这一环。

建议把本文代码保存成一个screen_color_monitor.py文件，同时写好注释和区域配置，后续加入更多监控项时只需要修改配置，不必反复重写线程逻辑。然后尝试用自建测试窗口做一次完整的“颜色变化识别”实验，确认多线程能够及时反应。跑通之后再谈扩展。