大麥搶票腳本 ticket-purchase 把下單交給它，登入付款自己來

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

先把結論說完。ticket-purchase 是 GitHub 上一個超過七千顆星的開源專案，用 Python 把大麥網的購票流程自動化：你把目標演出、城市、場次日期、票價、觀演人寫進設定檔，它負責在開票前後反覆刷新頁面、偵測可購按鈕、選好場次與票價、把觀演人填進訂單、送出。這條流水線的起點和終點都留給你：登入要你本人拿手機掃碼，付款要你自己按。從原始碼逐段看下來，它做得最扎實的是「替你守在電腦前反覆點」這段中間工程，而搶不搶得到票，決定權多半不在它手上。

這個專案值得認識的理由有兩個。想搶演唱會門票的人，需要先弄清楚它的能力邊界在哪、哪些熱門場次它無能為力；想學瀏覽器自動化的人，這是一份現成的完整教材，同一個目標、兩種路線（Selenium 驅動電腦版網頁、Appium 驅動 Android 手機 App），從登入、輪詢、重試到送單的每一步都有程式碼可以對照。下面按這兩條線把細節攤開。

從原始碼看，它把「守在螢幕前點滑鼠」這段全包了

網頁版的主流程寫在 concert.py 裡，結構很直白。你先在 config.json 填目標演出的網址、城市、場次日期、票價、觀演人名單，以及兩個開關：if_listen 決定要不要在缺貨時登記候補，if_commit_order 決定選完票之後要不要自動送出訂單。啟動後它先處理登入，這一步沒有任何自動化魔法：程式先打開大麥首頁，等你點了登入、印出「請掃碼登入」的提示，然後停下來等你用手機掃。掃完之後它把瀏覽器裡的 cookie 存成檔案，下次啟動直接重用，省掉重複掃碼。也就是說，它從頭到尾都沒有去破解大麥的登入或驗證機制，用的是你本人的正式帳號。

設定檔本身值得多看兩眼，因為它決定腳本搶票的成敗。網頁版的日期和票價都可以填清單：日期給多個備選場次，票價從高到低排，搶不到最想要的就往下退；設定檔裡有 max_retries、預設一千，說明文件也說是重試上限，但輪詢迴圈的程式碼目前沒有引用它，實際上不會自動停，跑不完就得自己關終端。App 版的設定多一個 price_index，用數字指定第幾個票價，這個設計後面會看到原因，它牽涉到大麥 App 介面的一個小機關。另外觀演人名單直接寫本名，幾個人就要填幾個，這是實名購票的結構：票、證件、人要對得上，腳本沒辦法也沒必要繞過。

真正花功夫的是開票那一刻的輪詢。程式不斷刷新演出頁面，快速模式下每 0.3 秒一次，一般模式 1 秒一次，每次刷新都檢查購票按鈕的文字有沒有變化。按鈕顯示「立即預訂」或「立即購買」就立刻點下去；顯示「缺貨登記」而你開了候補功能，就點登記；遇到「選座購買」的場次，也有對應的選座分支。點下去之後，它接著把訂單確認頁的觀演人、票數一一填好，按送出。整條判斷鏈在程式碼裡是一個 while 迴圈加一串按鈕文字比對，任何人都可以打開讀，這也是它作為教材的價值：你能在百行以內看懂「搶票快」是怎麼被工程出來的。

Pin

送出訂單就是它的終點線。程式碼裡判斷任務完成的條件之一，是頁面文字出現「支付方式」，也就是訂單已成立、進到付款頁。接下來的付款它不做，也不該做：付款綁定你的支付帳戶，這一步本來就該人工確認。所以更準確的描述是，它替你完成「從看到可購按鈕到訂單送出」的幾秒鐘，而這幾秒鐘正是人工搶票最容易手忙腳亂的地方。

網頁版與 App 版，是兩套完全不同等級的工程

這個專案其實裝了兩個子專案。damai 目錄是 2023 年 10 月建立的原版，用 Selenium 驅動 Chrome，環境需求最輕：裝好 Python 和 Chrome，剩下交給腳本。damai_appium 目錄是 2025 年 9 月由另一位作者加入的 App 版，用 Appium 加 UiAutomator2 驅動 Android 手機裡的大麥 App，環境門檻高出一截：Node.js、Android SDK、Appium 伺服器、模擬器或開了偵錯模式的真機，一樣都不能少。兩條路線共用同一套設定概念，但程式碼各自獨立。

先補兩個名詞。Selenium 是自動化操作瀏覽器的老牌工具庫，程式碼告訴它「找到這個按鈕、點下去」，它就代替你的手在 Chrome 裡動作；Appium 做的是同一件事，只是操作對象從瀏覽器換成手機 App。App 版的搶票主流程分七步：選城市、點預約按鈕、選票價、點加號把數量加到觀演人數、確定購買、逐一勾選觀演人、提交訂單。每一步都用最短等待加座標點擊實作，點擊動作壓到 50 毫秒，勾選兩個觀演人之間只停 0.01 秒，跑完還會印出整趟耗時，讓你知道自己輸在哪一步。

票價那一步藏著一場小小的軍備競賽。程式註解寫得明白：大麥 App 的票價元素文字是空的、被隱藏起來，靠文字比對找不到，腳本只能改用位置索引去抓第幾個票價區塊。這解釋了設定檔裡 price_index 的用途，也解釋了為什麼這類腳本特別怕 App 改版：平台把版面動一下，索引就全部錯位，維護者要重新數一次位置。使用者反映的「App 版邏輯跟不上現在大麥」，多數時候就是這種錯位的症狀。

為什麼要養兩條路線？因為大麥的場次銷售渠道會鎖端。有使用者在 issue 反映網頁版買不了、頁面提示要改用 App 掃碼購買，也有人發問是不是部分票只在 App 端開賣；另有網頁版使用者遇到只能購買一張的限制。渠道規則由平台決定且會變動，這正是 App 版存在的理由，也是部署前該先查清楚的第一件事：你的目標場次，到底在哪一端開賣。

七千顆星，量的是想搶票的人數

截至 2026 年 8 月，這個專案有 7,096 顆星、880 次 fork，對一個只針對單一購票平台的腳本來說，這個數字相當搶眼。不過星數量測的是需求，打開 issue 列表會看到另一種圖像。不斷有人問「有人真的搶到票了嗎」，也有留言請作者公布交流群的連結；同一時間，2025 年 10 月有一則被討論了 23 層的長文，作者花了三個小時把網頁版和 App 版都部署過一輪，結論是不建議使用：網頁版在開票後仍然持續刷新、遲遲不進入搶票流程；App 版的邏輯跟不上當時的大麥 App；沒有定時開售功能，腳本一啟動就開始跑；卡在選座頁面無法送單；沒有退票再上架的監控；跑完之後手機的輸入法被換掉、系統動畫全部消失，要自己手動復原。他最後沒搶到那場音樂會的票，並在文末感嘆試了好幾個 GitHub 上的同類腳本，好像沒有一個能用。

Pin

這則證言不必當成定論，留言裡也有人分享把腳本大幅改寫、加上倒數計時與自動選座之後成功搶到票的經驗，但它指出了這類專案的共同處境：平台在改版，腳本在追趕，中間永遠有時間差。專案自己的文件也有同樣的痕跡，README 頁尾寫著最後更新 2024 年 10 月，實際的提交紀錄卻到 2026 年 5 月都還有，修的是 Windows 上 ChromeDriver 的安裝問題；再往前一次較大的改動是 2026 年 2 月的網頁版重構。維護是間歇式的，文件落後程式碼，部署教學裡有些指令只照顧到 Mac。連專案的 pyproject.toml 裡，作者欄位都還是範本預設的 Your Name，學習專案的本色很誠實。

它要打的是大麥的服務端，跟你的手速關係不大

搶票腳本的真正對手，從來都在伺服器那一端。有使用者在 issue 反映，一般場次可以正常下單，遇到搶手的場次，訂單就被平台以「同一時間下單人數過多，建議您稍後再試」擋下，錯誤代碼以 F-10012 開頭；他反覆測試後仍不確定問題出在帳號還是 IP，留言裡有人猜 IP 純度、有人猜設備端被封控；可以確定的是這種擋單發生在服務端，客戶端點得再快也繞不過去。另有使用者反映在 Android 模擬器上經常遇到「訪問被拒絕」頁面，從症狀推測與平台對模擬器環境的偵測有關。把這些線索放在一起看，結論很清楚：0.3 秒刷新一次能幫你搶在別人前面把訂單送進去，但訂單進去之後排在第幾位、會不會被風控攔下，是平台說了算。

這也是我看這個專案時覺得最有價值的一課。它把「搶票」這件事拆開攤在程式碼裡：客戶端能做的只有快和準，而快和準的上限，早在你按下執行之前就被服務端的排隊、渠道和風控畫好了。理解這一層，比期待一個腳本幫你贏下熱門演唱會的門票更實際。

帳號風險與授權狀態，部署前先看清楚

作者在 README 的注意事項裡寫得很白：請遵守大麥網的使用條款，合理使用自動化工具，並建議使用專門的測試帳號。大麥官網底部設有「協議及隱私權政策」連結，平台對自動化下單的具體規範，以條款現行版本為準，這條線每個使用者要自己評估。可以確定的是，腳本登入的是你本人的實名帳號，觀演人也要綁定真實身分，一旦帳號被平台標記，影響的是你之後的正常購票。這類「用客戶端工具對平台做自動化」的帳號風險，在閒魚聊天記錄匯出工具那類專案也遇過同樣的提醒，值得當成同一個家族的共性來理解。

授權方面要注意一個細節：整個 repo 沒有任何 LICENSE 檔案，作者只在 README 宣告「本專案僅供學習和研究使用，請勿用於商業用途」。在著作權預設規則下，沒有授權條款代表權利仍由作者保留，你可以讀、可以跑，但把程式碼改作再散布，要先取得作者同意。想深入玩瀏覽器自動化的人，可以把它和用 AI 操作瀏覽器抓網頁資料的 BrowserAct、在手機上做 Android 自動化的 AutoGLM 這類工具對照著看，一個是寫死的腳本路線，一個是模型驅動的通用路線，兩種思路剛好互為鏡子。

誰該花一個晚上部署它

如果你的目標是學自動化，這個晚上花得值。clone 下來，從網頁版開始，環境最輕，照著 README 走到掃碼那步就能看到輪詢跑起來；再對照 concert.py 的按鈕判斷邏輯讀一遍，你會得到一段可以直接搬去別的搶購或監控場景的骨架。它附的測試檔案和環境檢查腳本，也讓它比多數同類專案更接近可維護的工程。

專案附帶的支援工程也做得比多數同類齊。倉庫裡附了快速上手文件、環境檢查腳本，一鍵啟動的 shell 腳本，還有 unit 測試和整合測試目錄，Windows 裝 ChromeDriver 會踩的坑在 2026 年 5 月被修掉。這些東西不會讓你搶到票，但會讓你少踩安裝的坑，對學習用途來說是加分的。

如果你的目標是下個月那場演唱會，先做兩件事再決定：去 repo 的 issue 列表看看最近一個月使用者反映的實際狀況，再確認目標場次在哪一端開賣。腳本能幫你的是把送單那幾秒做到零失誤，不能幫你的是排在幾萬人前面，也不能保證帳號安然無事。把期待放在這條線上，這七千顆星對你才是有用的七千顆星。

專案網址在 GitHub 上的 WECENG/ticket-purchase，採 Python 開發，網頁版與 App 版雙路線，最後提交 2026 年 5 月，未隨附授權條款。