cudaErrorMemoryAllocation主因是显存不足或驱动异常；cudaMalloc失败后未检查指针即调用cudaMemcpy会导致该错误；应先用nvidia-smi查看显存占用，再做分配与拷贝。
cudaMalloc 和 cudaMemcpy 为什么总报 cudaErrorMemoryAllocation
GPU 显存是独立于主机内存的资源，cudaMalloc 分配失败最常见的原因是显存不足，而不是代码写错了。比如你在 8GB 显存卡上尝试 cudaMalloc(&d_data, 10ULL * 1024 * 1024 * 1024)（10GB），必然失败——连检查都没必要做，直接崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
nvidia-smi实时看剩余显存，别依赖任务管理器 - 分配前加检查：
if (err != cudaSuccess) printf("CUDA error: %s\n", cudaGetErrorString(err)); -
cudaMemcpy报这个错，大概率是目标指针d_data为nullptr（cudaMalloc失败后没处理就继续用了） - 避免在循环里反复
cudaMalloc/cudaFree，显存分配本身有开销，应复用设备内存
kernel 函数必须用 __global__ 修饰，且不能有返回值
CUDA kernel 不是普通 C++ 函数：它没有返回值、不能递归、不能调用标准库函数（如 printf 仅限设备端有限支持）、参数只能是基本类型或设备指针。写成 int my_kernel(...) 或漏掉 __global__，编译器不会报错但运行时根本不会执行——它会被当成主机函数忽略。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- kernel 签名示例：
__global__ void add_kernel(float* a, float* b, float* c, int n) - 调用时必须带执行配置：
add_kernel>>(d_a, d_b, d_c, n);，少一对>>就是主机串行调用，毫无 GPU 加速效果 - 所有传入 kernel 的指针都必须是设备地址（由
cudaMalloc分配），传h_a（主机指针）进去会导致非法内存访问 - 调试时加
cudaDeviceSynchronize()检查 kernel 是否异常退出，否则错误会被静默吞掉
host/device 指针混淆导致段错误或结果全零
CUDA 中主机指针和设备指针完全不兼容。把 float* h_data = new float[N]; 直接传给 kernel，或者用 memcpy(h_data, d_data, ...)（而非 cudaMemcpy），程序可能不崩溃但结果不可预测——常见表现为输出全 0、随机大数，或 cudaErrorIllegalAddress。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 命名习惯强制区分：
h_x（host）、d_x（device），避免混用 - 拷贝方向务必写对：
cudaMemcpy(d_x, h_x, size, cudaMemcpyHostToDevice)是上传；cudaMemcpy(h_x, d_x, size, cudaMemcpyDeviceToHost)是下载 - 不要对
d_x做sizeof(d_x)判断大小——它只是个地址，长度信息在你手里 - 统一用
cudaMallocManaged可规避部分混淆（统一虚拟地址），但会损失性能，仅适合原型验证
nvcc 编译命令和头文件依赖容易漏掉 -lcuda -lcudart
#include <cuda_runtime.h></cuda_runtime.h> 只是声明，链接时缺 -lcudart 会报 undefined reference to 'cudaMalloc'；而调用驱动 API（如 cuInit）才需要 -lcuda。新手常把 nvcc main.cu 当成万能命令，但实际项目中混合了 .cpp 和 .cu 文件时，必须分开编译再链接。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 最简可运行命令：
nvcc -o vecadd vecadd.cu（nvcc 自动链接 cudart） - 混合编译：先
nvcc -c vecadd.cu -o vecadd.o，再g++ main.cpp vecadd.o -lcudart -o app - 检查是否真用了 GPU：运行后执行
nvidia-smi，看对应进程的 “GPU-Util” 是否跳动 - 别用
g++直接编译 .cu 文件——它不认识__global__，会当语法错误
GPU 编程真正的门槛不在语法，而在内存模型和异步执行的理解。一个 cudaMemcpy 调用背后是 PCI-E 总线传输，一次 kernel 启动涉及流调度和 warp 分配——这些细节不暴露在代码里，但每一步出错都会表现为“结果不对”或“程序卡住”，却很难定位到根源。
