cudaMalloc分配失败需检查cudaError_t返回值而非布尔值，主因是显存不足或上下文干扰；必须用cudaGetErrorString获取错误信息，且cudaFree前须确保kernel执行完毕，避免释放正在使用的显存。
必须成对调用 cudaMalloc 和 cudaFree，且 cudaFree 只能释放 cudaMalloc 分配的指针；传入非法地址、重复释放、或释放主机内存都会触发 cudaErrorInvalidValue 错误。
cudaMalloc 分配失败时怎么判断和处理
返回值是 cudaError_t 类型，不是布尔值，不能直接用 if (cudaMalloc(...)) 判断成功与否。常见错误是忽略返回值，导致后续 kernel 启动失败却找不到原因。
- 始终检查返回值：
cudaError_t err = cudaMalloc(&d_data, size); if (err != cudaSuccess) { fprintf(stderr, "cudaMalloc failed: %s\n", cudaGetErrorString(err)); return -1; } - 分配失败主因是显存不足，但不一定是“显存被占满”——驱动保留内存、上下文开销、未释放的旧设备指针都可能干扰
- 不要用
nullptr判断是否分配成功：即使失败，d_data的值也不会被cudaMalloc修改（除非你传入了未初始化的野指针）
cudaFree 释放前要不要置空指针
要，但目的不是防止 cudaFree 崩溃（它对 nullptr 是安全的），而是避免后续误用已释放地址引发 undefined behavior 或二次释放。
-
cudaFree(d_data); d_data = nullptr;是必要习惯，尤其在多分支或异常路径中 - 如果指针是局部变量，作用域结束自动销毁，置空意义不大；但如果是类成员或全局指针，不置空极易在后续
if (d_data)判断中误触发访问 - 注意：
cudaFree(nullptr)返回cudaSuccess，但不会报错不代表可以跳过检查逻辑
为什么不能用 free() 释放 cudaMalloc 分配的内存
因为 cudaMalloc 分配的是 GPU 显存，物理上不经过主机页表管理，free() 完全无法识别该地址空间，强行调用会触发段错误或静默失败（取决于运行时环境）。
- 主机内存（
malloc）和设备内存（cudaMalloc）由完全独立的内存子系统管理，API 不可混用 - 常见混淆点：
cudaMallocHost分配的是页锁定主机内存，它可以用cudaFreeHost释放，但绝不能用free()——虽然地址看起来像主机指针，但它已被 GPU DMA 引擎映射 - 调试时若看到
cudaErrorInvalidValue且确认指针非空，第一反应应是检查是否把malloc指针误传给了cudaFree
释放时机不当会导致什么问题
最典型的是 kernel 还没执行完就调用 cudaFree，造成显存提前回收，后续 kernel 访问野地址，行为不可预测（可能 crash，也可能读到垃圾数据）。
- 必须确保 kernel 执行完成：
cudaFree(d_data)前加cudaDeviceSynchronize()，或使用流（stream）并搭配cudaStreamSynchronize() - 异步 kernel 启动后立即释放，等于“释放正在被 GPU 使用的内存”，CUDA 不保证任何保护机制
- 在 C++ RAII 场景下，析构函数里释放显存时，务必确认所属流已同步，否则对象销毁后 kernel 仍在跑，极易踩坑
真正容易被忽略的是：cudaFree 本身是同步操作，但它的同步性只针对“释放动作”的可见性，不保证之前所有 kernel 都已完成——这个责任永远在程序员手上，CUDA 不会替你做依赖推断。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
