你在 Telegram 常遇到的兩種「垃圾引流」：
- 陌生帳號突然私訊你投放內容
- 或是把你拉進某個群組／頻道（有時還搭配機器人）
這類東西的本質通常不是 Bot API 在做
而是用 Telegram Client 在跑：也就是「真人帳號殼」在發訊息
不是 Bot API：而是 Telegram Client
Bot API 的限制很多，尤其是「主動私訊」這件事本來就不友善。
所以這類系統會直接用 Telegram Client（概念上就像你手機 Telegram 的程式能力），用程式去操作「使用者帳號」做發送。
關鍵差異只有一句話：
Bot 是平台管得很死的接口；Client 是真人帳號本來就能做的事。
核心資產不是內容，是 Session String
這類系統最值錢的不是訊息模板，而是：
登入狀態（session string / session data）
因為只要 session 還有效，就代表：
- 不用每次都簡訊驗證
- 程式可以長期「以這個帳號身份」發訊息、拉人、加群
所以流程通常是：
- 帳號先登入一次
- 把 session string 抽出來
- 之後都靠這串 session 直接啟動 client
為什麼一定要用 DB 做持久化？
因為系統要管理的不是「一個帳號」，是一個帳號池
DB 存的不只是 session，還會存「可用狀態」，概念上像：
- 這個帳號現在能不能發（可用 / 冷卻 / 受限）
- 最近一次發送時間
- 連續失敗次數（用來判斷風控或封鎖風險）
重點是：session 是鑰匙；DB 是你的帳號資源管理面板
沒有 DB，你就只是在亂發；有 DB，才叫系統
群發的關鍵不是「發很多」，是「別讓帳號一次死掉」
Telegram 對 client 行為會做風控：發太密、行為太機械，就會出事
所以真正的群發核心不是爆量，而是：
分散風險、延長壽命
這也是為什麼它幾乎一定會做「帳號輪詢」
Round Robin 輪詢：不是為了平均負載，是為了生存
常見策略會長得像：
- A 帳號發 N 則 → 換 B → 換 C
- 每個帳號之間插冷卻時間
- 出現錯誤就把帳號標記「降速/停用」
Round Robin 在這裡的目的不是效能，而是：
- 降低單一帳號的發送密度
- 讓風控壓力分散到整個池
- 某些帳號掛掉也不影響整體繼續跑
所以你封鎖一個帳號，通常只是在池子裡拔掉一顆牙：
池子還在，輪詢還在，引流就還在
它其實是「帳號資源調度系統」
把道德跟用途先放一邊，純看系統本質，這類引流架構其實只做三件事：
- 用 Telegram Client 操作真人帳號
- 把 session string 當成可重複使用的登入憑證，放 DB 管理
- 用 輪詢調度（round robin） 分散風控，延長整個帳號池壽命
訊息內容只是耗材；真正被精心管理的是「帳號」本身