尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
NOR Flash和NAND Flash到底有啥区别?一文讲透原理与选型
做硬件这些年被问到最多的一个问题不是单片机性能也不是电源怎么布而是“NOR Flash和NAND Flash到底有什么区别”。老实说这题很有含金量。能真正把这两个Flash家族差异讲清楚的人硬件成本意识、固件设计思路、存储选型功底通常都差不到哪里去。我见过不少工程师用了好多年Flash却搞不清为什么板子上的启动代码必须放NOR而U盘里几乎全是NAND。这篇文章我就从自己的工程经验出发把两者的底层原理、参数差异、选型套路和翻车教训一次说透。先给一句结论备用NOR擅长“随机读”能直接跑代码NAND擅长“大容量顺序存储”适合当数据仓库。但这个结论背后牵扯到的物理结构、接口设计、寿命管理远不是一句话能覆盖。下面我会从结构原理讲起一步一步拆最后附上实操选型建议。新手可以直接拿去用老手也能在排障部分捡点干货。1. 先搞清楚家族起源同一个“闪存”祖上兄弟俩各走各路1.1 Flash芯片的本质一个断电不丢数据的晶体管仓库不管是NOR还是NAND芯片内部最核心的存储单位都是一种叫“浮栅晶体管”的结构。很多人一听晶体管就头大其实用大白话很好理解。你可以把浮栅晶体管想象成一个带锁的小储物柜。通过施加高电压可以把电子“塞”进一个特殊的绝缘层里这个层就是浮栅。电子被塞进去之后即使整块板子断电它也能老老实实待上几个月甚至更久数据就这么记下来了。读的时候芯片只需要去检查这个柜子里到底有没有电子对应到存储逻辑里就是“0”和“1”。所以Flash的本质其实就是一个巨大的晶体管仓库仓库里面是一排排浮栅单元。NOR和NAND虽然都叫Flash但它们在仓库内部的“货架摆法”完全不同这也是它们性格差异的最大来源。1.2 存储单元的物理结构一个并联、一个串联决定了性格仓库里的摆法到底哪里不同NOR Flash的存储单元是并联结构的。可以这么理解每个晶体管都单独“挂”在一条位线上有自己的访问路径。CPU说我想读地址A的数据芯片就能直接把那个单元的值拎出来旁边的单元完全不受影响。就像一排放着几十本书每本书都有独立标签你想拿第二本就直接伸手拿不用把其他书挪开。NAND Flash则正好反过来。它的存储单元是几十个甚至上百个串在一根“豆腐串”上这个串就叫NAND串。因为所有单元共享同一个输出节点你没法单独“点名”某个单元必须先把一整串的数据整体搬出来再说。再打个比方每个箱子里面装了厚厚一沓资料你想读其中某一页得先把整个箱子搬出来再翻到那一页。虽然最终也能看到内容但整个过程没法做到“点读”。就是这一“并联”一“串联”导致NOR能按字节随机读而NAND只能按页整块读。不夸张地说后面所有区别——速度、寿命、接口、容量、成本——几乎都能从这一个物理结构推导出来。1.3 物理差异引发的连锁反应并联结构给NOR带来了随机读取快的红利控制逻辑也简单。但代价是每个单元都需要独立的接触孔和走线占芯片面积容量做不大成本也压不下来。串联结构正好反过来引脚和接触孔少单元密度可以做得很高同样一片晶圆能切出更大容量的NAND。这个差异直接影响了市场定位。NOR这些年能继续活着靠的不是大容量而是“代码执行”和“高可靠性”这两个刚需。而NAND靠着存储密度把每bit价格打到极低顺利吃下了U盘、存储卡、SSD这些海量数据市场。所以你可以这么记NOR拿存储密度换了“可随机访问”NAND拿“不能随机访问”换了存储密度和成本。理解到这一层后面再看参数表就不会被一堆数字带偏了。2. 核心差异逐条拆解读取、写入、擦除、容量与寿命2.1 读取方式与速度NOR的“随机访问”到底有多大优势先看读取。NOR支持按字节随机读这在并行NOR时代体现得最明显。芯片引脚里有完整地址线CPU给一个地址NOR就像SRAM一样把对应字节放到数据总线上。这意味着CPU可以直接从NOR里取指令执行不需要先把代码搬运到RAM也不需要额外的“读页”过程。而NAND的读取是按页进行的。一个页通常是2KB、4KB甚至更大主控先发一串命令和地址NAND芯片把这个页搬进内部页缓冲寄存器再从缓冲区往外送数据。如果你只想读其中某一个字节不好意思也得整页过一遍。需要顺序读取大块数据时比如视频流NAND吞吐率并不低但要是大量随机小读NAND和NOR的差距一下就拉开了。具体数字上常见的4线SPI NOR在100MHz左右的接口频率下实测顺序读速度能做到40到60MB/s而NAND那边页读延迟通常几十微秒连续读吞吐动辄200MB/s以上。但要注意前者是“随机点读也快”后者是“连续读快、随机读会打折扣”。所以衡量NOR的读性能不能只看峰值速率要看随机访问能力和访问延迟。2.2 写入与擦除NOR的“慢”藏在操作原理里再说写入和擦除这里最容易踩坑。Flash的写入本质上只能把“1”变成“0”想再变回“1”必须先把整块区域擦除。擦除是把一块区域统一恢复到全“1”状态这是所有Flash的基础约束。关键区别在于NOR擦除的最小单位通常是64KB或128KB的block编程通常按字节或字进行而NAND擦除的最小单位一般是128KB到2MB的block编程则按整页进行。为什么NOR写起来慢拿一颗中等容量的SPI NOR举例按字节编程一个字节可能要几十到几百微秒虽然单字节看着不快但也不算离谱可一旦数据量上到几百KB写周期次数会非常多再加上擦除一个block可能要几十毫秒到几百毫秒整个耗时肉眼可见地涨上来。NAND呢一个4KB页的编程时间普遍在200到400微秒左右擦一个2MB的block普遍在1到2毫秒。换算下来同样写1MB数据NAND要比NOR快一个量级甚至更多。项目里常见的一个坑是有人拿NOR当大容量EEPRO来存业务数据写入频繁、数据量还大结果经常发现“写一次要卡住很久”。这不是芯片有问题是操作方式完全选错了介质。反过来NAND虽然写快但必须按页整写小数据频繁修改同样会变成灾难。2.3 容量、密度与成本U盘里为什么从来没有NOR容量和成本可能是普通用户感受最直观的一条。民用市场上NOR Flash的主流容量大致在1Mb到256Mb之间再往上也有512Mb、1Gb的产品但始终不是主流。原因前面说过NOR单元占面积大每bit成本高。你要是想拿NOR做一个32GB的U盘先不说体积和引脚数量光是价格可能就是NAND的好几倍根本卖不动。NAND这边单片容量从几百Mb到数Tb都覆盖了叠几片就是SSD、U盘、存储卡。尤其是3D堆叠技术普及之后把存储层一层一层往上垒NAND的容量密度不断刷新颗粒单位价格被压得非常低。这两年主流的消费级存储已经普遍进入单颗1Tb级别甚至更高这种密度是NOR完全无法比拟的。所以市面上有个隐形共识引导程序、启动参数、安全数据这类“小而贵”的关键数据交给NOR图片、视频、日志、数据库文件这类“大而便宜”的海量数据交给NAND。这种分工不是谁瞧不起谁而是两种芯片在物理层面就拿定了主意。2.4 寿命与可靠性NAND的坏块管理绕不开NOR也并非无限关于寿命几乎所有新手都被忽悠过。先说结论NOR和NAND都有擦写次数限制但NAND更敏感因为单元串在一起一个单元出问题会影响一整串。大家常说的P/E循环次数也就是擦写循环次数差距非常明显——NAND做成SLC大约有十万次MLC大约一万次TLC普遍只有三千到五千次到了QLC甚至会降到一千次以内。这意味着如果拿NAND做高频日志存储几年内写坏一块颗粒是完全可能发生的事。NOR虽然也不是铁打的但单元结构相对“皮实”常见SLC类型的NOR能到十万次级别并不稀奇。更关键的是NOR出厂基本不含坏块掉电稳定性也相对好所以嵌入式工程师习惯拿它存引导程序和校准参数这类“关键时刻不能出错”的数据。而NAND从出厂开始就允许有一定比例的坏块使用过程中坏块还会持续增加。主控必须做三件事出厂坏块标记、运行时坏块映射、以及ECC纠错否则数据说丢就丢。这也是为什么NAND不能裸着直接挂到总线上让CPU乱读——管理太复杂必须靠主控方案。对比维度NOR FlashNAND Flash单元结构并联单元独立访问串联成串按页访问读取粒度字节/字随机读页读取不能随机点读编程单位字节/字页2KB16KB擦除单位64KB/128KB block128KB2MB block典型容量1Mb256Mb百Mb数Tb主流P/E寿命十万次级别SLC约10万次MLC约1万次TLC约30005000次坏块管理出厂坏块少见出厂即有坏块需主控管理每bit成本高低典型场景固件、参数、启动代码文件、视频、日志、SSD3. 实操向选型照着几个真实场景走基本不踩坑3.1 固件代码跑在NOR上嵌入式世界的“老传统”为什么砍不掉做过嵌入式的人都知道绝大多数MCU和SoC的启动流程都离不开一颗NOR Flash尤其是SPI NOR。原因很现实上电之后CPU要立刻从复位向量取第一条指令这个阶段DDR还没初始化NAND控制器也没跑起来主控只能从一颗简单的NOR里“摸出”启动代码。同时很多低功耗MCU方案希望代码直接在Flash里就地执行省掉“把代码搬到RAM”的流程既省RAM又免启动搬运时间。所以我们看到即便板上已经放了NAND绝大多数方案还是会保留一颗小容量的SPI NOR2Mb、4Mb、8Mb都很常见专门放bootloader和关键配置。选型提示如果是MCU代码存储优先考虑SPI NOR。注意两个参数一是接口频率二是容量余量。接口频率决定读速度容量决定能装多少代码。别为了省几毛钱选最小容量代码装不下再改板子成本翻十倍都不止。3.2 数据量上来了就上NAND文件系统和主控是绕不开的搭档当产品需要存储几百MB甚至几GB的用户数据时NOR基本出局老老实实选NAND。但选NAND不是买颗芯片焊上去就完事。NAND必须搭配“主控”管理包括ECC校验、坏块管理和磨损均衡。嵌入式里常见的方案有两种一是选择内置主控的eMMC或者SD卡省心但成本略高二是直接接裸NAND把FTL和纠错算法写进自家固件或依赖原厂库。现在很多MCU和SoC自带NAND控制器ECC和坏块映射已经由硬件处理大半裸NAND方案越来越常见。另一条重要经验NAND按页读写小文件碎片多了性能会烂寿命也会快速下降。方案设计时尽量让业务写入以页对齐、大块连续写为主。日志和配置这种小数据宁可单独放NOR或者单独分区也不要混着频繁覆盖NAND。3.3 NORNAND混合最“抠门”但最稳的组合我见过太多量产产品最后都是“NOR加NAND”双存储方案。这不是堆料而是分工协作。以一款某网关设备为例8Mb的SPI NOR放bootloader和固件A/B分区256MB的NAND放数据库和系统日志。NOR里的数据一辈子可能只写几次但必须无条件可靠NAND里的数据量大、更新频繁可以接受一定程度的损耗和重刷。即便NAND里的日志区写坏一个块恢复出厂重扫坏块就能救回来NOR里的启动代码只要不是物理损坏意外掉电一般都不会出问题。混合方案的板级成本其实不高小容量NOR价格压得很低同时固件升级链路也更安全先升级NOR里的安全引导再由新引导升级NAND里的业务镜像OTA的成功率会明显上升。如果你要做中高端产品这条路值得优先考虑。3.4 参数挑选速查买芯片时先看这四个指标最后给一个速查清单接口类型NOR还是NANDSPI还是并行。小系统优先SPI NOR大容量数据优先eMMC或裸NAND。容量余量NOR建议留20%以上空间给升级包NAND要预留足够冗余块给坏块替换。电压与功耗3.3V还是1.8V睡眠电流多少。低功耗设备这里尤其重要。温度范围工业现场选-40到85℃的工业级芯片别拿商业级元件硬顶严苛环境。下单前翻一下规格书里的“AC Characteristics”和“Endurance”两章基本能避开80%的选型坑。4. 为什么NOR能“跑代码”NAND却只能“存数据”把XIP说透4.1 XIP就地执行CPU在执行时到底需要什么这个问题值得单独开一节因为很多人只记住结论但说不出底层原因。CPU在取指令时是不讲“页”的。它随时可能从指令地址A跳转到指令地址B完全随机。这要求存储设备必须具备“字节寻址”的能力给一个地址立刻返回数据延迟越短越好。NOR天然满足这个条件地址线铺在那边选中某个地址就等于选中某个字节读延迟可以低到几十纳秒在慢速MCU上甚至能做到接近于零等待。NAND不行。它内部的数据读取方式是“整页搬进缓冲再串行输出”CPU根本没有办法在一条指令周期内拿到某个随机字节。就算硬把NAND挂到系统总线上模拟NOR时序也会因为页缓冲和串行移位导致延迟巨大根本不适合直接执行代码。所以“XIP”也就是就地执行本质上是一个硬件能力不是软件技巧。它要求存储介质天然支持随机字节读。在Flash世界里NOR就是为这件事而生的。4.2 NAND的IO复用与页缓冲天生就是“块设备”再看NAND的接口。哪怕是传统并行NAND引脚数也远少于同等容量的并行NOR命令、地址、数据全部复用在同一组IO上读写必须按一套复杂的命令序列来调度。读一个页要先发命令、发地址、等芯片把整个页读进内部缓冲再连续读很多个总线周期把数据取出来。这一整套流程活脱脱就是个“块设备”的操作方式。这也解释了为什么NAND在嵌入式系统里几乎不直接挂在CPU总线上而要通过NAND控制器。控制器负责把“块的读写请求”翻译成“NAND芯片的引脚时序”顺便完成ECC、坏块管理、磨损均衡。NOR尤其是并行NOR在早期单片机系统里可以直接挂在系统总线上像RAM一样访问中间省掉一层翻译。理解了这点就不会再试图让NAND“裸跑代码”了。不是说绝对不行而是复杂度和成本完全划不来。个别系统确有“从NAND启动”的方案实际做法还是把NAND里的代码搬到内部SRAM或DDR里再执行本质仍然是“存数据不直接执行”。4.3 并行NOR、SPI NOR和NAND别混为一谈这里提醒一个常见误区很多人把“串行Flash”直接等同于SPI NOR其实SPI NOR只是NOR的一种封装形式介质类型和工作原理还是NOR。并行NOR引脚多、读快、支持字节寻址适合大CPU总线直挂但体积大、价格高。SPI NOR引脚少通常四线甚至六线通过命令访问虽然也是NOR但读延迟比并行NOR稍高胜在省引脚、成本低MCU板上几乎都用它。并行NAND传统NAND页访问为主必须配主控。还有一类高性能接口NAND本质上仍是“页加缓冲加串行出数据”的逻辑别被高速接口的参数迷惑。选型时不要只看名字。“串行”和“并行”是封装与接口的区别“NOR”和“NAND”才是存储介质和工作原理的区别两个维度要分开评估。5. 实操排障我在几个项目里踩过的存储坑5.1 启动时程序莫名跑飞先查NOR的时序有一种很经典的故障用SPI NOR存固件低频率下一切正常把接口频率调到100MHz以上之后程序偶尔死机、跑飞、校验失败。这种问题十有八九不是代码bug而是NOR的读时序配置跟不上。排查思路很简单先把SPI频率降到最低确认能稳定运行再用逻辑分析仪或者示波器抓CS片选、时钟、数据输入输出这几条线比对读命令的dummy cycle和规格书要求。大多数SPI NOR在高速读模式下地址之后需要插入若干个dummy时钟周期这个参数配错一位读回来的数据就是错的。实际解决起来要么把频率降到芯片规格书推荐值要么把dummy cycle算准确。另外PCB上时钟线过长、走线过细也会让高速读时序的余量变小。别一上来就怀疑芯片坏了先查时序这是最容易翻车也最容易修的地方。5.2 NAND文件系统反复损坏别把锅全部甩给“掉电”另一个高频坑用裸NAND存文件系统运行一段时间后文件损坏、系统反复重启。很多资料把锅甩给“突然掉电”实际上NAND损坏的真正原因往往是“坏块增长”和“ECC不足”双杀。NAND出厂时虽然有坏块但出厂坏块会被标记。真正麻烦的是运行时新产生的坏块。如果主控的ECC纠错能力偏弱位翻转就会从一次性软错误变成永久性错误最终整块报废。再加上海量小文件乱写某些物理块被反复擦写寿命提前耗尽也是常事。排查手段在系统里加一个坏块扫描工具定期统计坏块数量变化读回数据时主动算ECC观察纠错率。如果坏块数量突然跳增通常就是磨损均衡没做好或者供电电压异常导致颗粒劣化。故障现象优先怀疑点排查动作程序偶尔跑飞NOR高速读时序降频验证抓SPI波形文件系统损坏NAND坏块/ECC不足扫描坏块统计ECC错误率写数据后读不出来没有页对齐/频繁改写检查写入长度调整分区策略容量上报不准识别ID错误读ID核对型号和容量5.3 从NOR升级到NAND最容易被忽视的三件事很多项目最初用NOR后期数据量上来要换NAND最容易忽视三件事。第一启动方式变化。原bootloader可能在依赖NOR的XIP特性换NAND之后CPU不能直接执行必须把引导代码复制到RAM再跑启动流程要重新设计。第二坏块和ECC策略。NOR可以“裸用”NAND不能。如果原平台没有NAND控制器要从软件层补上管理逻辑工作量并不小。第三功耗与寿命预算。NAND的编程和擦除电流比NOR大持续写入时整机功耗会上升低功耗设备要提前评估同时NAND的P/E寿命要按实际每日写入量来算不能拍脑袋。这三件事每一项都能单独写一篇长文但不提前规划轻则产品返工重则量产翻车。5.4 排查工具与手段工程师的“三板斧”如果怀疑Flash有问题我常用的手段就是“三板斧”。第一读ID。发读ID命令核对厂商和设备ID确认芯片型号、容量、工艺代没有搞错。第二全片回读对比。把已知正确的镜像写进去整片读出来算哈希逐位对比差异能快速定位是不是某块区域总读错。第三坏块扫描加擦写循环测试。对NAND写满全片再回读统计坏块地址和ECC错误率可以评估颗粒健康状况。这三个动作建议都做成命令行工具量产测试和售后返修都能复用。别看简单能省下大量排查时间。6. 一些不是废话的个人体会最后说点参数之外的东西。我在实际项目里最大的感受是做存储选型别把自己钉死在“性能参数”这一个维度上。NOR和NAND看似是两种Flash实际上是两条完全不同的工程路线。NOR更接近“内存”适合当代码和参数的贴身管家NAND更接近“磁盘”适合当数据和文件的大仓库。你需要的往往不是二选一而是找到两者在产品里的分工。另外一个建议量产之前务必做一次读写寿命压力测试用比实际业务更恶劣的写入频率跑上一段时间观察坏块增长和数据完整性。很多存储问题都拖到量产之后才爆发到那时改芯片、改硬件、改固件成本都是指数级上升。这些坑我踩过不少希望读到这里的你能少踩一次。
RELATED

相关推荐

Triton-TLE布局引擎:AI芯片算子性能优化实战解析

Triton-TLE布局引擎:AI芯片算子性能优化实战解析

1. 先从"一个算子要调两周"说起:AI芯片软件栈的困境这两年只要接触过AI芯片的团队,应该都有同感:硬件流片只是第一步,真正让人血压飙升的是软件栈。芯片送样之后,算法工程师跑过来问能不能支持某个新算子&am…

📅 2026/10/20 10:11:04
AI写Rust代码为何频繁翻车:所有权与生命周期难题解析

AI写Rust代码为何频繁翻车:所有权与生命周期难题解析

1. 当AI生成的Rust代码开始"胡言乱语":一个普遍存在的现象如果你最近半年用AI辅助写过Rust代码,大概率遇到过这种场景:AI信心满满地给你生成了一段看起来结构完整的代码,编译器的报错却像瀑布一样刷屏——生命周期标注对…

📅 2026/10/20 10:11:04
大模型Agent记忆系统设计:分层存储、检索与遗忘策略

大模型Agent记忆系统设计:分层存储、检索与遗忘策略

难得碰到一个面试高频题能把“背题型学生”和“架构型工程师”拉开差距的,Agent 的记忆系统绝对算一个。很多人在聊这个题目时,第一反应是“把对话历史塞进 prompt 里”,或者“加一个向量数据库做检索”,但面试官真正想听的&#…

📅 2026/10/20 10:11:04
MORE NEWS

更多资讯

📰

第7讲:并查集

目录 本节目标1. 并查集原理2. 并查集实现3. 并查集应用 省份数量等式方程的可满足性 本节目标 并查集原理并查集实现并查集应用 1. 并查集原理 在一些应用问题中,需要将 n 个不同的元素划分成一些不相交的集合。开始时,每个元素自成一个单元素集合…

📰

Django+Vue宠物商店实战:库存原子扣减、订单状态机与RBAC权限落地

简介:这是一套基于PythonDjangoVue.js全栈技术实现的宠物商店管理系统源码,专为计算机相关专业本科生毕业设计与课程设计打造,已通过导师审核并获98.5分高分评价,适用于毕设选题参考、项目实战训练及期末大作业开发。资源包共396个…

📰

零基础本地部署DeepSeek-R1:Ollama三步跑通与强化学习原理解析

简介:这份PDF图解资料面向大模型初学者、技术爱好者及希望本地部署应用的研发人员,系统讲解DeepSeek大模型的本地部署方法与核心技术原理。内容从本地部署的三个实操步骤切入,逐步展开LLM基础概念、Transformer架构、预训练、监督微调与强化学…

📰

交通标志检测实战:YOLO数据体检与训练避坑指南

简介:面向交通标志检测与目标检测模型训练的数据资源包,包含约7000张已标注图像数据和YOLO标签文件,覆盖红绿灯等12个目标类别,并完成7:3训练集与验证集划分,可直接用于YOLOv5、YOLOv8等常见检测框架的模型训练与精度评…

📰

用C/C++写一份“无毒”表白代码:从控制台动画到Windows图形窗口

简介:使用C语言(含C写法)实现的控制台表白小项目,面向编程初学者、嵌入式/系统开发入门者,以及想用代码制造浪漫的同学;它以极简源码演示了如何用循环、延时、屏幕输出来生成动态文字和闪烁效果&#xff0c…

📰

Codex安装纯教程

手把手:装好 Codex 并接上 DeepSeek(照着做就行) 本文只讲操作,不讲原理。每一步照抄,走完就能用。 想了解原理、配置项含义和完整排错表,请看我的另一个文章《从零安装 Codex CLI 并接入 DeepSeek 模型》。…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬