TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
WXPush 微信推播工具：能用不能用，先看你有沒有認證服務號
WXPush 把微信服務號的模板消息 API 包成一支部署在 Cloudflare Workers 的 HTTP 端點，部署只需貼一段程式碼。但原始碼與微信官方文件都顯示，它的真門檻不在部署，而在你得先有一個通過認證的微信服務號，而且模板消息只能用於服務通知、不能行銷。這篇從機制、服務號限制、十萬次額度的兩層真相，到與 Server醬、PushPlus、Bark 的取捨，一次說清楚。
用 AI 摘要這篇文章：
WXPush 是開發者飯奇駿（frankiejun）以 MIT 授權開源的微信推播工具，把整支服務塞進一個 Cloudflare Worker 裡，呼叫一支 /wxsend 端點就能把訊息推到指定的微信使用者手機。它的部署確實輕到誘人：把 src/index.js 整段貼進 Cloudflare Workers 編輯器、填好幾個環境變數就能上線，不必另外架伺服器。但比部署更關鍵的前提藏在它的 API 依賴裡：它背後呼叫的是微信同樣架在 Cloudflare Workers 上的那類「模板消息」API，而這個 API 只開放給通過認證的微信服務號。換句話說，能不能用 WXPush 的分水嶺不在部署，而在你手上有沒有那一個服務號。
這篇把 WXPush 的實際機制、那道被多數介紹文跳過的服務號門檻、以及它跟 Server醬、PushPlus、Bark 之間的取捨一次說清楚，讓你在動手部署前就能判斷值不值得裝。
一支 API 打到底：WXPush 實際在做什麼
WXPush 全部邏輯集中在一個檔案 src/index.js（連同大量內嵌的 HTML 顯示頁，約九百多行），本質是微信官方模板消息 API 的薄包裝。它對外只露出一個 /wxsend 端點，接收 token、title、content 三個必填參數，支援 GET 與 POST 兩種呼叫方式，POST 可改用 Authorization 標頭帶 token，對接 webhook 場景更順。
推進去的過程拆成兩個官方 API 呼叫，都寫在 sendMessage() 與 getStableToken() 這兩個函式裡：先用你設定的 WX_APPID 與 WX_SECRET 呼叫 api.weixin.qq.com/cgi-bin/stable_token 換出 access_token，再對 WX_USERID 裡每一個用 | 分隔的 OpenID，逐一呼叫 cgi-bin/message/template/send 寄出模板消息。所謂「原生彈窗加聲音提醒」，其實是微信模板消息本身的呈現方式，並不是 WXPush 自己做的通知系統；這點很重要，因為它決定了後面那道門檻為什麼躲不掉。
對呼叫端來說，整支服務被收斂成「發一個 HTTP 請求」這一件事。最基本的形式是一個 GET 網址：
https://<你的-Worker-網址>/wxsend?token=你的API_TOKEN&title=伺服器通知&content=服務已於 22:00 重啟想接自動化腳本，則改用 POST 帶 Authorization 標頭與 JSON 內容，格式更乾淨，也避免把參數留在網址裡。這個設計讓 WXPush 很容易接進現有的監控、CI 完成通知、或定時任務，只要那個系統能發 HTTP 請求，就能驅動它。臨時要覆寫收件人也可以：在請求裡多帶一個 userid 參數，就能指定這一則訊息只推給某個 OpenID，不碰預設的全員設定。
一個值得注意的設計：點開微信通知後跳到的頁面，由你設定的 WX_BASE_URL 決定（預設指向 WXPush 自帶的 /skin 顯示頁），而訊息內容是被編碼後帶在網址 query string 裡的（?message=...&date=...&title=...）。這讓「跳轉穩定」這句 README 描述有了具體解釋：落地頁就長在同一個 Worker 上，不依賴外部空間。對個人用量這個設計夠用，但若是會把機敏內容推到公開服務的場景，得留意訊息會以網址參數的形式經過微信跳轉、留在伺服器日誌與收件人瀏覽器記錄裡。
真正的門檻在微信那一側：認證服務號
把環境變數清單攤開就會發現，WX_APPID、WX_SECRET、WX_TEMPLATE_ID、WX_USERID 這四個值全部只能從「微信公眾平台」的服務號後台取得。而根據微信官方開發者文件的明文規定，模板消息的使用權限只開放給通過認證的服務號，訂閱號拿不到這個 API。這句話原文是「只有認證後的服務號才可以申請模板消息的使用權限並獲得該權限」，相當直接。
這個限制會過濾掉很大一批潛在使用者。微信公眾號分訂閱號與服務號兩大類，個人能較容易註冊的訂閱號，並不具備呼叫模板消息 API 的資格；服務號則需要組織型態的註冊與認證手續。換句話說，如果你手邊沒有已經認證好的服務號，WXPush 對你來說不是「十分鐘就能裝好」，而是「連第一步都過不了」，你得先走完服務號申請與認證這條前置流程。這也是為什麼我會把 WXPush 歸類成「適合已經在微信體系裡有服務號的開發者」，而不是它對外訴求的「個人使用者」場景。
把「認證服務號」翻譯成實際的取得成本更清楚：服務號的註冊主體是企業、組織或個體工商戶這類非純個人身分，需要提交營業執照或對應登記資料、走完微信審核與年費認證。對本來就在微信上做服務的店家或應用營運方，這個服務號是現成資產，WXPush 等於幫它多開一個對外推播的 API；但對單純想做個人通知推送的人，為了這個工具去申請一個服務號，幾乎一定是本末倒置。看清這層成本，你就能解釋為什麼市面上絕大多數「微信推送」需求者寧可去用 Server醬這種把服務號維運吸收掉的第三方服務。
另一個容易被忽略的官方限制是用途。微信文件把模板消息限定在「重要的服務通知」，例如信用卡刷卡通知、購買成功通知這類，明文禁止廣告與行銷訊息，也不能騷擾使用者。所以如果你想拿 WXPush 做的是定期推播電子報、促銷提醒、或任何帶行銷味的廣播，等於直接踩到微信政策的紅線，帳號有被處置的風險。這要歸因於它所綁定的 API 天生就排除了這類用途，與 WXPush 本身無關。另外官方也限制每個帳號同時最多二十五個模板、並要從所選行業類別裡挑，這些都會回頭影響你能推什麼樣的訊息。
「每天十萬次免費」其實是兩層額度疊在一起
README 寫的「每天十萬次額度，個人用不完」，讀起來像一個數字，實際上是兩個獨立額度剛好同數字。第一層是 Cloudflare Workers 的免費方案：根據 Cloudflare 官方 limits 文件，免費方案每天有十萬次請求、每次請求上限 10 毫秒 CPU 時間，超額會回 Error 1027，並在 UTC 零點重置。第二層是微信模板消息本身，官方預設也是每天十萬次（帳號粉絲數超過十萬、百萬、千萬時還會往上調）。兩邊剛好都是十萬，所以這個數字不是某一邊單獨給的承諾。
把這個看清楚有兩個實際好處。一是你不會誤以為額度無上限：真要密集推播，瓶頸可能先撞到 Cloudflare 那 10 毫秒 CPU 上限（官方文件提到平均一個 Worker 約耗 2.2 毫秒，但較重的驗證或運算可能落到 10 到 20 毫秒而被切），也可能撞到微信側的每日上限。二是它點出 WXPush 的成本結構：對絕大多數個人通知場景（伺服器掛掉、定時任務完成、監控觸發），十萬次一天確實用不完；但若你想撐的是高頻推送，就得同時評估 Cloudflare 付費方案與微信側的每日上限。
順帶一提，原始碼裡每次請求都會重新呼叫 stable_token 換 access_token，沒有做 token 快取。微信官方建議 access_token 快取約七千兩百秒以避免頻繁刷新碰上限，所以這個設計在極高頻場景下算是一個效率短板，不過對個人量級的推播影響有限。
跟 Server醬、PushPlus、Bark 比起來
想判斷 WXPush 適不適合你，把它跟幾個常被拿來相提並論的推播工具擺在一起看最快。下面這張表是依各工具的官方定位與公開說明整理（具體配額以各工具官網為準），時間基準為 2026 年 8 月。
| 工具 | 託管方式 | 推送通道 | 主要門檻 | 適合誰 |
|---|---|---|---|---|
| WXPush | 自架（Cloudflare Workers 或 Docker） | 微信模板消息，走你自己的服務號 | 要有已認證微信服務號 | 已有服務號、想完全自控的開發者 |
| Server醬 | 第三方託管服務 | 微信（早期）／企業微信等 | 依賴服務方續航與配額政策 | 不想自架、求最快上手 |
| PushPlus | 第三方託管服務 | 微信、郵件、其他通道 | 配額與進階功能綁付費方案 | 需要多通道聚合的人 |
| Bark | 自架或官方伺服器 | 蘋果 APNs（僅 iOS） | 只推 iOS、不推微信 | 純蘋果裝置的使用者 |
差異的核心一句話：Server醬與 PushPlus 把「微信那側的服務號維運」吸收進他們自己的服務裡，你不用碰服務號，代價是訊息從他們的服務發出、也受他們的配額與政策節制；WXPush 走相反路，訊息從你自己的服務號發出，完全不依賴第三方續航，但你自己得扛下服務號這個前置成本。這也是它跟同樣需要自行打理基建的監控類自架工具處境相近的地方。如果你的訊息需要走到微信、又想完全自控，WXPush 是這個交叉條件下少見的選項；如果你只是要快速收到通知、不在乎走誰的通道，門檻低很多的第三方服務會更省事。
動手前要準備什麼
釐清門檻之後，部署本身反而單純。決定要用 WXPush 之前，照下面這個清單先自問一遍，缺任何一項都會卡住：
- 一個通過認證的微信服務號（不是訂閱號），並在其後台開通模板消息使用權限。這是能否呼叫 API 的根本條件。
- 從服務號後台取得的
AppID與AppSecret（對應 WXPush 的WX_APPID、WX_SECRET）。 - 一個從微信模板庫挑選並設定的模板 ID（
WX_TEMPLATE_ID），且模板欄位要能對應 WXPush 推送的title與content。 - 接收訊息使用者的
OpenID（WX_USERID，多使用者用|分隔）。 - 一個 Cloudflare 帳號（用 Workers 免費方案），或一套能跑 Docker 的環境（官方映像
ghcr.io/frankiejun/wxpush:latest，連接埠 3939）。 - 自訂一個夠複雜的
API_TOKEN，因為它是唯一用來驗證呼叫端的鑰匙，等於誰拿到 token 誰就能對你的服務號推訊息。
這些都備齊後，部署路徑官方給了三種：最簡單的是把 src/index.js 直接貼進 Cloudflare Workers 編輯器；想要版本控制與自動重新部署可連結 GitHub 倉庫走 Cloudflare Pages；偏好自架則用 Docker。三條路的環境變數都一樣，差別只在程式碼怎麼更新上去。實際部署步驟建議照作者在 README 與教學影片裡的程序走，這裡不重複展開。
適合誰、不適合誰
WXPush 適合的人其實滿明確：你已經在微信體系裡有一個認證服務號（例如店家、服務型應用的營運方），想把伺服器告警、定時任務結果、或後端事件用一支 API 推到內部成員的微信，而且希望訊息從自己的服務號發出、不依賴第三方推播服務的續航與配額。對這種需求，WXPush 把模板消息包成乾淨端點、又開源可自架，是一個合理選擇。它的 MIT 授權允許商用，repo 在 2026 年 8 月仍有新提交、約一千兩百多個星標、零未解 issue，維護訊號算健康。
相反地，如果你屬於下面任何一種，把 WXPush 放回架上會更省心：只有個人訂閱號、沒有也不打算申請認證服務號；想推的是行銷、促銷、電子報這類會踩到微信模板消息政策紅線的內容；收訊對象不在微信上（例如想推到 iOS 通知中心，那跟微信有關的工具或純 iOS 的 Bark 更對題）；或單純只想三分鐘裝好就收到通知、不想碰任何服務號設定，這時 Server醬、PushPlus 這種第三方託管服務的門檻低得多。
最後一個判斷點是誠實面的：WXPush 把「免費、簡單、十萬次」放進標語，但真正決定你能不能用的是微信那一側早就寫死的服務號資格與用途限制；部署包裝再輕也繞不過這一層。看懂這一層，你就不會把時間花在部署一個最終推不出訊息的服務上。
