TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
PayQrcode 免費收款碼合併工具，把微信支付寶收進一張圖
PayQrcode 是把微信與支付寶收款碼合成同一張圖的免費網頁工具，全程在瀏覽器本機處理、圖片不上傳。實測發現預設參數的輸出在標準解碼器下兩層都讀不出來，列印前用兩款 App 實測是必要驗收，本文附完整參數測試結果與驗收流程。
用 AI 摘要這篇文章：
先講結論。PayQrcode 這個免費網頁工具，確實能把微信收款碼和支付寶收款碼（收款 QR Code）合成同一張圖，過程全部在你自己的瀏覽器裡跑完，圖片不會上傳到任何伺服器。這兩件事我都親自驗證過。但它預設參數做出來的合成碼，我用兩套主流的開源 QR 解碼器去讀，微信層和支付寶層都解不出來；GitHub 上也有一條 2025 年 7 月開立、到現在沒人回應的 issue，使用者回報支付寶內建掃碼對著合成碼，跳出「無法處理微信的二維碼」的錯誤。所以這篇文章的實用重點不是「它多神奇」，而是：你真的要用它，列印之前必須拿兩款 App 實際掃過一次，官方頁面上寫得像句客氣話，實際上是必要驗收。
先對齊使用場景。這工具服務的對象，是同時收微信支付和支付寶款項的人：在中國大陸擺攤、開小店、經營社群小生意的朋友，其中包含長期在中國大陸工作和生活的台灣人（同樣在中國大陸生態裡討生活的，還有處理電子發票報帳的 InvoiceFlowAI 這類工具）。台灣本地的行動支付（LINE Pay、街口這類）不在它的支援範圍，它的輸入白名單只認四種網址格式：wxp:// 開頭的微信收款連結，以及 weixin.qq.com、wechatpay.cn、alipay.com 三個網域。你手上沒有這兩種收款碼，這篇看到這裡就可以離開了。
它想取代的東西：需要伺服器的舊式聚合碼
「把兩個收款碼變成一張」這個需求不新。早期常見的做法是「軟體識別版」：你拿到一個短網址，掃碼後先連到某台伺服器，伺服器判斷你的瀏覽器是微信還是支付寶，再把相對應的付款連結吐回來。這個做法的弱點很直觀：伺服器要錢養、網域一旦被封鎖就全滅、短網址遭人竄改時使用者毫無知覺，而仰賴平台介面的工具，平台一改政策就得退場，WeChat Article Exporter 的收攤就是個現成的例子。作者在 README 裡把 PayQrcode 定位成這條路的替代品，合併直接發生在圖片像素上，成品是一張普通的靜態圖，沒有伺服器可以攻擊，也沒有服務可以停機。這個定位是作者的宣稱，但就機制而言確實成立：你列印出來的紙，不需要任何後端就能繼續運作。
我丟兩張假收款碼進去，它真的吐出一張合成圖
實測流程很單純。我自己產了兩個測試用的 QR 圖檔，一個編碼 wxp:// 開頭的假微信收款連結，一個編碼 qr.alipay.com 的假支付寶連結，打開官網依序上傳。頁面上的兩個唯讀欄位立刻顯示解出來的原始網址，代表它先在你瀏覽器裡把兩張圖解碼還原成文字，確認格式對了才繼續；格式不對會直接跳錯誤提示，例如把微信碼丟進支付寶欄位，它不會讓你矇混過去。全部就緒後右下方出現合成結果，按下下載鈕拿到一張 PNG（桌機上是 588×588，高解析度螢幕與手機的尺寸會跟著變）。整段操作不需要註冊，也看不到廣告和次數限制。
一個重要細節：整段流程完全離線。我把專案原始碼整包抓下來檢查，整個前端只有五個相依套件：負責解碼的 jsQR、負責編碼的 qrcode、負責匯出畫面的 html2canvas，加上介面用的 Vue 和 TDesign 元件庫。上傳控制項設定成不自動上傳（autoUpload 為 false），圖檔用 FileReader 讀進記憶體就交給 canvas 處理。我在原始碼裡搜尋 fetch、axios、XMLHttpRequest，一筆 API 呼叫都沒有。你的收款碼圖片離開瀏覽器記憶體的唯一去處，就是你按下載之後的硬碟。把「不上傳」當賣點的網頁工具最近越來越多，Quote Maker 是另一個把這件事講清楚也做到的例子。
一張圖怎麼可能對兩個 App 說不同的話
這是整個工具最有意思的部分，原理是 QR Code 規格表裡的一行老設計：糾錯等級。QR Code 有 L、M、Q、H 四種糾錯等級，等級 H 容忍最多約 30% 的圖案損毀仍然讀得回來，代價是同樣的資料要畫得更密。你平常看到印刷品上商標蓋住一角還能掃的 QR Code，就是吃了這個紅利。PayQrcode 等於是把這個「容錯空間」拿來當隱藏容器用：蓋住的部分不是缺陷，是另一個條碼的座位。
合成步驟照原始碼逐行看是這樣。兩張上傳的碼先各自解回原始網址，再用最高糾錯等級 H 重新編成兩張乾淨的新 QR。支付寶那張的右下角會空出一塊長條區域（程式把它清成透明），頁面上那條滑桿控制的就是這條的長度，介面上的名稱照抄簡體原文叫「缺省比例」，意思就是預設比例，出廠預設 50%。有個容易被忽略的細節：清除用的是透明而非塗白，所以最終成品裡，這條區域會透出底層微信碼的圖案，兩層在這裡是疊影的關係。處理過的支付寶碼接著旋轉 180 度，縮放到版面的一半寬，疊在微信碼的右下角，蓋住大約四分之一的面積。旋轉的用意，按作者在 README 的說法，是干擾微信掃描器對那塊小碼的定位。
最反常的發現：標準解碼器讀不出預設輸出
故事到這裡聽起來很漂亮，問題出在我把合成圖丟給解碼器的時候。我用 jsQR 和 ZXing 這兩套最通用的開源 QR 解碼器，去讀官網實際輸出的那張 PNG，兩套都讀不出任何一層的內容。為了排除官網渲染過程的嫌疑，我在本機照原始碼重建整套合成流程，把這條預設比例從 0 一路拉到 90 共七個值掃過一遍，結果相當一致。
| 預設比例滑桿 | 支付寶碎片層 | 微信底層 |
|---|---|---|
| 0% | 兩套解碼器都讀得出 | 讀不出 |
| 10% | 兩套解碼器都讀得出 | 讀不出 |
| 20% | 兩套解碼器都讀得出 | 讀不出 |
| 30% 起（含預設 50%） | 讀不出 | 讀不出 |
兩個取捨從這張表直接浮出來。預設比例調得越低，支付寶碼保留越完整、越容易被解出，代價是它的長條破口縮小，透出的微信碼圖案變多，微信層被干擾的程度上升；調得越高，兩層都逼近各自糾錯能力的極限。微信底層在我的測試裡全軍覆沒，七個設定值沒有一個讀得出來。QR Code 的三個定位角分別在左上、右上、左下，右下角放的是校正圖形；四分之一面積的連續覆蓋會同時壓掉校正圖形與時序圖形，這種整塊的連續損毀，對這兩套解碼器來說已經超出 H 級能救的範圍。
這裡要誠實畫一條界線。jsQR 和 ZXing 不是微信，也不是支付寶，商業 App 的掃碼引擎對受損條碼的容忍度通常比開源函式庫高，實際結果可能因手機型號、掃描距離、螢幕亮度而不同。我的測試證明的是「這個輸出的品質已經被推到邊緣」，沒有證明「微信和支付寶一定讀不出來」。但被推到邊緣的東西，在不同環境下就是會有人踩出去。
踩出去的人已經出現了，而且沒人回應他
GitHub issue 編號 2，2025 年 7 月 8 日開立至今，狀態開啟，零回覆。一位真實使用者回報，把合成碼圖片存進相簿、再用支付寶的選圖掃碼，支付寶鎖到了底下那層微信碼，跳出「無法處理微信的二維碼」的錯誤訊息。對照 README 裡作者宣稱的「極少數情況下可能誤解析，機率小於 0.5%」，機率數字本身無法驗證，但方向比數字更要緊：支付寶讀到微信碼、微信讀到支付寶碼，任何一個方向出錯，客人站在攤位前就是掃不出來，而那個當下沒有 workaround，只能道歉重收。
翻文件還翻到一個更實際的落差。README 的調參建議寫「支付寶碼覆蓋比例建議初始 30% 到 40%」「旋轉角度可正負 10 度微調」，可是這兩個參數在程式碼裡不存在。旋轉角度寫死 180 度，預設版面的碎片大小寫死在 50%，介面能動的只有那條預設比例滑桿，外加幾組換湯不換藥的固定主題版型，同樣沒有覆蓋率或角度可調。照著官方文件除錯的人，會在頁面上找不到他要調的東西。文件與實作脫節到這個程度，通常意味著專案在快速收尾後就沒再回頭維護文件。
列印前的驗收，比生成多花你兩分鐘
如果你決定用，流程照這樣走會穩得多。生成之前，先把預設比例滑桿從出廠的 50% 往下調，我實測 20% 以下支付寶層就能讓標準解碼器順利讀出，這是個有實測依據的起點。合成圖下載後，先在螢幕上用微信和支付寶各掃一次，兩邊都要跳到正確的付款畫面。列印出來之後再掃一次紙本，墨色深淺和紙張反光都會影響辨識，螢幕上能掃不代表紙上能掃。掃進付款畫面時多看一眼收款人名稱是不是你自己，這是所有靜態收款碼共通的安全習慣，跟合不合成無關。
驗收失敗的處理方式也要先想好。微信掃不出來，通常代表疊加的支付寶碎片干擾太強，把預設比例再往下調一格重新生成；支付寶掃到微信碼，就是 issue 裡那個情境，同樣把滑桿往下調再試。同一組參數試到第三版仍然有一邊失敗，我的建議是放棄合成，回到兩張分開的收款碼，一張圖的省事，不值得賠上客人結帳的那三十秒。
另外兩個使用邊界先說清楚。它只能合兩個碼，想再加第三種付款方式，這工具幫不了你，那類需求要走雲端動態碼服務，代價是伺服器與月費，屬於另一個品類的取捨。它的輸入白名單只認前面提過的四種網址格式（子字串比對，不算嚴謹的網域檢查），所以你沒辦法拿它合任意兩個 QR Code，例如官網連結加表單網址的組合，支付寶欄位會直接拒收，而 README 宣稱的「官網、表單等多場景通用」在程式碼裡根本不成立，這也是文件與實作脫節的另一處；拿 QR Code 做其他用途的場景（例如 PrintRelay 掃碼傳檔那種臨時通道）也有各自更合適的工具。
授權狀態與專案體質
倉庫 2025 年 4 月 30 日建立，開發只活了兩週，最後一次推送停在 2025 年 5 月 14 日；至今累積 840 顆星、178 個 fork，星數與 fork 在這一年多持續緩慢增加，正式版卻一個都沒發過。倉庫裡沒有 LICENSE 檔，GitHub 的授權欄位顯示 None，法律上的意思是「原始碼看得到，但作者沒有授予使用、修改、再散布的權利」。自己用通常沒人追究，想商用或改作發行，授權狀態是未定數，嚴格來說應該先取得作者同意。作者在官方頁面掛了一個 vvhan 造訪統計腳本，會送出頁面路徑與來源 referrer 這類基本資訊，只在官方網域生效，原始碼註解也標明可自行移除；真的在意，一鍵部署到自己的 Vercel 或 Cloudflare Pages 帳號就沒有這段了。不過部署到 Cloudflare 曾有人回報白屏，那條 issue 後來結案，回覆裡留了一行解法線索（框架預設要選 Vue），自架前仍要有動手排查的心理準備。
誰該用，誰該繞開
該用的人：你同時收微信和支付寶，列印需求是長期的（店貼、攤位、海報），你願意在列印前花兩分鐘做雙 App 驗收，而且滑桿調低後兩邊都掃得動。這個情境下它是零成本、零帳號、圖片不出門的乾淨解法。該繞開的人：你需要三種以上的付款方式，或你需要金額可變的動態碼，或你就是不想承擔「客人掃不出來」的任何機率，後面兩種情境雲端活碼服務雖然要錢，穩定性至少有人扛。工具本身的誠實度我給高分，原始碼攤開跟你看到的行為一致，宣稱離線就真的離線；輸出的可靠性我給的是附條件的及格，條件就是你願意當自己的品管。
