FreeRTOS中任务函数必须为void (*)(void*)类型，pvParameters是唯一合法传参途径；裸指针不能用于调度，仅结构体地址、堆分配指针或intptr_t转换后的整数可安全传递。
RTOS中不能直接用裸指针传任务函数
实时操作系统（如FreeRTOS、Zephyr、RT-Thread）的任务创建接口从不接受 void* 指针作为“任务主体”，更不会让你传一个指向函数的指针（如 void (*task_func)()）然后由内核直接调用。这是因为任务上下文切换需要完整的栈帧、寄存器保存/恢复、优先级和状态管理，裸指针无法承载这些语义。
常见错误是写类似这样的代码：
void my_task() { while(1) { /* do work */ } }
xTaskCreate((TaskFunction_t)my_task, ...); // FreeRTOS中看似可行，但本质不是“用指针调度”，而是注册函数地址供内核封装成任务控制块（TCB）- 你传的
my_task是函数名，它在编译期求值为函数入口地址，类型是TaskFunction_t（即void (*)(void*)），不是运行时可变的指针变量 - 真正参与调度的是内核分配的
TaskHandle_t（本质是 TCB 地址），这个句柄才是后续vTaskSuspend()、vTaskResume()等操作的目标 - 如果你试图用局部变量指针（如
&my_task）或临时分配的函数指针变量去传参，会触发编译警告或运行时崩溃——函数指针必须指向静态生命周期的函数
如何用指针安全传递任务参数
任务函数签名固定为 void task_func(void* param)，其中 param 是唯一可传入的用户数据。这里的 param 才是你真正能自由使用的指针——但它只能用于传参，不能用于调度决策本身。
- 传结构体地址最常用：
MyTaskConfig* cfg = pvPortMalloc(sizeof(MyTaskConfig)); ... xTaskCreate(my_task, ..., (void*)cfg); - 避免传栈地址：不要写
MyTaskConfig cfg; xTaskCreate(..., (void*)&cfg);—— 任务还没启动，cfg内存可能已被复用 - 传整数需强转：
xTaskCreate(my_task, ..., (void*)(intptr_t)priority_offset);，接收端再转回：int offset = (int)(intptr_t)pvParameters;，否则在64位平台可能截断 - FreeRTOS 的
pvParameters不做所有权转移，内存释放必须由创建者或任务自身协调，否则易内存泄漏
用指针管理多个任务句柄便于动态控制
当你需要批量启停、查询或删除任务时，把 TaskHandle_t 存进数组或链表是标准做法。注意：这些句柄是内核内部结构指针，不可解引用，只可用于 API 调用。
立即学习“C++免费学习笔记（深入）”；
- 声明数组时用
TaskHandle_t task_handles[4];，创建后存入：xTaskCreate(..., &task_handles[i]); - 不能用
sizeof(task_handles)/sizeof(task_handles[0])在中断里遍历——RTOS 任务句柄数组本身不是原子对象，多任务并发访问需加临界区或互斥量 - 删除任务前务必检查句柄是否非
NULL：if (task_handles[0] != NULL) vTaskDelete(task_handles[0]); task_handles[0] = NULL;，否则重复删会触发断言失败 - Zephyr 中对应的是
k_tid_t，它本质是线程对象指针，但同样禁止手动free()或delete
为什么不用函数指针数组实现“动态任务调度”
有人想用 void (*task_table[])(void*) = {task_a, task_b, task_c}; + 索引切换任务逻辑，这是误解了“调度”的含义。RTOS 调度器决定的是哪个任务获得 CPU 时间片，而不是在几个函数间跳转执行。
- 这种写法最多实现单任务内的状态机，不是多任务并发；所有函数仍在同一栈、同一上下文中运行，无优先级、无抢占、无阻塞语义
- 若强行在一个任务里循环调用不同函数指针，会阻塞整个任务，其他高优先级任务无法响应——违背实时性根本目标
- 真正动态调度靠的是
vTaskPrioritySet()、xTaskNotify()、队列/信号量唤醒等机制，不是靠换函数指针 - 函数指针数组本身没有 RTOS 上下文支持，也不能被调度器识别或管理
最关键的细节：所有任务句柄、TCB、栈内存都由内核在堆上分配，而你在应用层持有的指针只是对它们的引用。一旦内核回收了某任务资源，你手里的指针就变成悬垂指针——这点比通用 C++ 更危险，因为 RTOS 很少做运行时指针有效性检查。
