cv::imread失败时返回空Mat，需立即用img.empty()检查；确保路径为绝对路径或工作目录下文件存在，Windows中反斜杠需转义或使用原始字符串。
cv::imread 读不到图？先查路径和返回值
OpenCV 的 cv::imread 不报错也不提示失败，它只默默返回一个空 cv::Mat。这是最常踩的坑——你以为图片加载了，其实 mat.empty() 是 true。
常见错误现象：cv::imshow 窗口黑屏、崩溃，或直接卡死；用 mat.rows / mat.cols 访问时触发段错误。
- 检查路径是否为**绝对路径**，或确保工作目录（不是源码目录）下真有该文件；Windows 下反斜杠要写成
"./img.jpg"或R"(.\img.jpg)" - 调用后立刻加判断：
if (img.empty()) { std::cerr - 中文路径在 Windows 上大概率失败，别试；Linux/macOS 对编码更敏感，优先用英文路径
-
cv::imread默认按 BGR 读取，不是 RGB —— 这会影响后续颜色处理逻辑，但不影响显示
cv::imshow 黑窗口？记得加 cv::waitKey
cv::imshow 只负责把图像数据“推”到 GUI 窗口缓冲区，不刷新、不阻塞、不维持窗口。没接 cv::waitKey，窗口一闪就关，或者卡住不动。
使用场景：调试查看中间结果、快速验证图像是否加载成功。
立即学习“C++免费学习笔记（深入）”；
- 必须跟
cv::waitKey(0)（无限等待按键）或cv::waitKey(1)（至少 1ms，用于视频循环） - 如果
waitKey参数为 0 但窗口仍闪退，说明前面imread失败了，回看上一节 - 多个
imshow调用共用一个窗口名会复用窗口；不同名字才开新窗，名字含中文可能出问题 - Linux 下没装 GTK 或 Qt 后端时，
imshow可能完全不工作，得换cv::imwrite保存再手动查看
读取模式参数选错，颜色/通道数就错了
cv::imread 第二个参数控制解码方式，默认是 cv::IMREAD_COLOR，但它不是“读成彩色”，而是“转成 3 通道 BGR”。这个细节直接影响后续操作。
-
cv::IMREAD_GRAYSCALE→ 单通道CV_8UC1，适合边缘检测、阈值分割等预处理 -
cv::IMREAD_UNCHANGED→ 保留 alpha 通道（如 PNG），此时可能是 4 通道；但 OpenCV 窗口显示时会忽略 alpha，别指望它透明 - 误用
IMREAD_COLOR读灰度图，结果得到 3 个相同通道的“伪彩色”图，浪费内存且混淆逻辑 - 读取位深高于 8bit 的图（如 16bit TIFF），默认会截断为 8bit；要用
cv::IMREAD_ANYDEPTH配合CV_16UC1类型判断
Linux/macOS 下 imshow 不显示？后端没连上
OpenCV 编译时没链接 GUI 库（GTK、Qt、Carbon），cv::imshow 就是空操作——不报错、不警告、不显示。Windows SDK 通常自带，所以新手容易误以为“只要代码对就行”。
验证方法：运行 cv::getBuildInformation()，搜 GUI 段，看 GTK 或 Qt 是否为 YES。
- Ubuntu 常缺
libgtk-3-dev，装完需重新编译 OpenCV（系统包通常阉割 GUI） - macOS 用 Homebrew 安装时加
--with-opengl --with-qt5（Qt5 支持更稳） - 不想重编？改用
cv::imwrite("debug.jpg", img)把图存下来，终端用open debug.jpg或eog debug.jpg查看 - Docker 或无桌面环境里，
imshow必然失效，别挣扎
真正麻烦的不是语法，是 OpenCV 把“失败静默化”贯彻得太彻底——空 Mat、无 GUI 后端、路径相对性，三者叠加，足够卡人一小时。盯住 empty() 和 getBuildInformation()，比翻文档快得多。
