送禁令（Send Ban）優(yōu)先級驗證：已知用戶禁令先于頻道 Slot 故障裁決)
即時通訊后端【免費下載鏈接】WuKongIMMore than just IM 不只是即時通訊(IM)項目地址https://gitcode.com/gh_mirrors/wu/WuKongIM點擊查看免費下載導(dǎo)讀本文基于 WuKongIM 倉庫中的 E2E 驗證報告 docs/reports/2026-09-24-send-ban-priority.md完整還原一次真實的進程級故障優(yōu)先級驗證當目標頻道的權(quán)威 Slot 宕機、策略查詢返回 503 時已經(jīng)寫入的用戶發(fā)送禁令UID Send Ban依然可以獨立裁決并拒絕發(fā)送。讀者將掌握 WuKongIM 發(fā)送禁令的優(yōu)先級判定順序、三節(jié)點集群下如何人為構(gòu)造一個策略可用、另一個策略不可用的確定性場景以及如何用一條 Go E2E 命令復(fù)現(xiàn)該驗證并產(chǎn)出 JSON 證據(jù)報告。驗證背景設(shè)計 F7 與發(fā)送禁令裁決WuKongIM 在消息發(fā)送路徑上引入了**發(fā)送禁令send_ban**機制用于按用戶UID或按目標頻道Channel粒度的發(fā)送控制。消息在真正落庫之前必須經(jīng)過權(quán)限裁決裁決結(jié)論直接影響協(xié)議層返回的原因碼。本次驗證對應(yīng)設(shè)計 F7證明用戶禁令與頻道 Slot 不可用兩類故障同時存在時系統(tǒng)按既定優(yōu)先級裁決——已知的用戶禁令先于頻道策略的可用性判定即使頻道策略權(quán)威節(jié)點宕機被禁用戶的消息仍然被拒絕而不是放行或錯誤重試。從源碼看這一優(yōu)先級并非測試臨時設(shè)計而是發(fā)送權(quán)限鏈路的固有順序。internal/usecase/message/FLOW.md 明確寫道UID SendBan and actual source-Channel SendBan/Disband precede all system identity, system-device and plugin exemptions——即 UID 禁令與源頻道禁令排在所有系統(tǒng)身份、系統(tǒng)設(shè)備和插件豁免之前。測試拓撲與確定性故障構(gòu)造集群參數(shù)驗證在三節(jié)點集群上進行關(guān)鍵配置通過節(jié)點環(huán)境變量覆蓋對應(yīng) send_ban_test.go 中的suite.WithNodeConfigOverrides配置項取值說明WK_CLUSTER_HASH_SLOT_COUNT256全集群共 256 個 Hash SlotWK_CLUSTER_INITIAL_SLOT_COUNT12初始創(chuàng)建 12 個物理 SlotWK_CLUSTER_SLOT_REPLICA_N1每個 Slot 僅 1 個 voter單副本W(wǎng)K_GATEWAY_TOKEN_AUTH_ONfalse關(guān)閉 token 認證專注權(quán)限裁決路徑WK_MESSAGE_PERMISSION_CACHE_TTL1h消息權(quán)限緩存 TTL 為 1 小時選擇單副本1 voter/Slot是為了確定性制造一個策略 Slot 不可用而另一個仍可用的場景正如報告明確聲明不是高可用部署的推薦或承諾。讀者切勿將本拓撲理解為生產(chǎn)高可用配置。Slot 放置與接入節(jié)點通過公開的 Manager placement 接口確認UID 的用戶策略 Slot 12 位于節(jié)點 3UID 為ban-priority-sender由crc32.ChecksumIEEE(uid) % 256計算落槽頻道的策略 Slot 8 位于節(jié)點 1節(jié)點 2 為第三方接入節(jié)點ingressID既非 UID 權(quán)威也非頻道權(quán)威。測試先用ban-priority-room-N逐一嘗試找到與用戶 Slot 權(quán)威不同 Leader 的頻道房間從而把用戶策略權(quán)威與頻道策略權(quán)威物理拆開到不同節(jié)點見 send_ban_test.go。故障注入順序先成功發(fā)送priority-warm預(yù)熱證明基線鏈路可用寫入用戶禁令send_ban1停止頻道策略權(quán)威所在的節(jié)點 1通過公開頻道策略查詢GET /channel/send_ban探測返回HTTP 503證明目標策略權(quán)威確實不可用測試中顯式斷言http.StatusServiceUnavailable見 send_ban_test.go。操作矩陣完整結(jié)果斷言報告給出了四步操作矩陣是本次驗證的核心證據(jù)完整繼承如下操作接入節(jié)點結(jié)果用戶禁令仍為 1UID owner 與第三節(jié)點HTTP 200、SEND 原因碼 25無消息 ID/序號寫入用戶禁令 0UID owner 與第三節(jié)點HTTP 503無消息 ID/序號再寫入用戶禁令 1第三節(jié)點原因碼 25無消息 ID/序號恢復(fù)節(jié)點 1確認 Slot authority 穩(wěn)定再解禁第三節(jié)點priority-recovered成功幾個關(guān)鍵語義點原因碼 25即協(xié)議層ReasonSendBan用戶或目標頻道禁止發(fā)送定義于 pkg/protocol/frame/common.go按ReasonCode枚舉順序ReasonUnknown0、ReasonSuccess1…… 依次遞增到ReasonSendBan25被拒絕的請求返回時無消息 ID 也無消息序號MessageID0、MessageSeq0測試斷言require.Zero拒絕請求的消息 ID/序號send_ban_test.go所有拒絕請求僅執(zhí)行一次不重試直到放行——這是測試紀律的核心約束AGENTS.md 中同樣強調(diào)Never retry a ban rejection until it succeeds見 test/e2e/message/send_ban/AGENTS.md禁令寫入版本依次為 1–4策略切換后的請求立即按新策略執(zhí)行無需等待緩存過期或額外刷新。源碼縱深優(yōu)先級是如何實現(xiàn)的用戶禁令先于頻道策略在 internal/usecase/message/permission.go 的權(quán)限入口中消息發(fā)送前按頻道類型分派檢查其中單人會話person會先執(zhí)行checkTerminalChannelPermission再執(zhí)行checkPersonSendPermission。真正體現(xiàn)用戶禁令優(yōu)先的是底層裁決順序checkSenderSendPermissionpermission.go調(diào)用GetUserSendPolicy(ctx, fromUID)讀取 UID 策略若SendBan ! 0則調(diào)用observeSendBan(user, 1)并直接返回ReasonSendBancheckTerminalChannelPermissionpermission.go讀取頻道策略先判Disband解散再判SendBan命中即返回ReasonSendBan。因此當用戶已被禁SendBan1時發(fā)送請求在任何需要查詢頻道權(quán)威的環(huán)節(jié)之前就已命中用戶策略并返回原因碼 25——這正是頻道 Slot 宕機返回 503用戶禁令仍能裁決拒絕的實現(xiàn)基礎(chǔ)被禁用戶不需要依賴頻道權(quán)威可用。HTTP 層面對不可用的表達/user/send_ban與/channel/send_ban的讀寫路由注冊于 internal/access/api/send_ban.go。當?shù)讓?usecase 不可用或查詢失敗時writeSendBanResult統(tǒng)一將錯誤映射為HTTP 503 temporarily_unavailablesend_ban.go。測試正是利用這一點寫入解禁send_ban0發(fā)生在頻道權(quán)威宕機期間因此返回 503——解禁寫入本身也受 Slot 權(quán)威可用性約束而讀取用戶禁令不受影響。公開同步契約驗證零副作用驗證最后通過成員公開接口POST /channel/messagesync核對完整歷史返回more0無更多分頁且嚴格等于兩個成功請求priority-warm與恢復(fù)后的priority-recovered無任何拒絕記錄或重復(fù)記錄send_ban_test.go。這證明被 503 拒絕的解禁寫入沒有留下半成品記錄被原因碼 25 拒絕的發(fā)送沒有產(chǎn)生任何持久化副作用。首次失敗與獨立發(fā)現(xiàn)Manager 歷史查詢不一致驗證過程并非一帆風(fēng)順。首次運行耗時 33.85 秒失敗于 Manager 完整歷史查詢而策略判定全部通過。第二次保留相同故障與判定改用成員公開同步契約核對歷史同時記錄三個節(jié)點的 Manager 響應(yīng)節(jié)點 3、節(jié)點 2返回404 channel not found節(jié)點 1頻道 Slot 權(quán)威返回兩條完整記錄成員同步從節(jié)點 2 同樣返回兩條完整記錄。因此沒有證據(jù)表明消息丟失。這是一個獨立待查問題Manager 跨節(jié)點查詢不一致已記錄在 docs/development/CODE_QUALITY.md指向ManagementMessageReader.QueryMessages - ReadChannelCommitted權(quán)威路徑且不能將其標記為已修復(fù)。原失敗產(chǎn)物保留本次通過的是禁發(fā)優(yōu)先級 公開成員歷史斷言二者邊界分明。重跑命令與產(chǎn)物驗證可一鍵復(fù)現(xiàn)完整命令Go 1.25.11 / Darwin arm64 實測通過WK_E2E_SEND_BAN_REPORT/tmp/send-ban-priority.json GOWORKoff go test -tagse2e ./test/e2e/message/send_ban -run ^TestKnownUserBanPrecedesUnavailableChannelSlot$ -count1 -timeout3m -p1 -v要點說明WK_E2E_SEND_BAN_REPORT指定報告輸出路徑測試結(jié)束時在指定路徑寫出.priority.json伴隨文件若未設(shè)置默認寫入系統(tǒng)臨時目錄下的wukongim-send-ban-report.json見 send_ban_test.go報告 JSON 包含節(jié)點數(shù)3、Hash Slot 數(shù)256、初始 Slot 數(shù)12、副本數(shù)1、源碼修訂號WK_E2E_SOURCE_REVISION、完整公開 Slot placementUID Slot 與頻道 Slot、時間戳、**策略版本、SEND 決策狀態(tài)碼與原因碼**與歷史響應(yīng)觀測原報告還提及產(chǎn)物清單manifest.json與源碼身份source.json兩個伴隨文件生產(chǎn)二進制與1ba4a6352相同本輪基于42b291b14僅補測試、無生產(chǎn)代碼變更——這是一次純驗證性質(zhì)的運行。邊界與限制聲明報告對驗證范圍保持了嚴格克制本文一并繼承本項不是性能資格測試不改變原有的 30 分鐘壓測、三組重復(fù)對照以及其他故障驗收缺口單副本拓撲不是高可用推薦選擇 1 voter/Slot 僅為確定性構(gòu)造故障不代表生產(chǎn)部署形態(tài)持久化側(cè)零副作用的證明范圍有限通過公開成員歷史契約證明拒絕無副作用但報告明確表示*不擴展為所有在線投遞矩陣的證明*Manager 跨節(jié)點查詢不一致為獨立未決問題禁止將本次驗證通過解讀為其已修復(fù)?？偨Y(jié)本次驗證用一次干凈的三節(jié)點故障注入確認了 WuKongIM 發(fā)送禁令的一個關(guān)鍵優(yōu)先級語義已知用戶禁令send_ban1可以在目標頻道策略權(quán)威完全不可用503時獨立裁決并拒絕發(fā)送拒絕僅執(zhí)行一次、不產(chǎn)生消息 ID/序號、不留下任何持久化副作用策略版本遞增且切換后立即生效。結(jié)合 permission.go 的實現(xiàn)可見這是UID 策略先行這一設(shè)計原則在真實進程故障下的行為保證。對運維與二次開發(fā)者而言這份報告同時提供了可復(fù)現(xiàn)的 E2E 命令、明確的證據(jù)邊界以及一個仍需跟進研究的 Manager 歷史查詢一致性問題。贊分享即時通訊后端【免費下載鏈接】WuKongIMMore than just IM 不只是即時通訊(IM)項目地址https://gitcode.com/gh_mirrors/wu/WuKongIM點擊查看免費下載相關(guān)推薦WuKongIM 用戶與頻道發(fā)送禁令Send Ban完整驗收審計功能矩陣、RPC 性能門檻與故障診斷實錄WuKongIM 用戶與頻道發(fā)送禁令Send Ban完整驗收審計功能矩陣、RPC 性能門檻與故障診斷實錄 本文以 WuKongIM 發(fā)送禁令Send b即時通訊后端WuKongIM發(fā)送禁令在 Slot Leader 手動轉(zhuǎn)移中保持生效的 E2E 驗證實錄WuKongIM發(fā)送禁令在 Slot Leader 手動轉(zhuǎn)移中保持生效的 E2E 驗證實錄 本篇記錄 WuKongIM 三節(jié)點進程級 E2E 如何驗證“用戶/即時通訊后端WuKongIM 發(fā)送禁令網(wǎng)關(guān)批次驗證三節(jié)點黑盒 E2E 下 UID/頻道分布與 ACK 逐條對齊WuKongIM 發(fā)送禁令網(wǎng)關(guān)批次驗證三節(jié)點黑盒 E2E 下 UID/頻道分布與 ACK 逐條對齊 本文基于 WuKongIM 倉庫中的報告 send ban即時通訊后端創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 WuKongIM 發(fā)送禁令（Send Ban）優(yōu)先級驗證：已知用戶禁令先于頻道 Slot 故障裁決
即時通訊后端【免費下載鏈接】WuKongIMMore than just IM 不只是即時通訊(IM)項目地址https://gitcode.com/gh_mirrors/wu/WuKongIM點擊查看免費下載導(dǎo)讀本文基于 WuKongIM 倉庫中的 E2E 驗證報告 docs/reports/2026-09-24-send-ban-priority.md完整還原一次真實的進程級故障優(yōu)先級驗證當目標頻道的權(quán)威 Slot 宕機、策略查詢返回 503 時已經(jīng)寫入的用戶發(fā)送禁令UID Send Ban依然可以獨立裁決并拒絕發(fā)送。讀者將掌握 WuKongIM 發(fā)送禁令的優(yōu)先級判定順序、三節(jié)點集群下如何人為構(gòu)造一個策略可用、另一個策略不可用的確定性場景以及如何用一條 Go E2E 命令復(fù)現(xiàn)該驗證并產(chǎn)出 JSON 證據(jù)報告。驗證背景設(shè)計 F7 與發(fā)送禁令裁決WuKongIM 在消息發(fā)送路徑上引入了**發(fā)送禁令send_ban**機制用于按用戶UID或按目標頻道Channel粒度的發(fā)送控制。消息在真正落庫之前必須經(jīng)過權(quán)限裁決裁決結(jié)論直接影響協(xié)議層返回的原因碼。本次驗證對應(yīng)設(shè)計 F7證明用戶禁令與頻道 Slot 不可用兩類故障同時存在時系統(tǒng)按既定優(yōu)先級裁決——已知的用戶禁令先于頻道策略的可用性判定即使頻道策略權(quán)威節(jié)點宕機被禁用戶的消息仍然被拒絕而不是放行或錯誤重試。從源碼看這一優(yōu)先級并非測試臨時設(shè)計而是發(fā)送權(quán)限鏈路的固有順序。internal/usecase/message/FLOW.md 明確寫道UID SendBan and actual source-Channel SendBan/Disband precede all system identity, system-device and plugin exemptions——即 UID 禁令與源頻道禁令排在所有系統(tǒng)身份、系統(tǒng)設(shè)備和插件豁免之前。測試拓撲與確定性故障構(gòu)造集群參數(shù)驗證在三節(jié)點集群上進行關(guān)鍵配置通過節(jié)點環(huán)境變量覆蓋對應(yīng) send_ban_test.go 中的suite.WithNodeConfigOverrides配置項取值說明WK_CLUSTER_HASH_SLOT_COUNT256全集群共 256 個 Hash SlotWK_CLUSTER_INITIAL_SLOT_COUNT12初始創(chuàng)建 12 個物理 SlotWK_CLUSTER_SLOT_REPLICA_N1每個 Slot 僅 1 個 voter單副本W(wǎng)K_GATEWAY_TOKEN_AUTH_ONfalse關(guān)閉 token 認證專注權(quán)限裁決路徑WK_MESSAGE_PERMISSION_CACHE_TTL1h消息權(quán)限緩存 TTL 為 1 小時選擇單副本1 voter/Slot是為了確定性制造一個策略 Slot 不可用而另一個仍可用的場景正如報告明確聲明不是高可用部署的推薦或承諾。讀者切勿將本拓撲理解為生產(chǎn)高可用配置。Slot 放置與接入節(jié)點通過公開的 Manager placement 接口確認UID 的用戶策略 Slot 12 位于節(jié)點 3UID 為ban-priority-sender由crc32.ChecksumIEEE(uid) % 256計算落槽頻道的策略 Slot 8 位于節(jié)點 1節(jié)點 2 為第三方接入節(jié)點ingressID既非 UID 權(quán)威也非頻道權(quán)威。測試先用ban-priority-room-N逐一嘗試找到與用戶 Slot 權(quán)威不同 Leader 的頻道房間從而把用戶策略權(quán)威與頻道策略權(quán)威物理拆開到不同節(jié)點見 send_ban_test.go。故障注入順序先成功發(fā)送priority-warm預(yù)熱證明基線鏈路可用寫入用戶禁令send_ban1停止頻道策略權(quán)威所在的節(jié)點 1通過公開頻道策略查詢GET /channel/send_ban探測返回HTTP 503證明目標策略權(quán)威確實不可用測試中顯式斷言http.StatusServiceUnavailable見 send_ban_test.go。操作矩陣完整結(jié)果斷言報告給出了四步操作矩陣是本次驗證的核心證據(jù)完整繼承如下操作接入節(jié)點結(jié)果用戶禁令仍為 1UID owner 與第三節(jié)點HTTP 200、SEND 原因碼 25無消息 ID/序號寫入用戶禁令 0UID owner 與第三節(jié)點HTTP 503無消息 ID/序號再寫入用戶禁令 1第三節(jié)點原因碼 25無消息 ID/序號恢復(fù)節(jié)點 1確認 Slot authority 穩(wěn)定再解禁第三節(jié)點priority-recovered成功幾個關(guān)鍵語義點原因碼 25即協(xié)議層ReasonSendBan用戶或目標頻道禁止發(fā)送定義于 pkg/protocol/frame/common.go按ReasonCode枚舉順序ReasonUnknown0、ReasonSuccess1…… 依次遞增到ReasonSendBan25被拒絕的請求返回時無消息 ID 也無消息序號MessageID0、MessageSeq0測試斷言require.Zero拒絕請求的消息 ID/序號send_ban_test.go所有拒絕請求僅執(zhí)行一次不重試直到放行——這是測試紀律的核心約束AGENTS.md 中同樣強調(diào)Never retry a ban rejection until it succeeds見 test/e2e/message/send_ban/AGENTS.md禁令寫入版本依次為 1–4策略切換后的請求立即按新策略執(zhí)行無需等待緩存過期或額外刷新。源碼縱深優(yōu)先級是如何實現(xiàn)的用戶禁令先于頻道策略在 internal/usecase/message/permission.go 的權(quán)限入口中消息發(fā)送前按頻道類型分派檢查其中單人會話person會先執(zhí)行checkTerminalChannelPermission再執(zhí)行checkPersonSendPermission。真正體現(xiàn)用戶禁令優(yōu)先的是底層裁決順序checkSenderSendPermissionpermission.go調(diào)用GetUserSendPolicy(ctx, fromUID)讀取 UID 策略若SendBan ! 0則調(diào)用observeSendBan(user, 1)并直接返回ReasonSendBancheckTerminalChannelPermissionpermission.go讀取頻道策略先判Disband解散再判SendBan命中即返回ReasonSendBan。因此當用戶已被禁SendBan1時發(fā)送請求在任何需要查詢頻道權(quán)威的環(huán)節(jié)之前就已命中用戶策略并返回原因碼 25——這正是頻道 Slot 宕機返回 503用戶禁令仍能裁決拒絕的實現(xiàn)基礎(chǔ)被禁用戶不需要依賴頻道權(quán)威可用。HTTP 層面對不可用的表達/user/send_ban與/channel/send_ban的讀寫路由注冊于 internal/access/api/send_ban.go。當?shù)讓?usecase 不可用或查詢失敗時writeSendBanResult統(tǒng)一將錯誤映射為HTTP 503 temporarily_unavailablesend_ban.go。測試正是利用這一點寫入解禁send_ban0發(fā)生在頻道權(quán)威宕機期間因此返回 503——解禁寫入本身也受 Slot 權(quán)威可用性約束而讀取用戶禁令不受影響。公開同步契約驗證零副作用驗證最后通過成員公開接口POST /channel/messagesync核對完整歷史返回more0無更多分頁且嚴格等于兩個成功請求priority-warm與恢復(fù)后的priority-recovered無任何拒絕記錄或重復(fù)記錄send_ban_test.go。這證明被 503 拒絕的解禁寫入沒有留下半成品記錄被原因碼 25 拒絕的發(fā)送沒有產(chǎn)生任何持久化副作用。首次失敗與獨立發(fā)現(xiàn)Manager 歷史查詢不一致驗證過程并非一帆風(fēng)順。首次運行耗時 33.85 秒失敗于 Manager 完整歷史查詢而策略判定全部通過。第二次保留相同故障與判定改用成員公開同步契約核對歷史同時記錄三個節(jié)點的 Manager 響應(yīng)節(jié)點 3、節(jié)點 2返回404 channel not found節(jié)點 1頻道 Slot 權(quán)威返回兩條完整記錄成員同步從節(jié)點 2 同樣返回兩條完整記錄。因此沒有證據(jù)表明消息丟失。這是一個獨立待查問題Manager 跨節(jié)點查詢不一致已記錄在 docs/development/CODE_QUALITY.md指向ManagementMessageReader.QueryMessages - ReadChannelCommitted權(quán)威路徑且不能將其標記為已修復(fù)。原失敗產(chǎn)物保留本次通過的是禁發(fā)優(yōu)先級 公開成員歷史斷言二者邊界分明。重跑命令與產(chǎn)物驗證可一鍵復(fù)現(xiàn)完整命令Go 1.25.11 / Darwin arm64 實測通過WK_E2E_SEND_BAN_REPORT/tmp/send-ban-priority.json GOWORKoff go test -tagse2e ./test/e2e/message/send_ban -run ^TestKnownUserBanPrecedesUnavailableChannelSlot$ -count1 -timeout3m -p1 -v要點說明WK_E2E_SEND_BAN_REPORT指定報告輸出路徑測試結(jié)束時在指定路徑寫出.priority.json伴隨文件若未設(shè)置默認寫入系統(tǒng)臨時目錄下的wukongim-send-ban-report.json見 send_ban_test.go報告 JSON 包含節(jié)點數(shù)3、Hash Slot 數(shù)256、初始 Slot 數(shù)12、副本數(shù)1、源碼修訂號WK_E2E_SOURCE_REVISION、完整公開 Slot placementUID Slot 與頻道 Slot、時間戳、**策略版本、SEND 決策狀態(tài)碼與原因碼**與歷史響應(yīng)觀測原報告還提及產(chǎn)物清單manifest.json與源碼身份source.json兩個伴隨文件生產(chǎn)二進制與1ba4a6352相同本輪基于42b291b14僅補測試、無生產(chǎn)代碼變更——這是一次純驗證性質(zhì)的運行。邊界與限制聲明報告對驗證范圍保持了嚴格克制本文一并繼承本項不是性能資格測試不改變原有的 30 分鐘壓測、三組重復(fù)對照以及其他故障驗收缺口單副本拓撲不是高可用推薦選擇 1 voter/Slot 僅為確定性構(gòu)造故障不代表生產(chǎn)部署形態(tài)持久化側(cè)零副作用的證明范圍有限通過公開成員歷史契約證明拒絕無副作用但報告明確表示*不擴展為所有在線投遞矩陣的證明*Manager 跨節(jié)點查詢不一致為獨立未決問題禁止將本次驗證通過解讀為其已修復(fù)?？偨Y(jié)本次驗證用一次干凈的三節(jié)點故障注入確認了 WuKongIM 發(fā)送禁令的一個關(guān)鍵優(yōu)先級語義已知用戶禁令send_ban1可以在目標頻道策略權(quán)威完全不可用503時獨立裁決并拒絕發(fā)送拒絕僅執(zhí)行一次、不產(chǎn)生消息 ID/序號、不留下任何持久化副作用策略版本遞增且切換后立即生效。結(jié)合 permission.go 的實現(xiàn)可見這是UID 策略先行這一設(shè)計原則在真實進程故障下的行為保證。對運維與二次開發(fā)者而言這份報告同時提供了可復(fù)現(xiàn)的 E2E 命令、明確的證據(jù)邊界以及一個仍需跟進研究的 Manager 歷史查詢一致性問題。贊分享即時通訊后端【免費下載鏈接】WuKongIMMore than just IM 不只是即時通訊(IM)項目地址https://gitcode.com/gh_mirrors/wu/WuKongIM點擊查看免費下載相關(guān)推薦WuKongIM 用戶與頻道發(fā)送禁令Send Ban完整驗收審計功能矩陣、RPC 性能門檻與故障診斷實錄WuKongIM 用戶與頻道發(fā)送禁令Send Ban完整驗收審計功能矩陣、RPC 性能門檻與故障診斷實錄 本文以 WuKongIM 發(fā)送禁令Send b即時通訊后端WuKongIM發(fā)送禁令在 Slot Leader 手動轉(zhuǎn)移中保持生效的 E2E 驗證實錄WuKongIM發(fā)送禁令在 Slot Leader 手動轉(zhuǎn)移中保持生效的 E2E 驗證實錄 本篇記錄 WuKongIM 三節(jié)點進程級 E2E 如何驗證“用戶/即時通訊后端WuKongIM 發(fā)送禁令網(wǎng)關(guān)批次驗證三節(jié)點黑盒 E2E 下 UID/頻道分布與 ACK 逐條對齊WuKongIM 發(fā)送禁令網(wǎng)關(guān)批次驗證三節(jié)點黑盒 E2E 下 UID/頻道分布與 ACK 逐條對齊 本文基于 WuKongIM 倉庫中的報告 send ban即時通訊后端創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考