企业官网建设流程全解析

刚入行时，我第一次在原理图里看到“SD NAND”这个小封装，第一反应是：这不就是一颗能焊在板子上的 SD 卡吗？可紧接着脑子里冒出一个很天真的问题——SD NAND 里面装的为什么是 NAND，而不是 NOR？

这个疑问一点都不丢人，我甚至觉得，能问出这句话的初级工程师，已经比那些拿到芯片就跑 demo 的人强了。因为这个问题背后，藏着嵌入式存储选型最核心的一套逻辑：接口协议怎么选介质、容量成本怎么限制方案、控制器到底在替谁干活。这篇文章就沿着这个问题往下挖，把 NAND、NOR、SD 协议和控制器之间的角色关系一次讲透，不讲厂商、不扯玄学，只说原理和选择依据。

1. 为什么初级工程师先认识 NOR，反而觉得 NAND 陌生

1.1 NOR 是很多 MCU 的“第一片 Flash”

很多人的嵌入式启蒙板，MCU 内部都集成了一小块 Flash，用来存程序、存常量。这块内部 Flash 的本质就是 NOR 结构。为什么选 NOR？因为 MCU 上电后需要直接取指执行，NOR 支持随机字节访问，低延迟，可以被直接映射到 CPU 的地址空间里，程序坐在 Flash 上就能跑起来，这在行业里叫 XIP（片上执行）。

后来板子上的代码不够放了，外扩一颗 SPI NOR，用四根线就能读写，指令也直白：发一个读命令、给个地址，数据就从 MISO 上冒出来。对刚接触嵌入式的工程师来说，NOR 实在是太“顺手”了。于是脑子里就形成了一个定势：Flash 嘛，就该是 NOR 这样的——能直接读、能放代码、擦写放心。

1.2 NAND 给人的第一印象反而不太好

NAND 在初级工程师的认知里，往往是带着“负面标签”出场的：不能按字节读、坏块要管理、写之前要先擦、还要做纠错。听着就麻烦。

所以当有人推荐“用 SD NAND 存日志吧”，很多人第一反应就是：为什么不用 NOR？NOR 又稳定又简单，NAND 一堆毛病。但现实很快打脸：数据记录需要 128MB 容量，NOR 能做到，但价格和面积都高得离谱；而且日志要持续写入，NOR 的擦除时间长得让人崩溃。

真正的问题不是“NAND 比 NOR 高级”，而是 SD NAND 这个产品的本质，决定了它必须用 NAND 而不是 NOR。要理解这一点，得从存储单元的物理结构讲起。

2. 并联和串联决定了命运：NOR 随机读，NAND 整页扛

2.1 NOR 的每个存储单元，都像一户单独开门的人家

NOR 的存储阵列，是把每一个存储单元并联在位线上。每个单元都有自己的接触孔，字线负责选行，位线直接连到每一列的单元上。读数据时，选中一条字线，这一行的所有单元同时和位线接通，感应放大器立刻判断每个单元是导通还是截止，从而读出“1”或“0”。

这种结构带来一个天然优势：可以随机访问任意字节。因为每一户人家门前都单独修了一条路，你想敲哪家门，直接过去就行，不用惊动整条街。这也是 NOR 能 XIP 的物理基础——CPU 给一个地址，存储器就能直接把对应位置的字节交出来。

代价也很明显：每个单元都要留出接触孔、拉开间距，导致单元面积很大，同工艺下单位面积能存的数据量比 NAND 少得多。NOR 的很多容量标称到现在还是 Mb 级别，不是厂商不想做大，是硬件结构撑不起大容量的成本和良率。

2.2 NAND 的串型队列，把密度做上去了

NAND 的结构，存储单元是一个接一个串在一根线上，整串只有首尾两个选择晶体管分别连接位线和源线。你没法把串中间某个单元的“门”单独打开，必须给整串加上电压，然后通过感应一整页的电流状态来读出数据。

换句话说，NAND 的数据进出天然是以“页”为单位的，常见一页 4KB 到 16KB 甚至更大。读一页，先整页搬进芯片内部的页缓冲器，再从缓冲器按顺序吐出来。写也是一样，一次只能编程一整页，而且写之前还得先把所在的块擦除干净。

打个比方：NOR 是每家一条独立电线，NAND 是一整串彩灯，你要查某一盏灯的亮度，得把整串灯一起点亮再看。好处是省线、省空间，坏处就是没法精准操作单个单元。但省下的空间换来了极高的存储密度，大容量存储市场几乎全被 NAND 家族占据。

2.3 一张表看清两个存储家族的底细

很多初级工程师纠结于“NOR 寿命长、NAND 寿命短”，但这只是其中一个维度。更关键的是，闪存控制器可以通过磨损均衡把 NAND 的寿命摊到全部块上，而 NOR 的大扇区擦除在频繁写小数据的场景里反而很吃亏。寿命之外，擦除速度、写吞吐和成本才是 SD 这种场景真正看重的指标。

3. SD 协议天生是“块设备协议”，不是字节总线协议

3.1 SD 命令集里压根没有“读某个字节”这种操作

理解 SD NAND 为什么装 NAND，必须先搞明白 SD 协议本身是什么样的。SD 协议从设计之初就是块设备协议：主机发一条读命令，带上块号，卡返回一整块数据；发一条写命令，主机把一整块数据交给卡。这个“块”通常是 512 字节，对应 SD 规范里的标准扇区大小。

如果看具体命令，读单个块用 CMD17，读多个块用 CMD18，写单个块用 CMD24，写多个块用 CMD25。这里面的地址指的是“第几个块”，而不是“第几个字节”。主机从来没有机会从 SD 卡里读一个字节——即使它只想看一个字节，也得先拿到整块 512 字节的数据，再从内存里取那一位。

这意味着什么？意味着 SD 协议对介质的要求是“能按块高效读写”，而不是“能按字节随机访问”。NAND 的页读写特性，跟 SD 协议的块操作天然匹配；而 NOR 最引以为傲的随机字节读能力，在 SD 协议这层根本接不上电。

3.2 控制器把逻辑块映射进 NAND 页，用户完全无感

SD NAND 内部其实有两部分：一颗 NAND 闪存die，一个控制器。控制器对外提供 SD 协议接口，对内负责把主机的逻辑块号翻译成 NAND 的物理页号。主机发“写第 100 块”，控制器查一层逻辑到物理的映射表，找到对应物理页，然后执行 NAND 的页编程操作。

这套流程之所以能跑得顺，靠的就是 NAND 的页大小和 SD 块读写粒度能互相折算。虽然 SD 的一块是 512 字节，NAND 一页是好几 KB，但控制器可以把一个逻辑块簇攒够之后再写进一页，也能在做读操作时把整页读出来，再按块返回给主机。整个过程中，用户看到的只是“能按块读写的卡”，NAND 的擦除、页缓冲、坏块替换全是幕后工作。

把这个映射逻辑反向应用到 NOR 上，就成了一个笑话：NOR 明明支持字节随机读，可 SD 协议不会把“随机读字节”的指令传下去，主机只会按块读。NOR 的随机访问优势被 SD 协议这堵墙完全挡在外面，用户花了大价钱买的“随机读能力”，在 SD 场景里根本用不上。

3.3 “能启动”不等于 XIP，说明 NOR 的看家本领在这里无处施展

也有工程师问：SD NAND 不是也能做启动吗？那它是不是也得像 NOR 一样能被 CPU 直接执行？

这里有一个常见误解。SD 卡启动的流程通常是这样的：芯片内部的 boot ROM 先通过 SD 协议按块读取启动代码，放到芯片内部的 SRAM 或 DDR 里，然后 CPU 从 RAM 开始执行。后续的应用代码也是由这段引导程序从卡里搬进内存，再跳转运行。整个过程，CPU 始终没有从 SD 卡里直接取指。

原因很简单：SD 协议本身就没有把存储介质映射进 CPU 地址总线的机制，它对外只提供块读写命令。即使 SD 卡里面装的是一颗 NOR，除非卡内部控制器专门做一个“把随机读翻译成块地址再读出来”的转换，否则 CPU 也无法直接在卡里执行代码。更关键的是，真的把 NOR 塞进去，为了获得 SD 接口，还得再经过控制器，绕一大圈后 XIP 依然不成立，NOR 最后一块遮羞布也没了。

4. 容量、成本、写速度：算完账就明白没人做“NOR 型 SD 卡”

4.1 同容量下 die 面积差距，是绕不开的成本墙

存储芯片的价格，很大程度由 die 面积决定。同样一片晶圆，能切出多少颗合格芯片，直接决定每颗芯片的边际成本。NOR 因为每个单元都要独立接触孔，单元间距大，同样容量下 die 面积可能比 NAND 大好几倍。放到大容量时，这个差距会被进一步放大。

举个例子，做一颗 256MB 的 NOR 和一颗 256MB 的 NAND，前者在工艺、面积、良率上全面吃亏，成本可能差出数倍甚至一个数量级。这也是为什么市面上大容量 NOR 屈指可数、价格高得离谱，而 NAND 可以轻松做到几十 GB、上百 GB 还保持低单价。

SD 卡这个产品类别的容量基线是多少？照片、视频、日志文件，随便就是 GB 级。哪怕是最“抠搜”的 SD NAND 方案，容量也常在 64MB 到 128MB 起步。用 NOR 去满足这样的容量需求，成本和面积直接劝退，方案根本立不起来。

4.2 写日志场景的实测对比：擦除等待最要命

我调过一个数据记录仪，要求每秒钟追加写几 KB 数据，写到一张“SD 卡”里。如果这块存储是 NOR，每次写入前的擦除是大麻烦。NOR 不能原地把某一位从“1”改成“0”，得先把整个擦除块恢复成“1”，然后再向该改的位置写入“0”。擦除一块要几十毫秒到上百毫秒是常态，频繁小写入会让系统反复卡在擦除等待上，实时性根本保不住。

换到 SD NAND 后，情况完全不同。NAND 内部也是先擦后写，但擦除一个块的时间通常在毫秒量级，而且页编程一顿操作猛如虎，连续多块写起来吞吐量能到几十 MB/s。日志系统用文件系统组件直接 f_write，无需关心擦除对齐，控制器内部自己拆页、自己擦块、自己做坏块替换。实测下来，同样数据量的日志写入，SD NAND 的耗时是 NOR 方案的零头。

读方向当然也要提一句：NOR 的随机读延迟确实低，但 SD 应用里主机读文件往往是成块地读，NAND 把整页读进缓冲后再流水线输出，顺序读吞吐反而更高。反正 SD 协议拿到的是块，用户关心的也是“一次读多少数据”，不是“第一个字节多快出来”。

4.3 真的有人做过“NOR 型 SD 卡”吗？两头不讨好

理论上当然可以做：把 NOR 封装成 SD 卡的样子，控制器负责把块读写转换成 NOR 的字节随机读写。但这个产品会同时踩中两个坑。容量做小了，用户直接用 SPI NOR 更便宜、更简单，不需要 SD 接口绕路；容量做大，NOR 的成本和面积又撑不住。SD 接口增加的控制器、协议开销、电源管理，对 NOR 来说全是额外负担。

所以现实世界里，你会发现 SD 卡、SD NAND、eMMC 这些块存储设备，介质清一色全是 NAND。这不是偶然，是成本、容量、协议匹配度共同逼出来的必然选择。一个问题想明白就够了：SD 生态从诞生起就是围绕“能按块快速读写的大容量介质”设计的，而 NAND 就是那个介质。

5. SD NAND 真正的核心是控制器，NAND 是它最合理的“供应商”

5.1 控制器替主控扛走了坏块、纠错和磨损均衡

很多初级工程师以为 SD NAND 就是一个 SD 接口的 NAND，其实不对。SD NAND 应该理解成“NAND die + 管理控制器”的复合体，NAND 只是肚子里装的货，控制器才是真正干活的。

NAND 天生不完美：有瑕疵坏块、会位翻转、擦写多了会磨损、掉电可能丢页。这些问题如果裸着用，全要主控承担。但 SD NAND 的控制器把这些都包了：上电扫描坏块、维护坏块表、写数据做 ECC 校验、读数据纠错、动态加静态磨损均衡、掉电时保存映射表。用户往文件系统里 f_write 一个文件，控制器在后面默默完成了不知道多少操作。

这正好回答了一个更深层的问题：为什么 SD 控制器更喜欢配 NAND？因为 NAND 到处都是需要管理的地方，控制器的价值才能最大化。如果用 NOR，坏块管理几乎不用做、ECC 强度要求低、磨损压力也小，控制器反而变成了一身本领没处使的摆设，还得赔上接口转换的损耗。

5.2 代码量对比：裸 NAND 写 FTL，SD NAND 直接开文件

我最喜欢用代码量来给初级工程师直观感受这二者差别。如果用一颗裸 NAND 存数据，主控这边要做的有：写 NAND 驱动、扫坏块、维护坏块映射表、实现地址转换（把文件系统的逻辑块映射到物理页）、处理擦写均衡、嵌入 ECC 计算与校验。这一套自己从零写，没有几个月调不顺手，中间踩的坑一个接一个。

换成 SD NAND，主控只需要 SD 协议层的驱动——SDIO 或 SPI 模式都行——然后直接挂一个现成的 FAT 文件系统。打开文件、写数据、关闭文件，整套流程跟操作电脑上的 U 盘没什么区别。坏块、磨损、ECC 全部封装在芯片里，主控代码量少得可怜。

如果你正在一个 MCU 项目里纠结“要不要用 SD NAND”，先想想自己手里有没有写 FTL 的人力。没有的话，SD NAND 几乎是把 NAND 用起来的唯一省心方式，因为控制器已经在里面替你把最苦的活干完了。

5.3 选型判断速成方法：问两个问题就够

那是不是意味着 NOR 就该彻底淘汰了？当然不是。给大家一个特别实在的选择标准：

第一个问题：你的代码需不需要从这块存储里直接执行、上电就拿 PC 指针去取指？如果是，选 NOR（或者干脆用 MCU 内部 Flash），这是 NAND 和 SD NAND 都给不了的。

第二个问题：你的数据容量是不是明显超过 32MB、需要文件系统、还需要持续写入日志或固件升级文件？如果是，就别折腾 NOR 了，SD NAND 或者同类的 eMMC 才是正路。SD NAND 的优势是引脚少、走 SDIO/SPI、适合低引脚 MCU；eMMC 容量更大、并行接口，但引脚和主机要求也更高。

还想再补一句：选 SD NAND 的时候，也别拿烧 NOR 的心态去测它。它不是“NAND 的一种”，而是“插在板子上的小硬盘”，评价它要看连续读写、磨损均衡、掉电保护这些指标，而不是拿字节随机读的眼镜去挑毛病。

最后聊点实际体感。我后来做某数据记录仪项目的存储升级时，就是把日志从 SPI NOR 迁到了 SD NAND：主控代码只换了 SD 驱动那一层，上层文件操作几乎原样保留，容量却从 16MB 跳到了 128MB，写日志再也不被擦除时间卡脖子。在这个项目里，我彻底想明白了一件事：SD NAND 装 NAND 不装 NOR，不是因为 NAND 更“高级”，而是 SD 协议的块接口、大容量需求、写吞吐预期和 NAND 的物理特性刚好严丝合缝。NOR 呢，在启动、随机读、低容量这些主场里依然是不可替代的角色。技术选型从来没有“谁取代谁”，只有把合适的介质放到合适的接口后面。