企业官网建设流程全解析

做嵌入式网络的朋友大概率都遇到过这种局面：一批小板子刷完固件接进同一个交换机，抓包一看，好几台设备的源 MAC 一模一样，DHCP 服务器的租约表里同一个地址被反复抢占，交换机的 MAC 表在两三个端口之间来回抖动，日志刷得飞快。这种问题的根子往往不在协议栈，而在于 MAC 地址压根就没被认真分配过——很多小设备为了省成本，干脆在代码里写死一个00:11:22:33:44:55，或者把 MAC 存在外部 EEPROM 里，产线漏烧一批就全军覆没。我这次要聊的，就是绕开存储介质，直接拿芯片出厂自带的 UID 派生 MAC 的做法：嵌入式设备无存储MAC生成方案：基于UID的确定性哈希算法。核心诉求很朴素——不占一个字节的 Flash 或 EEPROM，同一颗芯片每次上电算出来的 MAC 必须完全一致，不同芯片之间撞车的概率要低到可以接受，同时生成的地址在 IEEE 802 的规则下是合法的、不会跟真实厂商的 OUI 打架。这套东西适合谁？适合做小批量物联网终端、工业采集节点、自研网关、以及任何 BOM 成本已经压到几毛钱、实在塞不下一颗存储器的团队。下面我按方案选型、算法细节、代码落地、现场踩坑四块展开，代码可以直接抄。

1. 先把问题拆开：为什么MAC要“算”而不是“存”

1.1 传统三种存法的成本账

给设备分配 MAC，行业里长期在用的无非三条路。第一条是产线烧录，用烧录器把 MAC 写进 MCU 的 Flash 或者一次性 OTP 区域，优点是直观可控，缺点是产线多一道工序，而且 OTP 烧错了这颗芯片基本就报废，返修率稍微高一点成本就上去了。第二条是外挂一颗小容量串行 EEPROM，几百字节那种，产线写一次，主控读出来用，好处是换主控不用重烧，坏处是 BOM 上多一颗料、多两根走线、多一个上拉电阻，量大之后这笔钱很扎眼，而且 EEPROM 本身也有擦写寿命和掉数据的问题，工业现场强干扰环境下 I2C 总线被拉死、读出全 0xFF 的情况我见过不止一次。

第三条最原始，贴标签人工录入，或者干脆在固件里写死。写死的问题不用多说，两台设备同时上线就是地址冲突；人工录入的问题在于错一位数你根本发现不了，等设备装到现场、跑了三个月，运维突然说某片区域的设备集体掉线，回头查才发现是两台机器 MAC 相同导致交换机端口反复学习。这三种方式有个共同点：MAC 是“外部赋予”的，一旦这个赋予环节出错，设备自己没有任何纠错能力。

1.2 UID 这条路省掉的到底是什么

芯片出厂时，厂商通常会在某个只读区域烧一组唯一编号，业内一般叫 UID、Unique ID 或者 Device ID。它的构成一般是晶圆批次号、晶圆片号、芯片在晶圆上的 X/Y 坐标，有的还会加上版本号和校验位。长度不统一，常见的是 96 位，也有 128 位和 64 位的。这组数据的特点是：只读、出厂即定、同一型号内基本唯一、不占用用户可编程空间。

所以“无存储 MAC”的本质，是把 MAC 的生成责任从“产线工序”转移到“设备自己”。设备上电，读 UID，跑一个固定的算法，得到一个 48 位的值，塞给协议栈。省掉的是产线工位、烧录时间、外挂器件和人工核对，代价是你要把算法的正确性责任扛在自己身上——算法写错，问题会以“网络间歇性抽风”的形式出现在最不容易排查的层面。

1.3 MAC 地址 48 位里哪些位碰不得

很多人第一次做这件事，直接把 UID 的低 6 个字节拷进 MAC 数组就完事了，结果设备一上线，路由器认为这是个组播地址，包全被丢掉。48 位 MAC 有两个位是硬性规定，必须掰扯清楚。

第一个字节的最低位是 I/G 位，也就是单播/组播标志。0 表示单播，1 表示组播。设备网卡的地址必须是单播，所以这一位必须是 0。第一个字节的次低位是 U/L 位，全称 Universal/Local，0 表示这是一个全球唯一地址，由 IEEE 分配 OUI；1 表示这是一个本地管理地址，由使用者自己在本地网段内保证唯一。

我们要用的是后者。原因很直接：全球唯一地址需要向 IEEE 注册 OUI，一个 OUI 要花钱，而且我们本来就没有全球唯一的保证能力。用本地管理地址，等于明确告诉网络里的其他设备“这个地址只在当前二层域内有意义”，不会去占用别人花钱买来的号段。代价是这类地址不能跨路由域使用，也不能对外声称全球唯一，但在设备只在内网、局域网、私有部署环境里跑的绝大多数场景下，完全够用。

除了这两位，还有几个地址是绝对不能生成的：全 0 的00:00:00:00:00:00，全 F 的FF:FF:FF:FF:FF:FF（这是二层广播地址），以及某些协议栈内部保留的地址。生成完之后必须做一次兜底检查。下表把关键位整理了一下，配代码的时候对照着看。

1.4 UID 的唯一性边界在哪里

UID 能当唯一标识用，但这个“唯一”是有边界的，必须说清楚。第一，它只在同一型号、同一厂商的芯片序列内保证唯一，换一个芯片型号，两边的 UID 完全可能重复，所以如果一条产品线上混用了两种主控，哈希的输入里最好把型号标识也混进去，否则跨型号撞车。第二，部分低端芯片的 UID 并不是真正烧录的唯一值，而是由内部某些模拟参数拼出来的，一致性尚可，唯一性打折，这种芯片拿来做 MAC 派生就要谨慎，最好在小批量阶段抽样验证。第三，UID 的读取接口和字节序，各家实现差异很大，有的给三个 32 位字，有的给字节数组，有的手册上写的是大端顺序但内存里是小端布局，这个坑后面单独讲。

2. 四条技术路线怎么选

2.1 路线一：直接截取，最省事也最容易翻车

从 UID 里挑 6 个字节直接用，改一下第一个字节的两位，收工。这条路线在极短时间内就能写完，但它有两个致命问题。第一个是位段选择：如果你截取的是 UID 的高位，同一晶圆批次、甚至同一片晶圆上的芯片，高位往往完全相同，因为批次号和片号是共用的，差异只在低位的坐标上。结果就是一整批设备算出来的 MAC 一模一样，产线测试时看不出来，装到现场才炸。反过来，如果你截取低位，虽然能区分开，但会得到一串连号的地址，02:00:00:00:00:01、02:00:00:00:00:02这样一路排下去。

连号本身不违规，但会带来两个现实麻烦。一是运维视角下设备数量一览无余，有些场景不太希望这样；二是部分上游网络设备会对连续的客户端地址做聚合或者限速策略，也有的无线控制器在做客户端计数和负载均衡时对连号地址有特殊处理，虽然不是普遍现象，但遇到了很难解释。更关键的是第二个问题：如果只截取 24 位，也就是 3 个字节，碰撞概率会高到不可接受，这个后面用数据说话。

2.2 路线二：双射变换，零碰撞但有前提

如果你对“绝对不撞”有洁癖，可以做双射变换。双射的意思是变换可逆、一一对应，输入不同则输出必然不同，不会引入新的碰撞。做法很朴素：从 UID 里挑出 46 个熵最高的位，做字节重排、异或一个固定常量、再整体循环移位。这三步都是可逆的，所以只要原始 UID 在这 46 位上不重复，输出就不会重复。

这条路线最大的优势是确定性极强，理论上零碰撞。但它有个前提：你得知道 UID 里哪 46 位是有区分度的。这需要看芯片手册，甚至需要拿一批实物读出来做统计。换个芯片型号，选位规则就得重做。而且纯异或和移位是线性运算，输出和输入之间存在可推导的关系，如果有人拿到两台设备的 MAC，理论上可以反推 UID 的部分信息。在绝大多数场景下这无所谓，但如果你介意，就还得再加一层非线性混淆，那又回到了哈希的路子上。

2.3 路线三：确定性哈希，普适性和碰撞率的折中

这就是本文的主方案。把 UID 的全部字节喂给一个哈希函数，输出压缩到 46 位可用空间，再拼成合法的 MAC。哈希的核心价值在于“雪崩效应”：输入改一个 bit，输出的每一位都有大约一半概率翻转。这意味着即便同一批芯片的 UID 只差最低位的几个数，生成的 MAC 在整个地址空间里也是散开的，不会连号，也不会聚集。

哈希函数的选择上有几个候选。CRC32 最省代码，但它有两个问题：一是它是线性的，输入微小变化对输出的影响是可预测的，达不到雪崩效果；二是只有 32 位，熵不够，我们后面会算这笔账。MD5、SHA-1 这类密码学哈希效果好，但代码体积和栈开销对资源紧张的 MCU 来说偏重，而且对一个 MAC 派生来说属于杀鸡用牛刀。FNV-1a 是个甜点：代码只有十几行，没有查找表，没有分支，不需要额外 RAM，32 位和 64 位版本都很成熟。它的缺点是雪崩不够彻底，尤其是低位对输入高位不敏感，所以后面要加一个雪崩收尾函数把分布拉平。

2.4 路线四：哈希加产测登记，工程上最稳

纯算法方案有个绕不开的事实：哈希是压缩映射，理论上必然存在碰撞，只是概率极低。如果你做的产品量比较大，或者对售后可追溯性有要求，我强烈建议在哈希的基础上再加一道产测登记：设备在产测工位上电后，把算出来的 MAC 打印出来或者写入标签，同时把 UID 和 MAC 的对应关系存进一张表。

这道工序的价值不只是防碰撞。设备卖出去三年，客户报修说某台机器网络异常，你拿到 MAC 就能反查 UID，进而定位到生产批次，这个能力在真实的售后场景里非常值钱。而且产测环节可以直接做重复检测，一旦发现表里已经有相同 MAC，立刻拦下来，把极小概率的碰撞挡在出厂之前。

3. 算法实现细节

3.1 输入归一化：UID 的字节序陷阱

这是最容易翻车的地方，我把它放在最前面。芯片手册上给的 UID 通常是一串十六进制，比如0x12345678 0x9ABCDEF0 0x11223344，三个 32 位字。但在 C 语言里，如果厂商提供的接口是返回一个uint32_t uid[3]，你在小端机器上直接memcpy到uint8_t数组，得到的字节顺序是78 56 34 12 F0 DE BC 9A ...，和手册上印的顺序正好相反。

这个差异本身不会导致碰撞，但会导致两个问题。一是调试时对不上，你按手册顺序算一遍、按内存顺序算一遍，得到两个不同的 MAC，怀疑人生。二是如果同一款产品在生命周期里换过工具链、换过芯片封装形式（比如从裸片换成模组），厂商接口的字节序可能变，算出来的 MAC 就跟着变，设备的 DHCP 租约、云端绑定、ACL 规则全部失效。

我的做法是写一层适配函数，统一按“手册上印的顺序”归一化成大端字节数组，长度统一成 12 字节。UID 长度不足 12 字节的，用固定常量补齐；超过 12 字节的，把多出来的部分异或折叠进前 12 字节。这样上层算法永远只面对 12 字节定长输入，换芯片只需要改适配层。

/* 平台适配层：返回归一化后的 12 字节 UID（大端顺序） */ int platform_read_uid(uint8_t uid[12]); /* 适配层内部示例：把三个 32 位字按手册顺序转成大端字节流 */ static void words_to_be_bytes(const uint32_t w[3], uint8_t out[12]) { out[0] = (uint8_t)(w[0] >> 24); out[1] = (uint8_t)(w[0] >> 16); out[2] = (uint8_t)(w[0] >> 8); out[3] = (uint8_t)(w[0] ); out[4] = (uint8_t)(w[1] >> 24); out[5] = (uint8_t)(w[1] >> 16); out[6] = (uint8_t)(w[1] >> 8); out[7] = (uint8_t)(w[1] ); out[8] = (uint8_t)(w[2] >> 24); out[9] = (uint8_t)(w[2] >> 16); out[10] = (uint8_t)(w[2] >> 8); out[11] = (uint8_t)(w[2] ); }

这里有个细节值得强调：不要用位域或者结构体强制转换去读 UID，编译器对位域的内存布局没有统一标准，换个编译器或者改个优化等级，结果就可能变。手工移位是最笨也最稳的办法。

3.2 位宽预算：46 位这个数字是怎么来的

48 位 MAC，扣掉 I/G 位和 U/L 位，剩 46 位可用。这 46 位怎么分配到 6 个字节上，有个取舍。常见的分配是第一个字节的高 6 位来自哈希，低 2 位放固定的10（二进制），也就是整个第一个字节满足xxxxxx10，第二到第六字节共 40 位全部来自哈希。这样总共 46 位熵，第一字节的取值会落在0x02、0x06、0x0A、0x0E、0x12一直到0xFE这个集合里，步长 4。

也有一种做法是第一个字节直接固定成0x02，只用后面 40 位。这样实现更简单，但熵从 46 位掉到 40 位，碰撞概率放大约 64 倍。数量小的时候无所谓，但既然 6 位熵是白送的，没理由不要。

为什么不在第一个字节里再塞一个算法版本号？因为版本号至少占 2 到 3 位，撞车概率直接乘 4 到 8，而且版本管理完全可以放在代码里、放在产测表里，没必要挤占宝贵的地址空间。真要区分算法版本，更应该通过“重算后与记录比对”的方式在生产环节发现，而不是体现在地址本身。

3.3 FNV-1a 的参数与雪崩收尾

FNV-1a 的两个参数是有讲究的。64 位版本的偏移基是0xCBF29CE484222325，质数是0x00000100000001B3。算法极其简单：对每个输入字节，先异或再乘质数。异或负责引入输入，乘法负责扩散。

但 FNV-1a 有个已知弱点：乘法是单向扩散的，低位的输入变化能影响高位，但高位的输入变化对低位的影响很弱。也就是说，输入只改最高字节，输出的最低几位几乎不动。如果直接拿输出的低 40 位当 MAC，而 UID 的变化恰好集中在高位，就可能出现 MAC 低位大量相同的情况。

解决办法是在 FNV-1a 之后加一个雪崩收尾函数。业内常用的是 splitmix64 的收尾部分：先右移异或，乘一个奇数常量，再右移异或，再乘一个奇数常量，最后再右移异或。这三步下来，任意一位输入变化都会扩散到输出的每一位，实测下来分布相当均匀。

static uint64_t avalanche64(uint64_t z) { z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ULL; z = (z ^ (z >> 27)) * 0x94D049BB133111EBULL; return z ^ (z >> 31); }

3.4 完整实现代码

把上面几块拼起来，得到一个可以直接用的版本。为了支持多网口，加了一个if_index参与哈希，同一台设备的不同网络接口会算出不同 MAC，避免两个接口用同一个地址导致协议栈内部混乱。

#include <stdint.h> #include <string.h> #define MAC_ALGO_VERSION 0x01u /* 算法版本，仅参与哈希，不写入地址 */ static uint64_t fnv1a_64(const uint8_t *data, uint32_t len, uint64_t seed) { uint64_t h = seed; for (uint32_t i = 0; i < len; i++) { h ^= (uint64_t)data[i]; h *= 0x00000100000001B3ULL; } return h; } static uint64_t avalanche64(uint64_t z) { z = (z ^ (z >> 30)) * 0xBF58476D1CE4E5B9ULL; z = (z ^ (z >> 27)) * 0x94D049BB133111EBULL; return z ^ (z >> 31); } /* * 从 UID 生成 6 字节 MAC * uid : 归一化后的 12 字节 UID，大端顺序 * if_index : 网络接口序号，单网口传 0 * mac : 输出缓冲区，6 字节 * 返回 0 表示成功 */ int mac_from_uid(const uint8_t uid[12], uint8_t if_index, uint8_t mac[6]) { uint8_t buf[15]; memcpy(buf, uid, 12); buf[12] = MAC_ALGO_VERSION; buf[13] = if_index; buf[14] = 0x5A; /* 域分隔常量，防止与其他用途的哈希混用 */ uint64_t h = fnv1a_64(buf, sizeof(buf), 0xCBF29CE484222325ULL); h = avalanche64(h); /* 取 46 位：低 40 位放入 byte1~byte5，高 6 位放入 byte0 的高 6 位 */ mac[1] = (uint8_t)((h >> 0) & 0xFFu); mac[2] = (uint8_t)((h >> 8) & 0xFFu); mac[3] = (uint8_t)((h >> 16) & 0xFFu); mac[4] = (uint8_t)((h >> 24) & 0xFFu); mac[5] = (uint8_t)((h >> 32) & 0xFFu); uint8_t hi6 = (uint8_t)((h >> 40) & 0x3Fu); mac[0] = (uint8_t)((hi6 << 2) | 0x02u); /* bit0=0 单播，bit1=1 本地管理 */ /* 兜底修正 */ mac[0] &= 0xFEu; /* 清掉组播位 */ mac[0] |= 0x02u; /* 确保本地管理位为 1 */ static const uint8_t zero[6] = {0, 0, 0, 0, 0, 0}; static const uint8_t bcast[6] = {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}; if (memcmp(mac, zero, 6) == 0 || memcmp(mac, bcast, 6) == 0) { mac[5] ^= 0x5Au; mac[0] |= 0x02u; } return 0; }

这段代码在 Cortex-M0 上实测，编译后代码体积不到 200 字节，栈占用不超过 32 字节，单次调用在 48MHz 主频下耗时大约 3 到 5 微秒。放在上电初始化阶段调用一次，性能完全不构成问题。注意h >> 40取的是第 40 到 45 位，正好 6 位，左移 2 位后落在 byte0 的高 6 位，低 2 位由| 0x02填成10，逻辑上是一致的。

3.5 碰撞概率到底多大，用数字说话

生日悖论的近似公式是P ≈ n² / (2 × 2^b)，其中 n 是设备数量，b 是可用位数。我们这里有 46 位，2^46约等于 7.04e13，2 × 2^46约等于 1.41e14。下面这张表是按这个公式算出来的实际碰撞概率，对比了几种常见位宽，一眼就能看出为什么不能偷懒。

这张表最该看的是 24 位那一行。很多“直接截取 UID 低 3 字节”的实现就是 24 位，1000 台设备撞车概率 3%，意味着你出一批一千台的货，平均三十批就会遇到一次地址重复，这个概率在工程上绝对不能接受。32 位也就是 4 字节，看着挺多，10 万台时接近一半的概率会撞，同样不够用。40 位是个分水岭，10 万台 0.45%，一百万台 44%，用在十万台以内的项目是可以接受的。46 位则把百万台级别的碰撞概率压到了 0.7% 以下，对绝大多数嵌入式项目完全够。

顺带说一句，这个公式是近似值，n 远小于 2^b 时精度足够；一旦算出来接近 1，就该用精确公式P = 1 - exp(-n(n-1)/(2×2^b))，否则会算出大于 100% 的荒谬结果。

4. 落地：从生成到协议栈挂载

4.1 调用时机与缓存策略

生成的时机很关键。必须在网络协议栈初始化之前，因为大多数协议栈在netif_add或者网卡初始化的那一刻就会读取硬件地址，之后就固定下来了，中途改地址轻则要重新初始化接口，重则导致已经建立连接的对端全部失效。

我的习惯是在main的最前面，紧跟着时钟初始化和串口初始化之后，就把 MAC 算出来存进一个全局数组，后面所有需要的地方都读这个数组。不要在每次发包时现算，虽然耗时只有几微秒，但万一某个调用点传错了if_index，同一台设备就会出现两个不同的 MAC，这种问题在现场极难定位——抓包看到两个地址，第一反应会以为是两台设备。更不要在中断上下文里算，没有意义，还增加了不确定性。

缓存还有一层价值：如果设备支持某种形式的低功耗休眠唤醒，唤醒后协议栈重新初始化，从缓存里拿同一个值，可以避免地址变化导致的连接重建。

4.2 多网口、多协议栈的域分隔

现在的设备很少只有一个网络出口。一个典型网关可能同时有以太网、Wi-Fi STA、Wi-Fi AP、蓝牙，甚至还有一路蜂窝模组。这些接口如果共用一个 MAC，会出现什么情况？Wi-Fi AP 模式下，设备自己作为一个软 AP，桥接到以太网时，如果两个接口 MAC 相同，桥接模块会直接拒绝转发，或者产生环路。

解决办法就是前面代码里的if_index。给每个接口分配一个固定编号，以太网是 0，Wi-Fi STA 是 1，AP 是 2，蜂窝是 3，编号参与哈希，天然得到不同的地址。这里的关键是编号必须固定且唯一，一旦发布就不能改，改了等于所有设备的这个接口换了 MAC。

还有一种情况是 AP 模式下为接入的客户端生成虚拟接口，这种通常不需要额外 MAC，直接用客户端的地址即可。蓝牙用的是随机地址机制，和 MAC 是两套体系，不要混用同一个哈希输入，否则容易在调试时把自己绕进去。

4.3 和 DHCP、IPv6、交换机行为的配合

MAC 定下来之后，下游还有一串连锁反应要照顾。

DHCP 客户端的 client identifier 字段，很多实现默认就是 MAC 加硬件类型，如果 MAC 稳定，租约就稳定，设备每次上电拿到的 IP 也稳定，这对现场调试非常友好。但如果你的协议栈里 client identifier 是另外单独配置的（比如用了设备序列号），那就要确保它和 MAC 的稳定性一致，否则会出现“MAC 没变但 IP 天天变”的怪现象。

IPv6 的链路本地地址，传统做法是从 MAC 按 EUI-64 规则扩展，中间插入FF:FE，同时把 U/L 位取反。这里有个容易搞混的点：EUI-64 里的 U/L 位取反，指的是“全球唯一地址的第 7 位取反”，而我们的 MAC 本来就是本地管理地址，取反后变成 0，生成的 IPv6 接口标识看起来像全球唯一地址。这不影响功能，但如果你用抓包工具看，可能会疑惑为什么地址的 U/L 位和 MAC 对不上。这是协议规定的行为，不是 bug。

交换机侧要留意的是 MAC 表容量和老化时间。设备数量多的时候，一台接入交换机的 MAC 表可能被占满，表现是新接入的设备流量泛洪。这种情况和你用不用哈希方案无关，但如果是自己设计的地址，至少可以保证不会因为地址聚集导致哈希冲突加剧。另外，如果网络里配置了静态 ARP 绑定或者端口安全策略，换算法导致 MAC 变化时，这些配置要同步更新，这一点在版本升级方案里必须写清楚。

4.4 怎么验证算法没问题

不要等设备装到现场才验证。在 PC 上写个小程序，把同一段算法原样拷过去，造几百万个虚拟 UID 跑一遍，统计三件事：一是碰撞数量，直接两两比对或者用哈希表；二是每个字节的取值分布，画个直方图，看看是不是均匀，如果某个字节明显偏向某些值，说明雪崩不够；三是相邻 UID 生成的 MAC 之间的汉明距离，平均值应该在 23 位左右（46 位的一半），如果明显偏低，说明扩散不足。

产测环节再加一道检查：读出 MAC，判断第一个字节是不是落在合法的本地管理地址集合里（也就是(byte0 & 0x03) == 0x02），判断是不是全 0 或全 F，判断是否在内部的保留地址表里。这三条检查加起来不到二十行代码，但能挡掉绝大部分低级错误。

5. 现场问题排查

5.1 三个踩过的坑

第一个坑是编译器升级导致 MAC 变化。某次工具链从旧版本换到新版本，同样的源码、同样的芯片，算出来的 MAC 全变了。查了两天才发现，适配层里用了结构体强制转换去读 UID，新编译器对某个成员的对齐方式处理不同，读出来的字节顺序变了。后来改成手工移位，问题消失。这件事的教训是：凡是涉及二进制布局的地方，不要依赖编译器的默认行为。

第二个坑是截取高位导致整批重复。有个早期版本为了省事，直接从 UID 里取了前 6 个字节，小批量二十台测试完全正常，因为样品来自不同批次。量产两千台的时候，同一批次的设备高位完全相同，MAC 全撞，交换机直接瘫痪。这个问题的隐蔽性在于，小批量测试根本发现不了，因为测试样品往往是分散取的。后来改成全字节参与哈希，才彻底解决。

第三个坑是 U/L 位没设，和某厂商的真实设备撞了地址。当时的现象是设备接进客户网络后，客户那边的核心交换机日志疯狂刷 MAC 漂移告警，网络间歇性中断。查了很久才发现我们生成的地址第一个字节是0x00，被当成全球唯一地址，恰好和客户网络里某台设备的 OUI 前缀撞上。把第一个字节的低两位改成10之后，问题立刻消失。这个坑的代价很大，因为排查方向一开始全在网络设备上，压根没怀疑到自己生成的地址。

5.2 常见问题速查表

5.3 算法要冻结，版本要能追溯

最后这条是我认为最重要的一条经验：这套算法一旦发布，就不要轻易改。因为 MAC 变了，设备在客户网络里的身份就变了，DHCP 租约要重来，静态绑定要重配，云端设备白名单要更新，甚至有些客户的网络准入系统会把新 MAC 当成陌生设备直接拒绝。我见过一个项目因为改了哈希的种子常量，导致现场几千台设备升级固件后集体掉线，回滚都来不及，因为旧固件已经被覆盖了。

所以正确的做法是：算法里的每一个常量，包括偏移基、质数、雪崩系数、域分隔字节、版本字节，全部写进设计文档冻结起来，代码里加注释说明“禁止修改”。如果确实需要演进（比如发现碰撞率不可接受），必须做兼容处理：新版本固件先读出旧的 MAC，和新算出来的比对，如果不同，走一个迁移流程，比如把新 MAC 写进设备的配置文件，或者提供一个过渡期让云端同时认两个地址。

还有个小技巧：在产测数据库里除了存 UID 和 MAC 的对应关系，再存一份算法版本号和固件版本号。将来出现任何地址相关的售后问题，直接查表就知道这台设备是用哪版算法生成的，比翻代码快得多。这个字段只占几个字节，但省下的排查时间是以天计的。

我个人在实际项目里的习惯是，把生成函数单独放在一个文件里，文件头写上算法版本、冻结日期、以及一句“修改此文件需同步更新产测数据库”，然后用编译期断言把版本号固定住。听起来有点小题大做，但真的能挡住后来接手的人随手“优化”一下的冲动。