搞嵌入式开发的，大部分时间都在跟C语言里的函数打交道。函数说白了就是把一段逻辑封装起来，给它输入、拿回输出，但“传参”这两个字，恰恰是很多人从入门到放弃的分水岭。我见过不少同事，跑得动流水灯，写得出定时器中断，可一到“把数据从A函数安全地交给B函数”就各种翻车：值传了改不回来、指针指到天上、数组传进去长度丢了、结构体一拷整个栈冒烟——这些问题归根结底，都是函数参数传递的基本功没打牢。
这篇东西不是教科书，是我自己踩坑踩出来的经验总结。围绕“嵌入式”、“函数”、“传参”这三个关键词，把底层机制、常用姿势、硬件细节、回调写法、常见坑都过一次。适合正在学嵌入式开发的新手，也适合基本功不扎实、想在参数设计上少走弯路的工程师。看完之后你会发现，传参这件事，不光是语法问题，更是工程习惯问题。
1. 函数调用的底层机制：传参这件事没那么玄
1.1 调用约定：参数是怎么被“递”出去的
很多教材讲传参，上来就画箭头：实参、形参、拷贝。但嵌入式工程师如果只停留在箭头层面，后面碰ARM、RISC-V的调用约定就懵了。以ARM Cortex-M系列常见的AAPCS调用约定为例，函数调用时，前四个参数会优先放在R0-R3这四个通用寄存器里，参数再多或者单个参数超过寄存器容纳范围，才会往栈上压。这意味着你调用一个foo(a, b, c)，系统并不是在内存里“复制”三个变量，而是先把a、b、c放在寄存器里，函数体再从寄存器里取。这带来一个直觉上的变化：传参是有“物理成本”的，寄存器数量、栈深度、对齐方式都会影响嵌入式程序的实际行为。
为什么要讲这个？因为嵌入式开发里，你经常要在中断里频繁调用函数，或者在实时性要求很高的循环里传大结构体。如果每次都把大结构体整个拷贝进栈，栈得开多大？你不懂AAPCS的规则，就理解不了为什么某些编码规范要求“参数超过4个要打包成结构体”“超过16字节用指针”。这些不是洁癖，是硬件规矩。
1.2 实参、形参与“拷贝”的本质
继续往下说。所谓值传递，形参确实是实参的拷贝，但这个拷贝发生在寄存器或栈帧里，它和实参在内存中是完全不同的两个存在。你修改形参，等于换了个新的本子记数，怎么涂改都影响不了原始数据。这一点在嵌入式里尤其要命——很多人写按键扫描、写ADC滤波函数，在函数里改了形参，回到调用方发现原值没变，然后就怀疑编译器有问题，其实只是没理解拷贝语义。
我举个实际的例子。假设你要写一个“把数字限制在0到100之间”的钳位函数，写成void clamp(int value)，在函数里给value赋值，回到调用处根本没用。正确做法是返回值，或者传指针。这段代码我见过无数新手写错，排查半天最后发现是语义理解不对。所以，别急着背“指针传参”，先把“拷贝”这个本质想清楚。
2. 嵌入式开发的三种传参姿势：值、指针、结构体
2.1 值传递：什么时候闭着眼用都没问题
值传递是最安全的传参方式，安全在于隔离。函数收到的是一份拷贝，随便怎么折腾，都不影响调用方。嵌入式里适合值传递的场景很明确：参数是int、float、char这类基础类型，数据量小，且调用方不期望被修改。比如传入一个温度阈值、一个超时毫秒数、一个分频系数，这些都用值传递，干净利落。有一类技巧是利用返回值“传回结果”，比如int get_tick_ms(void)，返回值往往比传指针更自然，也更容易被优化成纯寄存器操作，性能反而更好。
但值传递也有代价。在32位单片机上，一个int传进去可能就占一个寄存器，开销小到可以忽略；可如果你图省事，把一个几百字节的结构体直接当值传，编译器很可能生成一大段内存拷贝代码，既占栈又费CPU。我在STM32的工程里见过一个同事，把配置结构体全用值传递，一次调用拷出去80多字节，栈空间直接告急。这种场景就属于“值传递用错了地方”。
为了更直观，我把三种方式的取舍整理成一个对比表，后面展开细说。
| 传参方式 | 开销 | 是否可能修改原数据 | 典型使用场景 |
|---|---|---|---|
| 值传递 | 小参数低，大对象高 | 不会 | 基础类型、小配置项、只读业务参数 |
| 指针传递 | 固定（一个地址） | 会（通过解引用修改） | 寄存器操作、缓冲区读写、结构体修改 |
| 结构体值传递 | 随字节数线性增长 | 不会 | 极小结构体、只读快照场景 |
2.2 指针传参：操作寄存器和外设的硬性要求
嵌入式开发跟PC开发最大的不同，就是大量代码在操作硬件。你要写寄存器、要改外设配置，数据在某个地址里，函数光靠值拷贝根本碰不到那块内存，这时必须把地址传进去。比如典型的寄存器写函数void REG_Write(volatile uint32_t *addr, uint32_t val)，addr指向的是某个外设寄存器的地址，函数内部解引用才能把val写进硬件。这个场景里，传指针不是“为了让函数改外部变量”，而是为了建立“连接”到具体内存位置的能力——这是嵌入式函数设计的核心思维。
指针传参的坑也随之而来。第一，指针本身其实也是值传递，传进去的是地址值的拷贝，所以你在函数里让形参指针指向别处，调用方的指针并不会跟着变，想改指针本身你得传二级指针。第二，指针可能为NULL，尤其嵌入式里外设基地址经常由编译链接决定，有时候初始化没做就调用，解引用直接进HardFault。所以我现在的习惯是：函数里一进来就判空，哪怕只是断言，也能省很多半夜调板子的时间。
下面是一段我常用的寄存器写函数骨架，你可以直接参考这个模式：
void REG_Write(volatile uint32_t *reg, uint32_t val) { if (reg == NULL) { return; /* 开发期可以放assert，发布版再考虑去掉 */ } *reg = val; }2.3 结构体传参：性能与可读性的平衡
结构体是嵌入式开发里用来组织参数的主力，什么外设配置、传感器数据、任务状态，全都用结构体包着。结构体传参有两条路。第一条是整体值传递，好处是调用方数据完全隔离，坏处是拷贝开销大；第二条是传结构体指针，开销小，但函数内部可能改动原数据，安全性稍弱。我的取舍标准是：结构体小于等于16字节，且不需要修改原对象时，值传递可以接受；超过16字节，一律传指针，并配合const限定。这个16字节不是拍脑门，部分ARM调用约定里，结构体大于16字节通常需要由调用方在栈上复制，而小结构体还有可能通过寄存器传，性能差距非常明显。
工程上还有一个折中方案，就是结构体传const指针。void Sensor_Init(Sensor_Config_t * const cfg)这种写法，既只拷贝一个地址值，又告诉编译器和阅读者：这个指针不能指向别的对象，但对象内容在函数内部实际有可能被修改（除非目标成员也加const）。想真正禁止修改数据，就把形参写成const Sensor_Config_t *cfg，这是我在团队里一直强调的硬性规范。
3. 数组和字符串传参：最容易翻车的两个盲区
3.1 数组退化成指针，长度丢了谁负责
数组在C语言里有个经典退化规则：作为函数参数时，数组名不拷贝整个数组，而是退化成指向第一个元素的指针。这带来一个巨大的坑——你在函数内部用sizeof(arr)得到的已经不是数组总大小，而是指针大小，通常是4或者8。所以经典错误就是：在调用方uint8_t buf[64]; func(buf);，函数内存里sizeof(buf)拿到4，然后按4去操作缓冲区，把整个内存写穿。
解决办法没什么魔法：传数组的同时，显式传长度，函数签名写成void ProcessData(uint8_t *buf, uint16_t len)。不要指望编译器帮你记长度，它真的不记。我在串口接收驱动里写过的所有解析函数都带长度参数，这已经成了肌肉记忆。顺便说个细节：很多新手以为void ProcessData(uint8_t buf[])更安全，其实在函数参数列表里，这个写法和uint8_t *buf完全等价，该传的长度还是得传。
3.2 多维数组传参的正确打开方式
到了二维数组，情况更微妙。void Matrix_Init(uint8_t matrix[8][8])看起来挺规整，但实际参数传递时，编译器仍然把它处理成指针，而且只有第一维会退化，第二维必须固定。所以void Matrix_Init(uint8_t (*matrix)[8], uint8_t rows)才是更直白的写法，意思是“这个指针指向一排含8个uint8_t元素的数组”。这时函数内部访问matrix[row][col]就能正确计算地址偏移。嵌入式里做点阵屏、LED阵列、图像小块处理时经常碰这种需求，很多人在二维数组传参上卡住，其实就是没搞懂“退化的只是一维”。
如果你真的需要运行时动态行列数，那就别用原生二维数组了，直接把数据当作一维数组处理，手动算下标data[row * cols + col]，再把行数列数传进去。这个方式在底层驱动里反而更常见，因为它不依赖编译期常量，也方便直接对接DMA等外设。
3.3 字符串常量传参：const是保护它不是仇人
字符串在嵌入式里常用，但传参时的问题更容易被忽视。字符串字面量"hello"在C语言里是存放在只读存储区的，如果你把char *str作为形参，然后在函数里写str[0] = 'H'，在部分平台上是未定义行为，可能现场崩溃，可能静默改掉不该改的内存。正确的做法是形参用const char *str，明确表示这个字符串只读。嵌入式里经常要把字符串打印出来、拼到日志缓冲区里，形参一律const可以避免一系列低级事故。
这里我也踩过坑。以前写日志模块，函数签名用的是char *fmt，某次被别人调用时传了字符串常量，函数内部执行格式化时去改动源串，直接进了hardfault。后来全部改成const char *fmt，这类问题从根上消失了。注意，const不是限制你，而是把“我不改你的数据”这句话写进代码里，编译器和维护者都看得出来。
4. 参数限定符和嵌入式硬件细节：const、volatile与static
4.1 const限定符：我把“只读”写进了契约
上一节提了const，这里系统说说。const用在形参上，语义是“这个参数指向的数据，函数内部不会修改”。它有三个好处：第一，编译器能帮你在编译期发现误写，比如你声明const Sensor_t *sensor，然后函数里sensor->temp = 25;，编译器直接报错；第二，阅读代码的人能立刻知道函数对数据的影响范围，调用方可以大胆传常量或只读对象；第三，有些优化场景下，编译器可以更大胆地做假设。
但const也有个常见的迷惑点。const uint8_t *p表示p指向的内容不能通过p修改；uint8_t * const p表示指针本身不能改变指向。两者差别很大，尤其是结构体指针场景。我团队里的规约是：凡是只读取外部数据的函数，形参类型写const T *ptr；凡是只读取且不会改动指针位置的，就再加一层* const。这条规约降低了不少review成本。
4.2 volatile：寄存器参数必须知道的修饰符
嵌入式里传参的另一座大山是volatile。当你的指针参数指向的是硬件寄存器时，比如GPIO输出寄存器、DMA状态寄存器，这个地址的数值可能被硬件随时改变，甚至读一次和读一次结果都不同。编译器如果不知道这一点，可能把连续两次读优化成只读一次，或者把两次写优化成只写一次。所以，凡是传给函数用来访问寄存器的指针，形参类型一定要带volatile，比如void Gpio_Write(volatile uint32_t *reg, uint32_t val)。
这实际上是一个传参“类型契约”的问题。调用方传一个普通uint32_t指针进来，函数内部想以寄存器语义访问它，是不安全甚至不合法。我在做外设驱动时，会专门定义寄存器映射指针类型，比如typedef volatile uint32_t *RegPtr_t;，传参就用它，这样整个代码库都清楚哪些指针是“硬件地址”而不是普通内存。别怕volatile拖慢速度，嵌入式访问外设本来就不能乱优化。
4.3 static：一种容易被忽略的“不传参”
还有一种绕开传参的方式值得一提，就是static全局变量或文件内函数。嵌入式代码里，很多状态变量用static放到文件作用域，函数之间通过全局状态互相传递数据，省掉了形参列表。这种做法不是完全不可取，比如一个模块私有变量、不需要模块外部访问，用static确实能让接口更简洁。问题是太多人把static当作传参的替代品，最后代码变成一团乱麻：一个按键状态变量被三四个函数直接改写，查逻辑时根本不知道谁动了它。
我的原则是：如果函数之间需要交互的数据只是模块内部的一两个状态，用static没问题；一旦数据开始牵扯两个以上模块，或者调用关系变得复杂，就该老老实实设计参数。传参表面上多写几行，但它把数据依赖的边界画得清清楚楚。我在做RTOS任务通信时，尽量不用共享全局变量，而是通过函数参数把数据传入任务函数，隔离性立刻上了一个台阶。static修饰的函数本身在嵌入式里很常用，它限制函数只在当前文件内有效，这是另一个好习惯：模块内函数尽量static，暴露出去的接口才写extern。
5. 进阶场景：回调函数与参数传递
5.1 为什么好用的回调函数总带一个context参数
嵌入式里大量使用回调函数，定时器溢出回调、按键事件回调、中断服务程序里派发的回调，本质都是把函数指针作为参数传给另一段逻辑。这里有一个教科书上没那么爱讲、实际项目里绕不开的问题：回调函数触发时，你想让它带点“现场数据”，怎么办？
比如你注册一个按键回调void on_key_pressed(int key)，如果这个回调只能通过一个固定原型被调用，那你想在回调里区分“这是第几个按键”“当前是长按还是短按”“是哪次配置的回调”，就统统没地方塞。所以成熟的回调机制统统加一个“上下文参数”，设计成void on_key_pressed(int key, void *context)，注册回调时你把一个业务结构体的指针作为context绑定进去，回调发生的时候，context原封不动传回给你。这样同一个回调函数可以注册给十个按键，每个按键带各自的上下文，函数之间的传参就从“一条通道”扩展成了“两条通道”：一显式参数，一隐藏上下文。这是我在按键驱动和传感器处理里用得非常多的模式。
5.2 函数指针作为参数：一个按键事件的完整示例
纸上谈兵没意思，给个具体例子。假设我要做一个按键扫描模块，外部想知道某个按键被单击或长按了，注册回调时把按键编号和回调函数一起传进来：
typedef struct { uint8_t key_id; void (*handler)(uint8_t key_id, uint8_t event, void *ctx); void *ctx; } Key_Handler_t; int Key_Register(uint8_t key_id, void (*handler)(uint8_t, uint8_t, void *), void *ctx);注册过程里，用户调用Key_Register(3, my_handler, &my_device);，把my_device这个结构体地址作为context传进去。底层按键检测到事件后，查表找到对应的handler，按handler(key_id, EV_CLICK, handler_item->ctx)方式回调。这样业务层跟驱动层只通过参数往来，驱动层根本不知道业务层的结构体长什么样，却又能在回调时把上下文完整交还。这种解耦思路是我做嵌入式架构时反复用的一套，也是“函数传参”这个主题中最具设计感的一部分。
函数指针传参还需要注意类型匹配。C语言里函数指针类型的检查比较严格，参数不匹配时编译警告很隐晦，我建议把回调函数指针用typedef定义一下，比如typedef void (*KeyEventCb)(uint8_t, uint8_t, void *);，后面注册接口就清爽很多，报错也直观。另外，回调里尽量别做重活，尤其涉及中断上下文时，参数验证、数据拷贝这些轻动作放回调，重逻辑放任务循环，才能保证嵌入式系统的确定性。
6. 踩过的坑和排查经验：传参翻车现场复盘
6.1 高频错误清单：这些坑我全踩过
把这几年的翻车现场整理成几条，基本覆盖传参类Bug的大头。
第一条，值传参改不动实参，这个最基础但也最高频，不了解拷贝语义的新手必踩。第二条，传数组忘了带长度，sizeof拿到指针大小，缓冲区写穿，往往要等系统运行很久才在奇怪的地方崩掉。第三条，指针形参没有判空，初始化顺序稍有不对，解引用空指针直接HardFault。第四条，形参const修饰不当，明明只是读数据却定义成非const指针，导致调用方无法传const对象，只能加一堆难看且危险的强转。第五条，结构体传大对象，栈不够用或者性能受损，在实时循环里尤其致命。第六条，函数指针类型不匹配，各种诡异警告，甚至跳到错误的函数地址执行。
这些错误单独看都不难理解，但组合出现时，排查成本非常高。所以我现在写函数前会先把形参列表过一遍，问自己三件事：这个函数会改动实参吗？数据多大，拷贝得起吗？指针可能为空吗？这三个问题一过，至少一半坑就绕开了。
6.2 排查技巧：从现象倒推传参问题
真出了Bug，怎么快速锁定是传参问题？我总结了一套倒推法。第一，变量值“在函数里明明改了，出来没变”，优先检查是不是传值了，把形参改成指针或返回值试试。第二，缓冲区内容乱掉、地址写穿，优先怀疑数组长度没传或传错，检查所有涉及sizeof的代码。第三，程序莫名其妙进HardFault，在异常处理里打印LR寄存器，看崩在哪个函数，再检查那个函数的指针参数是否有效，有没有判空。第四，程序行为不稳定、优化等级一开就出问题，看看寄存器访问的指针形参有没有加volatile。第五，链接或编译报错涉及函数调用不匹配，检查函数指针类型和形参const匹配。
排查传参问题还有一个利器：在函数入口打印形参值。嵌入式里可以用串口打印，也可以把参数值存到固定调试变量里，然后死循环盯住它。有一次我调一个I2C驱动的超时问题，最后发现是超时计数参数传的是同一个字节的拷贝，函数内部的循环让形参自减，外部计时变量纹丝不动，打印入口值一眼就看穿了。
6.3 几个值得长期坚持的参数设计习惯
传参不只是语法，更是接口设计。我最后分享几个自己坚持了很久的习惯。第一个，函数参数尽量少于4个。参数多了，寄存器装不下，压栈和阅读都费劲，参数打包成一个结构体，接口反而更稳定。第二个，所有只读参数统一加const，让数据契约可视化。第三个，凡是地址参数，函数入口做一次判空断言，开发期用assert(ptr != NULL)，发布版再考虑移除。第四个，结构体大于16字节优先传指针，同时写清楚所有权的边界：谁分配、谁释放、函数会不会存储这个指针。第五个，回调参数永远包含context，宁可多写一个形参，也不要让回调失效后到处打补丁。
这些习惯不能一下子全养成，我先从const和判空开始，坚持两个项目后，review被别人怼的次数明显少了。参数设计漂亮了，整个函数的可读性和稳定性都会跟着上一个台阶。做嵌入式这行，代码可以丑，但接口的边界必须清楚，函数传参就是这条边界上最基础、也最值得打磨的施工技术。
