拓元系統 五月天 2020~2021 演唱會 搶票紀實

(本文僅分享拓元系統搶票心得，不提供任何搶票程式、工具或程式碼。)

拓元系統從 2017 年 還不需要實名制，演進至今，已規定每個帳號都必須綁定 身分證+手機號碼 認證，在帳號建立階段就已經可以過濾掉一些黃牛與潛在機器人帳號。不過搶票僧多粥少的情形，仍要視各活動場次規模、票數多寡而定。

坊間上的許多機器人或自動化教學，其實都是把握一個大原則：加快輸入程序。
至於導入 OCR 、 機器學習去做驗證碼自動輸入，個人認為除非是長期的例行性工作，不然殺雞焉用牛刀，況且魔高一尺道高一丈，若機制更新了還要花時間重建model，CP值不高。(若原本就在做ML相關應用則無妨)

下方來說說拓元系統其中一個道高一丈的例子：在各種搶訂、搶票頁面中，往往都會出現的 "同意會員服務條款" checkbox，以往這類的 checkbox 都可藉由一般的自動化簡單處理掉。

然而，以下圖這個 checkbox input 的 name 為例，在勾選 checkbox 之前是 TicketForm[agrees] ，而要有實際觸發 onClick ，才會產生一組隨機亂碼並重新命名成 TicketForm[agree][亂碼]。
在帶有亂碼的狀態下，再去點選 [確認張數] 才會真正順利送出訂購資訊，否則只是不斷鬼打牆、回到選擇張數頁面。

只要手動勾選過同意條款，checkbox input 的 name ，可看到隨機產生的特殊亂碼。

藉由自動化工具勾選 checkbox，因為沒有 onClick，所以帶出的 name 是 ”s_false_undefined”

沒有帶到隨機亂碼打出去的 POST，只會回到訂票選擇張數頁面。

手動勾選同意條款並有產生的隨機亂碼，打出去的 POST 才會真正進到訂票流程。

送出訂票資訊，並付款完成訂票。

由於目前常見的售票系統流程設計，在配票後會保留結帳時間，因此，只要前面的過程有比別人早一點完成，剩下就是希望伺服器不要出錯、網路順暢，這樣子能夠順利配到票、進到結帳流程倒數計時的機會就大些。

即便是手動訂票，仍會出現的常見錯誤

每 5 秒做一次 GET，最後才說沒連續座位 / 沒票了

最後一次回報 waiting: false

在配票機制這方面，拓元的設計就不如 KKTIX 了，只要中途碰到 無預期的錯誤 或是 無連續座位 / 無足夠座位，整個流程就會踢掉全部重來。
那這個瞬間要是有空位多出來，反而會給原本在後面的人撿走。這是相當差的 UX 設計。(尤其是無連續座位這一點，沒有連續座位又不代表不買...)

後面這個階段，自動化工具能幫助的其實就相當有限，因此整個搶票過程的焦點仍會著重在前述的各種魔高一丈道高一尺的追逐戰。

技術含量不多，一個簡單的搶票心得分享。