4. 内存分区策略：代码区、数据区、堆区、栈区的划分原则与大小估算
做嵌入式系统设计，说白了就是在跟资源较劲。尤其是内存，就那么几兆甚至几百K，怎么分才够用？我见过太多项目，前期拍脑袋分内存，后期跑起来各种溢出、死机，最后加班排查。
今天咱们就聊聊内存分区的门道。代码放哪、数据放哪、堆和栈怎么切，这些不是随便画几条线就完事的。
4.1 四大内存区域，各司其职
一个典型的嵌入式系统，内存通常被划分为四个区域。嗯，咱们一个一个来看。
| 区域 | 存放内容 | 特点 |
|---|---|---|
| 代码区（Text） | 程序指令、常量字符串 | 只读、大小固定 |
| 数据区（Data/BSS） | 全局变量、静态变量 | 可读写、生命周期贯穿整个程序 |
| 堆区（Heap） | 动态分配的内存 | 手动管理、大小可变 |
| 栈区（Stack） | 局部变量、函数调用上下文 | 自动管理、后进先出 |
你想想看，这四个区域如果划分不合理，后果是什么？代码区太大，堆栈不够用；栈区太小，函数嵌套深一点就崩了。我在项目中遇到过，一个同事把栈设成1KB，结果一个中断服务函数里定义了个512字节的数组，直接栈溢出，查了两天才找到原因。
4.2 代码区：别把指令当数据
代码区存放的是编译后的机器指令。这部分是只读的，你程序跑起来后不会改它。我个人的习惯是，代码区尽量放在Flash里，而不是RAM里。为什么？Flash便宜、容量大，RAM宝贵啊。
估算代码区大小其实很简单：编译完看.map文件，里面会告诉你.text段的大小。比如：
// 编译后查看.map文件
// .text 段大小: 0x2A3C (10812 bytes)
// .rodata 段大小: 0x0450 (1104 bytes)
// 代码区总大小 ≈ 10812 + 1104 = 11916 bytes这里要注意，常量字符串也会放在代码区。我曾经见过一个项目，里面定义了几百条调试日志字符串，每条都几十个字节，结果代码区直接膨胀了30%。
4.3 数据区：全局变量的家
数据区分为两块：已初始化的数据段（.data）和未初始化的数据段（.bss）。
- .data段：存放有初始值的全局变量和静态变量。这部分在程序启动时从Flash拷贝到RAM。
- .bss段：存放未初始化或初始化为0的全局变量。这部分在启动时清零。
估算数据区大小，同样看.map文件：
// .data 段大小: 0x01A0 (416 bytes)
// .bss 段大小: 0x0C80 (3200 bytes)
// 数据区总大小 ≈ 416 + 3200 = 3616 bytes我建议你养成一个习惯：能用局部变量就别用全局变量。全局变量多了，数据区膨胀不说，还容易引发竞态问题。说白了，全局变量就是共享资源，用起来要小心。
4.4 堆区：动态分配的利与弊
堆区用于malloc、new这类动态内存分配。嵌入式系统里，我其实不太推荐用堆。为什么？
- 堆容易产生碎片
- 分配失败时不好处理
- 实时性难以保证
但有些场景确实需要堆，比如你不知道运行时会有多少数据。这时候，堆的大小怎么估？
我个人经验是：堆的大小 = 最大可能分配量 × 1.5。为什么乘1.5？因为要考虑碎片。比如你最多需要10KB的动态内存，那就设15KB的堆。
4.5 栈区：最容易出问题的区域
栈区存放局部变量和函数调用的返回地址。栈的大小直接决定了你能嵌套多少层函数、能用多大的局部数组。
栈溢出的典型症状：程序跑着跑着就死机了，或者出现莫名其妙的数据错乱。我刚开始做嵌入式时，就吃过这个亏。一个递归函数没控制好深度，栈直接爆了，查了两天才发现是栈不够用。
估算栈大小，可以这样算：
// 估算最大栈使用量
// 1. 找出最深的函数调用路径
// 2. 计算每个函数使用的局部变量大小
// 3. 加上中断嵌套的栈开销
// 示例：最坏情况下的栈使用
// main() -> funcA() -> funcB() -> funcC()
// main: 局部变量 64 bytes
// funcA: 局部变量 128 bytes
// funcB: 局部变量 256 bytes
// funcC: 局部变量 512 bytes
// 中断嵌套: 512 bytes
// 总栈需求 ≈ 64 + 128 + 256 + 512 + 512 = 1472 bytes我建议把栈大小设为估算值的2倍。为什么？因为有些库函数内部也会用栈，你算不到。比如printf，它内部可能分配不小的缓冲区。
4.6 内存分区实战：一个完整的例子
假设我们有一个STM32F103芯片，64KB Flash，20KB RAM。怎么分？
我个人的习惯是这样：
// 链接脚本中的内存分区示例
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}
SECTIONS
{
// 代码区：放在Flash
.text : { *(.text) *(.rodata) } > FLASH
// 数据区：放在RAM
.data : { *(.data) } > RAM AT > FLASH
.bss : { *(.bss) } > RAM
// 堆区：放在RAM末尾
.heap : { . = ALIGN(4); _heap_start = .; . += 4K; _heap_end = .; } > RAM
// 栈区：放在RAM顶部
.stack : { . = ALIGN(4); _stack_start = .; . += 2K; _stack_end = .; } > RAM
}你看，20KB的RAM，我分了4KB给堆，2KB给栈，剩下的14KB给数据区。这个比例怎么来的？
- 数据区14KB：项目里全局变量和静态变量加起来大概10KB，留点余量
- 堆区4KB：偶尔用malloc分配一些临时缓冲区
- 栈区2KB：函数嵌套最深大概用到800字节，2KB足够
当然，这个比例不是固定的。如果你的项目大量使用动态分配，堆就要大一些。如果函数调用很深，栈就要大一些。关键是要根据实际需求来调。
4.7 避坑指南：我踩过的那些坑
做内存分区这么多年，我总结了几条经验，分享给你：
- 别信默认配置：编译器给的默认链接脚本不一定适合你的项目。我建议自己写链接脚本，精确控制每个区域的大小和位置。
- 监控栈使用量：在栈区填充一个特殊模式（比如0xDEADBEEF），程序跑一段时间后检查这个模式被覆盖了多少，就能知道栈的实际使用量。我每个项目都会做这个测试。
- 堆和栈不要挨着：如果堆和栈相邻，堆向下增长，栈向上增长，它们可能会互相覆盖。最好在堆和栈之间留一个保护区域。
- 考虑对齐：ARM Cortex-M系列要求4字节对齐，有些外设要求8字节甚至16字节对齐。分区时要注意对齐，否则可能出奇怪的问题。
4.8 知识体系总览
下面这张图，是我画的内存分区核心逻辑。你看一眼，就能明白整个知识结构。
嗯，内存分区这块，说白了就是平衡的艺术。代码区、数据区、堆区、栈区，每个区域都要照顾到，但又不能互相挤占。我个人的经验是：先估算，再留余量，最后用工具验证。这样三步走，基本不会出大问题。
好了，这一章的内容就到这里。记住，内存分区没有标准答案，只有最适合你项目的方案。多动手、多测试，慢慢你就有感觉了。