隨機、自選與歷史記錄會互相影響嗎？本站產生器逐步程式核對

先沿着一次按鈕操作追查

按下「開始攪珠」後，程式先清除上一輪計時器和畫面結果，再建立一個新的 LuckyDrum。一般隨機模式的 drum 只有一項初始資料：1 至 49 的完整陣列。它沒有接收上一組結果、官方歷史結果、熱門號碼表或使用者以前的選擇。

每抽一球，程式在目前陣列長度內選一個索引，取出該位置的號碼，再用 splice 從陣列刪除。第一球由 49 個位置選，第二球由剩下 48 個位置選，如此類推。刪除動作保證同一組內不會再抽到已取出的號碼，這種做法稱為無放回抽取。

畫面滾動號碼與正式結果是兩條流程

抽取期間，畫面會快速顯示不同號碼，營造攪珠效果。這些動畫號碼每隔一段時間獨立取得，只寫入 currentShuffleNumber 作顯示。動畫停止後，程式才呼叫 drum.draw() 取得正式結果；currentShuffleNumber 從未傳入號碼池，也不會被當成候選號碼。

這個分隔很重要。若使用者看到動畫曾出現 4，最後結果又有 4，那只是兩次獨立取值恰好相同，不是動畫把 4 推入結果。相反，即使動畫從未顯示某號碼，它仍可在正式抽取時被選中。

一般隨機與三種自選情況

自選模式不是一律「把選中的號碼加進結果」，要視你選了多少個及目標需要多少個。

例如目標為 6 碼而你自選 3、7、19，程式先把三碼放進結果，亦從 1 至 49 的池中刪除它們，再抽另外三個，所以同組不會重複。若你自選十個號碼而目標仍是六個，候選池就只有該十個，結果不可能出現清單以外的號碼。

切換回一般隨機模式時，自選陣列會清空。每次重新開始亦會建立新 drum；它不會沿用上一輪抽剩的 43 個號碼。

亂數來源與取餘數問題

程式使用瀏覽器 window.crypto.getRandomValues() 取得 32 位元無符號整數，範圍由 0 至 4,294,967,295。它不是 Math.random()，亂數材料由瀏覽器和作業系統提供。MDN 將 getRandomValues() 定位為可取得具密碼學強度亂數值的介面，但實際來源仍由瀏覽器實作；本站沒有聲稱它等同或模擬香港賽馬會的實體攪珠機。

若直接把所有 32 位元值除以 49 取餘數，因為 2³² 不能被 49 整除，部分餘數會比其他餘數多對應一個原始值。差距極小，但程式仍將它消除：先找出不超過 2³²、又可被目前池大小整除的最大界線；落在界線以上便捨棄並再取一個值。池大小為 49 時，尾段共有 39 個值會重取。號碼池縮至 48、47 時，界線亦會重新計算。

歷史號碼到底存在哪裡

首頁下方的最近記錄使用瀏覽器 localStorage，鍵名為 lucky_six_history，最多保留 12 組。程式只在整組狀態變成 COMPLETED 後寫入；開始新一輪的 handleStart 沒有讀取 history。刪除畫面記錄也只改 localStorage，不會觸及亂數函式。

官方歷史結果則由結果頁的資料模組取得，與 Machine 元件分開。Machine 沒有 import 結果快照，也沒有接收熱號、冷號或上期號碼參數。因此目前程式結構中不存在「歷史結果改變一般隨機權重」的路徑。

不同組重複，正是獨立抽取容許的結果

每組內不重複，不等於不同組之間必須完全不同。新一組重建 49 號碼池後，與上一組至少共享一碼的理論機率是 1 − C(43,6) ÷ C(49,6) = 56.4%。若程式強迫下一組避開上一組六碼，看起來會「更隨機」，實際上卻把第二組池縮成 43 個，改變了每個號碼原本的機會。

自動測試能證明甚麼，不能證明甚麼

現有測試會檢查四類事情：輸出必須在指定範圍；同一號碼池抽取不重複；遇到會造成取餘數偏差的尾段值時確實重取；大量重複操作時，各候選號碼的入選次數沒有明顯偏離預期。它也分別測試完全隨機、自選後補齊、以及從較大自選池抽取的流程。

測試不能「證明未來每一組都看起來平均」。以 1,000 組六碼為例，每個指定號碼平均入選 122.45 次，標準差約 10.37 次；有人較多、有人較少才是正常結果。若 49 個號碼剛好全部一樣多，反而不可能，因為 6,000 不能平均分成 49 份。

更重要的是，自動測試只核對我們寫下的性質，不是第三方安全認證。讀者可查看方法論、實際重複率的歷史研究，以及 MDN 的 Crypto.getRandomValues 說明。若日後抽取程式改動，這頁和相應測試亦必須一起更新。