简单理解：加个 .c 文件，代码体积反而变小？
工程中添加了.c文件（比如NOR_FLASH.c）后，不仅没报错，还出现 “内存占用变小” 的情况，这是 Keil 编译器链接优化机制导致的正常现象，核心原因不是 “加文件占空间少”，而是新增文件触发了编译器的 “代码复用 / 垃圾回收” 优化，我会用通俗的方式拆解：
先纠正认知：不是 “加文件让内存小”，是 “优化生效更充分”
你看到的Program Size变小，本质是：原来的工程中，编译器的--gc-sections（垃圾回收）、-Os（大小优化）等选项，因为代码量少 / 模块单一，优化效果有限；新增.c文件后，编译器在链接阶段能更充分地：
- 复用公共代码：比如新增的
NOR_FLASH.c和原有模块都用到了memcpy/strlen等库函数，编译器只保留一份函数实现，避免重复链接； - 精准回收未用代码：新增模块后，编译器能更清晰地区分 “被调用的代码” 和 “未被调用的代码”，把后者彻底移除；
- 优化段分配：多个
.c文件的代码段（.text）分开后，编译器能更高效地合并 / 压缩段空间，减少段对齐带来的 “内存碎片”。
具体原因拆解（用你的工程数据举例）
你的工程优化后：
Program Size: Code=28000 RO-data=2420 RW-data=24 ZI-data=12744对比之前的错误版本，Code段从 “超出容量” 降到 28KB，核心是这 3 个优化机制：
1. 垃圾回收（--gc-sections）更充分
- 无新增文件时：工程只有核心模块（GPIO/I2C/USART），代码段少，编译器没多少 “未用代码” 可回收；
- 新增 NOR_FLASH.c 后：编译器会扫描所有
.c文件的函数调用关系，比如：NOR_FLASH.c中定义了NOR_FLASH_Read()，但你没调用 → 直接移除；- 原有
main.c中未调用的IIC_ReadWriteTest()→ 一并移除；最终 “有用的代码总量” 反而变少，Code段自然减小。
2. 库函数复用（MicroLIB 机制）
- Keil 的
MicroLIB（轻量级库）会把printf/memcpy/strlen等库函数做成 “共享段”； - 新增
.c文件后，编译器发现多个模块都依赖同一个库函数 → 只链接一份，避免重复占用空间；比如：main.c和NOR_FLASH.c都用了memcpy，原来可能链接两份，现在只链接一份，节省了重复代码的空间。
3. 代码段对齐优化
- 每个
.c文件编译后会生成独立的代码段（.text），段大小会按 4/8 字节对齐（比如 10 字节的代码会占 12 字节）； - 少量
.c文件时，“对齐浪费” 比例高（比如 1 个文件浪费 2 字节，占比 20%）； - 多个
.c文件时，“对齐浪费” 被分摊（比如 5 个文件总共浪费 8 字节，占比仅 0.1%），整体Code段的 “有效利用率” 提升，看起来就变小了。
举个直观的例子
| 场景 | 代码段组成 | 实际占用 | 对齐浪费 | 总占用 |
|---|---|---|---|---|
| 仅 main.c（无新增） | main.text (100 字节) | 100 | 4 字节 | 104 |
| 加 NOR_FLASH.c 后 | main.text(80) + nor.text(20) | 100 | 0 字节（刚好对齐） | 100 |
| → 总占用从 104→100，看起来 “加文件后内存变小”。 |
总结
- 核心原因：新增
.c文件触发了编译器更充分的链接优化（垃圾回收、库函数复用、段对齐），而非 “新增文件本身占空间少”； - 关键机制：
--gc-sections（移除未调用代码）、MicroLIB（库函数共享）、-Os（代码压缩）是核心； - 实用结论：
- 这种 “加文件内存变小” 是正常现象，说明你的优化配置（Size 优化、MicroLIB、垃圾回收）都生效了；
- 后续新增模块时，只要保留这些优化配置，编译器会自动 “瘦身”，无需担心代码量增加导致空间不足；
- 若想进一步减小内存，可继续移除未调用的函数 / 模块，或替换
printf等大体积函数。
简单来说：不是 “加文件让内存小”，是 “加文件让编译器的优化功能发挥得更好”，最终保留的 “有用代码” 更少，内存自然变小。