主题相关的坑，返回值经常撒谎。先对日志链路，再改资源和布局。

主题相关的坑，返回值经常撒谎。我现在习惯先对三条日志，而不是先改 JSON。这套习惯来自几次「接口成功、用户没看见」的现场：有人已经开始换图、改坐标，日志里其实连 OnThemeChanged 都没有。

第一条看切换。有没有 SwitchSuit，有没有 NotifyAllThemeRoots，每一个根有没有 OnThemeChanged。缺最后一段，根多半没进管理器名单——不是 CreateThemeByKey 创建的，或已经 Destroy 还在切。有切换、解析失败，去读原因：配置打不开、key 不在清单、当前套没有这个页面、ZIP 解不开、目录没权限。这些比布尔值有用。过滤时把套名和 ThemeRoot 一起盯，只看成功两个字很容易放过「通知发出去了、听众是空的」。

第二条看数据。没有 Trigger，查生产者线程在不在、主流程有没有把生产者拉起来。有 Trigger、根收不到，回头看 Start 和回调有没有卸完没挂上。根收到了、控件没 Handle，查 bind_data 和解析有没有把控件丢掉。提示找不到数据源，是适配层没覆盖这种类型，别先怀疑绘制。控件在树上却看不见，把 display_mode、时段、条件可见过一遍，再看缓存有没有把可见性关掉。

第三条看安装和回调卫生。ZIP 要自带中央目录、文件名尽量纯 ASCII，框架自己解压，格式稍野、磁盘满、目录其实是个文件，都会失败。回调里不要死循环、不要再抢同一把非递归锁，套名指针不要存——通知返回后内存可能没了，拷进 string。订阅做一次就够，切忌在回调里再订自己。卡顿优先减嵌套、让缓存干活、别在绘制里做文件；泄漏常见于只建不 Destroy、订了不退订、解析失败路径上 new 了没释放。

三条日志对完，再去怀疑资源和布局，省很多来回。现场可以记成一句话：先确认根还在名单里，再确认 Start 过，再确认绑定类型能路由到数据源。