MAC 地址前 3 字节是 IEEE 统一分配的厂商代码 OUI，后 3 字节由厂商自行规划。这条规则让前缀变得可以被校验：系统声明的品牌、设备类型一旦和它对不上，矛盾就出现了。
提到 MAC，很多人第一反应是苹果电脑。其实 MAC 地址跟苹果没有关系，它是网络设备的物理层标识符。
对做多账号运营的人来说，它值得关注的地方在于：这串地址有一套全球统一的生成规则，而只要有规则，就意味着可以被校验。
一串 48 位的硬件标识
MAC 地址由 48 位二进制组成，通常写成 12 位十六进制，例如 00:1C:B3:XX:XX:XX。
名字里的 MAC 指 Media Access Control，说的是数据链路层，和苹果那个 MAC 只是拼写撞了车。它的常规用途在局域网内部：交换机根据地址判断数据帧该送到哪个端口，路由器用它做白名单或黑名单，企业网、校园网也常拿它来识别设备身份。这些场景跟账号风控本来没有关系。
前 3 字节是厂商代码，这就是 OUI
这 12 位十六进制分成两段。
前 3 字节，也就是 6 位十六进制，是厂商专属代码，行业内叫 OUI，由 IEEE 统一分配，每个厂商拿到的号段是固定的。后 3 字节由厂商自行规划，用来保证同一个品牌下不同设备之间不重复。
两段合起来，就构成了 MAC 地址的全球唯一性，和每台手机有专属 IMEI 是同一个道理。也正因为前缀是分配的、有据可查的，它才成了一个可以被拿来做交叉校验的字段。
读不到，不等于串不起来
有必要先说清一点：浏览器层面读不到 MAC 地址。
不少人据此认为读不到就等于安全，这个推论并不成立。风险从来不在能不能读到，而在于同一个标识会不会被重复使用、被串在一起。
真正会出问题的是两种情形。一种是用同一套硬件，或者简单克隆的虚拟机、云环境，导致多个账号背后是同一条 MAC 标识，你以为做了隔离，网络层的标识还绑在一起。另一种是远程协同：团队成员用各自的设备通过远程工具操作同一批账号时，不同设备的链路可能出现交叉，让原本无关的环境产生关联线索。
对不上时，矛盾长什么样
如果一台设备的系统信息声明自己是某品牌，而地址前缀对应的却是另一家厂商，这就是一个很直白的逻辑冲突。类似的还有几种：
- 系统声明的设备类型（台式机、笔记本、移动端）与地址前缀不匹配
- 多个环境的地址前缀高度集中，看起来像同一批设备
- 后 3 字节呈现明显规律，而不是随机分配
单个地址拿出来看都没有问题，放进环境的一致性里看，矛盾才浮出来。
哪些改动合理，哪些会自相矛盾
这里要分清两种改动。
一种是工程规划层面的。虚拟机、容器、批量部署的镜像，本来就有一套自己的地址分配方案，在同一套规划里给设备分段、编号，是常规做法——只要前后规则一致，就不会产生矛盾。
另一种是真的自相矛盾的。把系统信息声明成一家厂商，地址前缀却指向另一家；把一批环境的地址都规划进一个很小的前缀范围；把后 3 字节排成连续序号。这几种改动的共同点是：它们破坏了参数之间原本的对应关系，改动动作本身反倒成了异常信号。
标识不重复，本来就是隔离的一部分
在多账号管理里，环境隔离要做到的不只是数据不互通，还包括标识不重复。
PurpleMark 在浏览器环境这一层对包括设备标识在内的多项参数做独立配置，目标是让每个环境在平台侧看起来是一台独立设备。重点不在于单项参数多特别，而在于多个环境之间没有逻辑上的冲突。
自查不用专业工具，把 MAC 一致性放进环境检查清单，和 WebRTC 泄露检测、指纹一致性检查一起做就行。看四项：地址前缀与系统声明是否属于同一厂商、多环境之间的前缀分布有没有合理差异、后 3 字节有没有明显规律、时区与语言和分辨率是否同向匹配。
以上内容仅作技术原理说明，请在合法合规前提下使用相关工具并遵守各平台服务条款。
