排查
两个 App 抢同一个显示设置时，会发生什么
亮度自己会变。你设好的颜色，一小时后不对了。设置里什么都没动—— 因为另一件工具正在往同一个地方写，而双方都不知道。
第二个工具可以写的地方不止一处
显示状态不是一个值，而是一组各自独立的领域。每一个都可能被另一个工具悄悄写入： 一个菜单栏 App、一个辅助进程、一段脚本。双方都以为这块归自己管。
识别对方才是难的部分
按显示名称匹配并不可靠。厂商常常同时装一个菜单栏 App 和若干辅助进程， 而辅助进程往往根本没有可用的名字。所以可靠的信号是 bundle identifier 的前缀；对于 bundle id 没有公开文档的工具， 再用精确的本地化名称做第二轮匹配。
为什么「漏掉」比「误报」好
两轮都没匹配上的工具会保持未被发现，这是有意为之： 一条永不触发的警告，好过一条误报到无关进程上的警告。 一条你学会忽略的冲突警告，比没有警告更糟。
该怎么做
- 如果两个 App 都声称管亮度，选一个，关掉另一个。它们之间没有任何仲裁协议—— 后写的赢，而谁在后写取决于时序。
- 去查辅助进程，不要只看菜单栏里那个 App。真正写入的常常是辅助进程。
- 如果漂移发生在唤醒之后或显示器重连之后，那多半不是冲突， 而是一块需要一点时间才能重新应答的面板。
诚实的边界
- 这一页讲的是某一个实现如何发现对手。它不是一个标准， 也看不见 bundle id 和名称都没匹配上的工具。
- 「后写的赢」是描述，不是保证。两个工具交错写入，可能得到一个双方都没想要的状态。