從 Slack 大中華區關停，看數字時代最被忽視的風險

2026 年 4 月 1 日，愚人節。

但對成千上萬使用 Slack 的香港、澳門、大陸團隊來說，這一天發生的事情一點也不好笑。（Slack，類似海外版飛書與釘釘）

早上打開 Slack，看到的不是同事們的消息，而是一行冷冰冰的提示：你的工作區已被停用。所有消息、文件、頻道、工作流，多年積累的組織記憶，全部不可訪問。

沒有商量，沒有過渡，數據進入刪除倒計時。

一、發生了什么

2025 年 11 月，Salesforce 旗下的 Slack 向大中華區用戶發出通知：由于 Salesforce 與阿里巴巴在 2019 年建立的戰略合作關系，Slack 將不再直接續約該區域的訂閱，受影響用戶需要在 2026 年 2 月前做出安排。(來源：The Information 報道[1]；Hacker News 討論帖[2] 中有兩封不同版本通知郵件的全文)

https://news.ycombinator.com/item?id=45961519[3]

但不同規模的用戶，收到的是完全不同的兩封信。

大客戶的郵件里有一條出路：通過阿里云 reseller 繼續購買 Slack 服務。小團隊收到的則是一封告別信，“你的服務將在 2026 年 2 月 1 日終止，工作區和全部數據將在停用后 90 天內刪除。”沒有替代方案，沒有遷移路徑。(HN 用戶貼出的小團隊終止通知原文[4])

2026 年 4 月 1 日，工作區被實際停用。多名用戶在 Reddit 上報告：當天登錄發現工作區已鎖死，此前沒有收到任何通知，或者說，通知只發給了工作區的 Owner 和 Admin，普通成員不在通知對象內；而即便是 Owner 和 Admin，也有大量人聲稱沒有收到郵件。(gizchina 報道[5]；yage.ai 長文分析[6])

Slack 客服的回復模板確認了這一點：“我們已提前通知了工作區的 Owner 和 Admin。”但當后果是團隊永久喪失工作數據時，“我們通知了管理員”是一個技術上成立、體驗上災難的答案。

二、阿里云：誰的出路？

所謂“遷移到阿里云”的出路，也遠沒有聽起來那么通暢。

4 月 1 日流出的 Slack 支持模板顯示：通過阿里云 reseller 續購的路徑僅適用于部分香港付費客戶；對大陸和澳門用戶，模板原文寫著 “Slack via Alibaba Cloud is not available in China and Macau”。(yage.ai 分析文引用了完整模板[7])

換句話說，如果你是大陸或澳門的用戶，“阿里云遷移”從一開始就不是為你準備的。如果你是小團隊，不管你在哪里，你連這個選項都看不到。

而即便阿里云真的能遷移成功，你從一個你無法控制的平臺，搬到了另一個你無法控制的平臺。平臺邏輯沒變，你依然是租客，不是業主。

三、你的數據，你能拿走嗎？

這是整個事件中最值得深究的部分。有人會說：Slack 給了 90 天的刪除倒計時，用戶應該趁這段時間導出數據。但這里有兩層問題。

第一層：停用前的窗口期確實存在，但很多人錯過了。 從 2025 年 11 月通知到 2026 年 4 月停用，最長有將近 5 個月的準備時間，如果你收到了通知的話。 而大量用戶報告稱沒有收到。在 Slack 的用戶協議模型里，合同項下的通知只送給 Customer（即工作區 Owner），不送給每一個 Authorized User。一個 50 人的團隊，可能只有一個人在通知鏈上，而那個人可能根本沒看到那封郵件。

第二層：一旦工作區被停用，自助導出能力也一并消失。 Slack 的數據導出功能需要管理員登錄后臺操作（設置 → 工作區設置 → 導入/導出數據）。 工作區停用后，后臺不可訪問，自助導出通道就斷了。后續你只能聯系 Slack 客服請求數據返還，這取決于你的付費計劃、客服響應速度和 Slack 的裁量。(Slack 官方導出文檔[8])

更關鍵的是：即使在正常狀態下，免費和 Pro 計劃也只能導出公共頻道的消息；私聊和私有頻道的導出，在 Business+ 以下需要單獨申請，Slack 有權拒絕。(Slack 官方導入/導出指南[9])

所以現實是：你以為你擁有的數據，在你最需要它的那一刻，你可能既看不到，也拿不走，不是因為法律上它不屬于你，而是因為技術上的控制權不在你手里。

四、這不是第一次

這不是 SaaS 平臺第一次讓用戶突然失去對數據的訪問。但不同事件的觸發機制不同，值得分開看。

第一類：制裁合規。 2018 年，Slack 為合規美國 OFAC 制裁，封禁了所有與伊朗相關的賬戶，包括一個在加拿大溫哥華讀博的伊朗裔學者、幾年前去伊朗旅游過一次的比利時人、一個 CTO 去克里米亞度假導致整個公司工作區被停用的團隊。執行極其粗暴，事后 Slack 道歉并修正了策略，承認誤封了一批賬戶。(Slack 官方道歉博客[10]) 2019 年，GitHub 對伊朗、敘利亞、克里米亞開發者實施了類似限制，封鎖私有倉庫訪問，事后在 2021 年獲得 OFAC 許可恢復了伊朗用戶的全部服務。(GitHub 貿易管制說明[11])

第二類：商業退出。 這就是 2026 年 Slack 大中華區的情況。香港不是伊朗那種全面禁運轄區，美國對香港存在針對特定個人和實體的制裁項目，但沒有全面貿易禁運。Slack 退出的核心驅動力是合規成本：在中國直接提供 SaaS 服務需要本地基礎設施部署、數據安全評估、監管審查，成本極高。當成本超過收入，Salesforce 選擇退出。這是一個可以理解的商業決策，但對用戶來說，結果和制裁關停沒有本質區別。

第三類：國家封鎖。 2026 年 2 月，印度政府據報道依據《信息技術法》第 69A 條對 Supabase 域名實施了網絡封鎖，導致大量印度開發者在數天內無法訪問后端服務，生產環境的應用出現認證失效和數據庫連接中斷。Supabase 后來確認封鎖令在 3 月 3 日被撤銷，整個封鎖持續約 8 天。(Supabase 印度封鎖分析[12])

三類事件，三種觸發因素，美國制裁、商業退出、政府封鎖，但共同的失效模式只有一個：你對關鍵基礎設施的可用性，取決于一個你無法控制的外部主體的決策。

五、這不是道德問題，是結構問題

Slack 退出大中華區，不是因為它恨中國用戶。沒有人針對你，沒有人要害你。只是商業邏輯運轉到了某個節點，你所在的區域不再有利可圖，于是你被優化掉了。這恰恰是最可怕的部分，它不需要惡意，就能摧毀你。

當你使用 SaaS 時，你簽署的 Terms of Service 里通常包含一條：服務商有權在合理通知后終止服務。“合理通知”可能只是一封你沒收到的郵件。“終止服務”意味著你的管理后臺被鎖死，自助導出通道關閉。你的數據在法律上也許還是你的，Slack 的隱私政策確實把 Customer Data 定義為客戶控制的數據，但法律意義上的歸屬和技術意義上的可控是兩回事。

再加上美國 CLOUD Act：對于受美國司法管轄的服務商，美國政府可以基于有效法律程序（如法庭傳票或搜查令）要求其披露所控制的數據，不論數據存放在哪個國家的服務器上。這不是“隨時拿走”，但它意味著你的數據處于一個你無法參與的法律博弈中。

所以問題不是“數據屬于誰”，在合同和法律框架里，它屬于你。問題是：可用性、可遷移性、司法管轄和技術控制權，有多少真正在你手里？ Slack 事件已經給出了答案：在服務商決定退出的那一刻，以上全部歸零。

六、如果你還在用 SaaS

我不是說“立刻把所有 SaaS 都換掉”。對很多團隊來說，SaaS 依然是最務實的選擇。 但你應該問自己一個問題：如果你今天用的核心工具，即時通訊、代碼托管、數據庫、文件存儲，明天突然進不去了，你的業務還能運轉嗎？

如果答案是“不能”，你需要做的事情很簡單，而且現在就應該開始。

底線：定期導出，驗證恢復。 這不需要自建任何東西，只需要紀律。用 Slack，每月導出一次完整消息歸檔，因為一旦工作區被停用，自助導出就斷了。用 GitHub，確保每個倉庫在本地有完整克隆。用任何托管數據庫，確保有定時備份在跑，并且你驗證過恢復流程能真的跑通。滅火器看起來很“浪費空間”，直到火災來了。

進階：核心系統考慮自建。 如果你的業務對某個 SaaS 的依賴程度已經到了“它掛我就死”的地步，那它就值得自建。

拿這次的核心場景來說，即時通訊。Mattermost 是成熟的開源 Slack 替代品，體驗高度接近，已被大量高安全級別的機構采用。 法國政府基于 Matrix/Element 協議部署了自己的安全通訊系統 Tchap，正是出于數據主權的考量。

自建的門檻在 2026 年已經大幅降低：一臺 VPS，一個 PostgreSQL 實例，一個容器，AI 編程助手幫你寫配置、拉鏡像、配反代，部署一個可用的實例，確實可以在一小時內完成。 老馮在 PIGSTY 里很早以前就做了自建 Mattermost 的模板：一個自帶高可用 PITR 的 PG，加上一個跑無狀態 Mattermost 的容器，幾行命令，就可以輕松搭建一套屬于自己的 IM。

對于稍微有點技術能力的團隊來說，這筆賬是劃算的，因為你換來的是對數據和可用性的完全控制。對于沒有運維能力的團隊，底線方案（定期導出 + 恢復演練）也遠好于什么都不做。

當然，有人會說：不用 Slack 我還可以用飛書、釘釘、企業微信，這些國內大廠提供了極具性價比的替代品。 沒錯。但它們本質上依然是 SaaS，只是換了一個你無法控制的平臺方。而且它們可能面臨另一個維度的合規風險。平臺邏輯不變，你的處境就不會變。

七、數據主權是一個工程問題

“數據主權”這個詞說了很多年，但它不是政治口號，它是一個需要工程手段來回答的問題。

它有三個層次：物理位置（數據在哪國的機房）、法律管轄（運營商受哪國法律約束）、技術控制（你能否隨時訪問、導出、遷移、刪除數據）。三層全部滿足，你才真正掌握你的數據。

而實現這三層最切實可行的路徑是開源軟件加自建部署。開源保證技術透明和可遷移，自建保證物理和法律層面的控制權。 這不是唯一的路，合同保障、多云冗余、數據托管協議都能在某些層面提供保護，但它是唯一一條不依賴于任何第三方善意的路。

整條自建替代鏈在 2026 年已經成熟：即時通訊有 Mattermost、Rocket.Chat、Matrix/Element；代碼托管有 Gitea、GitLab； 數據庫用 PostgreSQL 自建，像 Supabase 也有成熟的開源一鍵自建方案；對象存儲有 MinIO；身份認證有 Keycloak。這些方案的共同特點是：開源、可自部署、數據在你手里。

八、結語

2026 年 4 月 1 日之后，那些失去 Slack 數據的團隊里，一定有人在想：如果當初我們用的是自建的方案，今天根本不會有這個問題。

但大多數人不會做改變。他們會罵幾天 Slack，然后換一個新的 SaaS，繼續把數據交給別人保管，繼續相信“這種事不會發生在我身上”。

直到下一次。

數據自主不是一種技術偏好，不是一種政治立場。它是對一個簡單問題的回答：你最核心的資產，控制權到底在誰手里？

如果答案不是你自己，那你就是在用自己的業務連續性，去賭別人的商業決策。

而這場賭局的賠率，正在對你越來越不利。

老馮 · 2026 年 4 月

本文不構成任何商業建議，但構成一個善意的提醒

References

[1] 來源：The Information 報道:https://www.theinformation.com/briefings/salesforces-slack-stop-direct-service-china-farm-alibaba
[2]Hacker News 討論帖:https://news.ycombinator.com/item?id=45961157
[3]:https://news.ycombinator.com/item?id=45961519
[4]HN 用戶貼出的小團隊終止通知原文:https://news.ycombinator.com/item?id=45961519
[5]gizchina 報道:https://www.gizchina.com/tech/slack-terminates-services-across-greater-china-triggering-user-backlash/
[6]yage.ai 長文分析:https://yage.ai/share/slack-china-workspace-exit-en-20260402.html
[7]yage.ai 分析文引用了完整模板:https://yage.ai/share/slack-china-workspace-exit-en-20260402.html
[8]Slack 官方導出文檔:https://slack.com/help/articles/201658943-Export-your-workspace-data
[9]Slack 官方導入/導出指南:https://slack.com/help/articles/204897248-Guide-to-Slack-import-and-export-tools
[10]Slack 官方道歉博客:https://slack.com/blog/news/an-apology-and-an-update
[11]GitHub 貿易管制說明:https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls
[12]Supabase 印度封鎖分析: https://articles.uvnetware.com/news/why-supabase-stopped-working-india-2026/