[code-review] 14 个 IM panel 复发 #2337 live-map len 读：len(m.config.IM.Adapters) 绕过 imAdaptersMu，持锁写并发时 fatal

[topcheer]

文件和行号

同型一行出现在 14 个 IM panel 的 *BindingEntries() 渲染路径（每帧执行）：

• internal/tui/discord_panel.go:418
• internal/tui/dingtalk_panel.go:423
• internal/tui/matrix_panel.go:483
• internal/tui/whatsapp_panel.go:517
• internal/tui/irc_panel.go:456
• internal/tui/feishu_panel.go:446
• internal/tui/slack_panel.go:493
• internal/tui/signal_panel.go:654
• internal/tui/tg_panel.go:400
• internal/tui/mattermost_panel.go:472
• internal/tui/nostr_panel.go:562
• internal/tui/twitch_panel.go:447
• internal/tui/wechat_panel.go:615
• internal/tui/qq_panel.go:449

问题描述

keys := make([]string, 0, len(m.config.IM.Adapters)) 是这些文件中唯一绕过 imAdaptersMu 的 map 读。#2152 建立的契约是所有 IM adapter map 访问走锁访问器（IMSnapshot/GetIMAdapter/IMAdapterEnabled 均为 RLock+深拷贝）。互斥锁对不持锁读者零保护：与任一持锁写（SetIMAdapterEnabled / AddIMAdapter / toggle 等，config_save.go:679-698）交叠时 Go runtime fatal "concurrent map read and map write"，不可恢复，整个 TUI 崩溃。

触发场景

1. 打开任一 IM panel（每帧渲染执行该行）
2. 同时任一 Cmd goroutine 完成一次持锁写（如 im_panel.go toggleIMAdapterEnabled 的 enable/disable 链、或残留的 Cmd goroutine 直调 SetIMAdapterEnabled 的路径）
3. 写入期间恰好帧渲染到该行 → fatal

预期行为 vs 实际行为

• 预期：渲染路径全部走锁访问器
• 实际：len() 直接读活 map；fix(tui): WeCom bind auto-enables instead of leaking the enable sentinel; entries snapshot the adapter map (#2333) #2337 已为 wecom_panel.go 单独修复（wecomBindingEntries 改为 snapAdapters := m.config.IMSnapshot().Adapters 后复用 len），且 zz_issue2333_test.go 的 TestIssue2337EntriesUseSnapshotLen 只扫描 wecom 源文件——同型缺陷在其余 14 个 panel 复发未被拦截

修复建议

每个文件改为先取一次快照复用：snap := m.config.IMSnapshot().Adapters; keys := make([]string, 0, len(snap))（下一行的遍历本来就用 IMSnapshot()，可复用同一变量）。并将 #2337 的源码扫描测试泛化到全部 IM panel 文件，防止再次复发。

严重程度

low~medium（触发窗口窄：需要渲染帧与持锁写精确交叠；但后果是进程 fatal 不可恢复，且面板打开期间渲染每帧都执行该行）

[topcheer]

【认领】复核属实，修复认领（本轮限额 1/2）：

验真（全量扫描实证）：14 个 panel 文件（discord/dingtalk/matrix/whatsapp/irc/feishu/slack/signal/tg/mattermost/nostr/twitch/wechat/qq）各恰好 1 处 make([]string, 0, len(m.config.IM.Adapters)) 直读活 map——#2152 锁访问器契约（IMSnapshot/GetIMAdapter/IMAdapterEnabled）下唯一绕过 imAdaptersMu 的读点；wecom_panel #2337 修复（snapAdapters 快照+复用遍历）注释明证该行曾与持锁写 racing。与 config_save.go 持锁写（SetIMAdapterEnabled 等）交叠时 Go runtime fatal 不可恢复。既有 TestIssue2337EntriesUseSnapshotLen 只扫 wecom——同型未拦截实证。

拟修复：①14 文件对齐 #2337 模式：snapAdapters := m.config.IMSnapshot().Adapters 一次快照，len+遍历复用（顺带消除每帧双快照浪费）；②将 #2337 源码扫描测试泛化到全部 IM panel 文件（含 wecom 共 15），防再复发。

验证计划：泛化扫描探针对 main 的 14 文件 FAIL 钉根因→修复后 PASS；internal/tui 包测回归。

[topcheer]

已修复（分支 fix/issue-2796，FRESH 队列等 PR 窗口，暂不关闭）。

根因：#2337 修 wecom 单文件时其扫描测试（TestIssue2337EntriesUseSnapshotLen）只覆盖 wecom_panel.go——同型 len(m.config.IM.Adapters) 活 map 直读在其余 14 个 panel 的 BindingEntries 渲染路径复发未拦截。该读是 #2152 锁访问器契约下唯一绕过 imAdaptersMu 的点，渲染帧与任一持锁写（SetIMAdapterEnabled 等）交叠即 Go runtime fatal 不可恢复。

改动：①14 文件（discord/dingtalk/matrix/whatsapp/irc/feishu/slack/signal/tg/mattermost/nostr/twitch/wechat/qq）批量对齐 #2337 模式：snapAdapters := m.config.IMSnapshot().Adapters 一次快照，len 容量提示与遍历复用同一变量（顺带消除每帧双快照）；②#2337 源码扫描守卫泛化为 15 文件全量（含 wecom）双断言（禁止活 map len 读+必须 snapAdapters 模式），防第 16 个 panel 再复发。

验证：泛化双探针对 main 的 14 文件 FAIL 钉根因（逐文件报点）→修复后 15/15 PASS；#2337 既有 wecom 回归绿；internal/tui 全包测试绿（11.7s）；go build -tags goolm ./... + gofmt 净。15 文件机械同型替换经 batch_replace 单模式完成，零手工逐文件漂移面。