刚开始做RGB控制时，很容易觉得逻辑很简单：
setColor(255, 0, 0)
把颜色发给设备，灯亮了，功能似乎就完成了。
但真正开始做 SyncRGB 后，我们发现更麻烦的问题是：
软件里的状态，和硬件真正执行的状态，不一定是一回事。
比如用户设置了蓝色，但随后设备重新上电、USB断线重连、游戏事件触发，硬件可能已经切到了其他灯效。
这时候系统里其实存在两个状态：
Desired State // 用户希望的状态
Reported State // 设备当前真实状态
如果两者不一致，软件就需要重新同步，而不是简单认为“命令发送成功 = 设置成功”。
多设备以后，问题会更明显
假设一个桌面同时有：
机箱风扇、RGB灯条、灯板和副屏。
用户点击“游戏模式”，背后实际上可能需要同时切换多个设备。
如果其中一个设备掉线，其他设备已经切换成功，那么这个场景到底算成功还是失败？
这时候RGB软件已经不只是一个“灯效播放器”，更像一个：
设备状态编排器。
游戏事件还会带来优先级问题
例如当前正在播放彩虹灯效，游戏突然触发“受到伤害”。
更合理的逻辑应该是：
彩虹灯效
↓
受到伤害 → 红色闪烁
↓
事件结束
↓
恢复彩虹灯效
而不是一次游戏事件就永久覆盖用户原来的设置。
所以系统还需要处理：
默认灯效 → 当前场景 → 实时效果 → 临时游戏事件
之间的优先级。
这也是我们现在做SyncRGB时越来越关注的东西
相比单纯增加更多灯效，我们更关心：
设备能不能正确同步、掉线后能不能恢复、临时事件结束后能不能回到原来的状态。
因为当RGB设备越来越多以后，体验差距可能不在于：
谁有更多彩虹效果。
而在于：
谁更少出现“这个设备怎么又没跟上”的情况。
从这个角度看，RGB控制软件真正要解决的，可能不是“怎么让灯亮”。
而是：
怎么让所有设备一直处于正确的状态。
