OpenCV 的 cv::resize 不支持 GPU 加速，必须用 cv::cuda::resize 配合 cv::cuda::GpuMat 及 upload/download；缩小应选 cv::INTER_AREA，放大则用 INTER_LINEAR 或 CUBIC；手写双线性需注意坐标截断、边界钳位和向量化对齐。
用 OpenCV 的 cv::resize 直接调用 GPU 加速？别试了
OpenCV 的 cv::resize 默认是纯 CPU 实现，即使你链接了 CUDA 版 OpenCV，cv::resize 也不会自动走 GPU——它不支持 CUDA 后端加速。想靠改个插值参数就获得 GPU 加速，行不通。
真正能触发 GPU 加速的，是 cv::cuda::resize，但它要求输入必须是 cv::cuda::GpuMat，且需显式调用 CUDA 模块。常见错误是直接把 cv::Mat 传给 cv::cuda::resize，结果报错 OpenCV(4.x): error: (-215:Assertion failed) src.isContinuous() && src.depth() == CV_8U 或更隐蔽的内存访问异常。
- 必须先用
upload()把cv::Mat拷贝到 GPU 显存：gpu_src.upload(cpu_src) - 目标
cv::cuda::GpuMat需预分配尺寸，不能传空对象 - 缩放完记得用
download()拿回 CPU 内存，否则后续无法保存或显示
cv::INTER_AREA 缩小时比 cv::INTER_LINEAR 更准，但不是万能的
很多人默认用 cv::INTER_LINEAR，但在图像缩小（downscale）场景下，它容易产生摩尔纹和细节丢失。OpenCV 文档明确说：cv::INTER_AREA 是为缩小专门优化的重采样方法，它基于像素区域关系（pixel area relation），不是简单插值。
实际效果差异明显：对一张 1920×1080 的建筑图缩小到 480×270，INTER_LINEAR 会让砖缝模糊成灰带，而 INTER_AREA 能保留边缘锐度和纹理节奏。但它只在缩小有效；放大时会退化成最近邻行为，视觉质量反而更差。
立即学习“C++免费学习笔记（深入）”；
- 缩小必选
cv::INTER_AREA，尤其源图含高频细节（文字、栅格、线条图） - 放大时切回
cv::INTER_LINEAR或cv::INTER_CUBIC，别硬套INTER_AREA - 注意：如果用
fx/fy参数而非dsize，INTER_AREA在非整数倍缩放时可能有轻微偏差
自己写双线性缩放？先避开这几个边界坑
手写双线性插值看似可控，但实际极易因坐标映射和边界处理出错。最常踩的坑不是公式写错，而是浮点-整数转换时的截断方向和越界访问。
比如目标点 (x, y) 映射到原图坐标 (src_x, src_y)，正确做法是：src_x = x * scale_x，然后取 floor(src_x) 和 ceil(src_x) 得到左右像素索引——但若直接用 (int)src_x，负数时会向上取整（C++ 中 (int)-1.9 是 -1，不是 -2），导致采样错位。
- 用
std::floor()或static_cast<int>(std::floor(src_x))</int>确保向下取整 - 四个采样点索引必须做显式 clamping：
clamp(x0, 0, w-1)，不能依赖条件跳过计算 - 权重计算用
src_x - x0，不是x0 + 1 - src_x，否则在边界处权重和不为 1 - 若图像宽高不是 4 的倍数，SSE/AVX 向量化时需额外处理尾部像素，否则崩溃
SIMD 加速真有用，但 Vc 库比手写 intrinsics 更稳
用 AVX2 对双线性缩放内层循环向量化，实测可提升 3–5 倍吞吐（1080p→540p 场景）。但直接写 _mm256_load_ps 等 intrinsics 容易出错：对齐要求没满足、寄存器复用冲突、跨平台编译失败。
Vc 库封装了这些细节，比如 Vc::float_v 自动匹配当前 CPU 支持的最优指令集（SSE/AVX/AVX2），且内存加载自动处理未对齐情况。你只需把标量循环改成向量步进，核心逻辑几乎不变。
- 把单像素插值函数改写为接受
Vc::float_v输入，返回Vc::float_v输出 - 循环步长用
float_v::size()（通常是 4 或 8），末尾用mask处理剩余像素 - 避免在向量化代码里混用
std::sqrt等标量函数，Vc 提供Vc::sqrt() - 编译时加
-mavx2（GCC/Clang）或/arch:AVX2（MSVC），否则 Vc 会降级到 SSE
真正麻烦的是混合缩放：既要处理不同通道（RGBA）、又要应对 stride 不对齐的图像数据、还得兼容 BGR/RGB 排列——这些细节比算法本身更耗调试时间。
