MAC 位址前 3 位元組是由 IEEE 統一分配的廠商代碼 OUI，後 3 位元組由廠商自行規劃。這項規則讓前綴可以被校驗：系統聲明的品牌或裝置類型一旦與它對不上，就會出現矛盾。
提到 MAC，很多人第一反應是 Apple 電腦。其實 MAC 位址跟 Apple 沒有關係，它是網路裝置的實體層識別碼。
對做多帳號營運的人來說，值得注意的是：這串位址有一套全球統一的生成規則，而只要有規則，就代表可以被校驗。
一串 48 位元的硬體識別碼
MAC 位址由 48 位元二進位組成，通常寫成 12 位十六進位，例如 00:1C:B3:XX:XX:XX。
名稱裡的 MAC 指 Media Access Control，說的是資料連結層，和 Apple 的 Mac 只是拼寫剛好相同。它的常規用途在區域網路內部：交換器根據位址判斷資料框該送到哪個連接埠，路由器可用它做允許清單或封鎖清單，企業網路、校園網路也常拿它來識別裝置身分。這些情境原本跟帳號風險控制沒有關係。
前 3 位元組是廠商代碼，也就是 OUI
這 12 位十六進位分成兩段。
前 3 位元組，也就是 6 位十六進位，是廠商專屬代碼，業界稱為 OUI，由 IEEE 統一分配，每個廠商拿到的號段都是固定的。後 3 位元組由廠商自行規劃，用來確保同一品牌下不同裝置之間不重複。
兩段合起來，就構成 MAC 位址的全球唯一性，和每支手機都有專屬 IMEI 是同一個道理。也正因為前綴是分配的、有據可查的，它才成為可用來做交叉校驗的欄位。
讀不到，不等於串不起來
有必要先說清楚一點：瀏覽器層面讀不到 MAC 位址。
不少人因此認為讀不到就等於安全，但這個推論並不成立。風險從來不在能不能讀到，而在於同一個識別碼會不會被重複使用、被串在一起。
真正會出問題的是兩種情形。一種是使用同一套硬體，或簡單複製的虛擬機器、雲端環境，導致多個帳號背後是同一條 MAC 識別碼；你以為做了隔離，網路層的識別碼卻還綁在一起。另一種是遠端協作：團隊成員用各自的裝置透過遠端工具操作同一批帳號時，不同裝置的鏈路可能出現交叉，讓原本無關的環境產生關聯線索。
對不上時，矛盾長什麼樣
如果一台裝置的系統資訊聲明自己是某品牌，而位址前綴對應的卻是另一家廠商，這就是很直接的邏輯衝突。類似的還有幾種：
- 系統聲明的裝置類型（桌上型電腦、筆記型電腦、行動裝置）與位址前綴不匹配
- 多個環境的位址前綴高度集中，看起來像同一批裝置
- 後 3 位元組呈現明顯規律，而不是隨機分配
單個位址拿出來看都沒有問題，放進環境的一致性裡看，矛盾才會浮現。
哪些改動合理，哪些會自相矛盾
這裡要分清兩種改動。
一種是工程規劃層面的。虛擬機器、容器、批次部署的映像檔，本來就有一套自己的位址分配方案，在同一套規劃裡替裝置分段、編號，是常規做法——只要前後規則一致，就不會產生矛盾。
另一種是真的自相矛盾。把系統資訊聲明成一家廠商，位址前綴卻指向另一家；把一批環境的位址都規劃進很小的前綴範圍；把後 3 位元組排成連續序號。這幾種改動的共同點是：它們破壞了參數之間原本的對應關係，改動動作本身反而成為異常訊號。
識別碼不重複，本來就是隔離的一部分
在多帳號管理裡，環境隔離要做到的不只是資料不互通，還包括識別碼不重複。
PurpleMark 在瀏覽器環境這一層，對包括裝置識別碼在內的多項參數做獨立設定，目標是讓每個環境在平台側看起來都是一台獨立裝置。重點不在於單一參數多特別，而在於多個環境之間沒有邏輯上的衝突。
自我檢查不需要專業工具，把 MAC 一致性放進環境檢查清單，和 WebRTC 洩漏檢測、指紋一致性檢查一起做就行。看四項：位址前綴與系統聲明是否屬於同一廠商、多個環境之間的前綴分布有沒有合理差異、後 3 位元組有沒有明顯規律、時區與語言和解析度是否同向匹配。
以上內容僅作技術原理說明，請在合法合規前提下使用相關工具，並遵守各平台服務條款。
