在 macOS 上使用 cv2.imshow 配合 cv2.destroyAllWindows() 循环显示图像时，会持续累积内存占用，导致明显内存泄漏；根本原因在于 destroyAllWindows() 在 macOS 后端存在未释放资源的 Bug。

在 macos 上使用 `cv2.imshow` 配合 `cv2.destroyallwindows()` 循环显示图像时，会持续累积内存占用，导致明显内存泄漏；根本原因在于 `destroyallwindows()` 在 macos 后端存在未释放资源的 bug。

该问题并非 cv2.imshow 本身设计缺陷，而是 OpenCV 在 macOS（特别是基于 Cocoa/Quartz GUI 后端）中对窗口资源清理逻辑的实现漏洞。调用 cv2.destroyAllWindows() 并不能真正释放所有关联的图像缓冲区与窗口句柄，尤其在高频循环中反复创建同名窗口（如 'Image'）时，旧窗口资源持续滞留，最终表现为 Python 进程内存线性增长——图像分辨率越高，单次泄漏量越显著（如 4K 图像比 360p 泄漏更快）。

✅ 推荐解决方案：避免调用 cv2.destroyAllWindows()，改用 cv2.destroyWindow() 精确销毁目标窗口

import cv2
import numpy as np

flag = False
window_name = 'Image'

# 首次创建窗口（可选，但建议显式指定）
cv2.namedWindow(window_name, cv2.WINDOW_AUTOSIZE)

while True:
    img = np.zeros((2160, 3840, 3), np.uint8)
    if flag:
        img = cv2.circle(img, (1920, 1080), 128, (255, 255, 255), -1)
    flag = not flag

    cv2.imshow(window_name, img)
    k = cv2.waitKey(1)  # 注意：waitKey(1) 避免无限阻塞，单位为毫秒

    # ✅ 正确做法：仅销毁指定窗口，不调用 destroyAllWindows()
    if k == 27:  # ESC 键退出
        cv2.destroyWindow(window_name)  # 精准释放
        break

⚠️ 关键注意事项：

macOS Automator Services

部署和使用军舰的 macOS Automator 自动化服务集合。包含 5 个实用工作流：PDF转JPG、PNG重命名并转JPG、图像拼接、解压RAR、顺序命名图像文件。一键安装所有服务到 ~/Library/Services/ 目录。使用场景：(1) "安装我的自动化服务"，(2) "部署所有 Automato...

下载

• 永远不要在循环内调用 cv2.destroyAllWindows() —— 这是 macOS 下泄漏的直接诱因；
• 使用 cv2.namedWindow() 显式声明窗口（非必需但增强可控性）；
• cv2.waitKey() 参数建议设为 1 或合理毫秒值（如 10），避免无响应假象，同时保障 GUI 事件处理及时性；
• 若需多窗口管理，请为每个窗口分配唯一名称，并在退出前逐一 destroyWindow()；
• 升级 OpenCV 至最新版（如 4.10+）仍可能复现此问题，官方尚未修复，因此规避策略优于等待补丁。

? 补充建议（长期稳健性）：
对于生产级图像可视化需求（尤其长时间运行或资源敏感场景），可考虑替代方案：

• 使用 matplotlib.pyplot.imshow() + plt.ion() 实现实时更新（无 GUI 后端依赖，跨平台稳定）；
• 或切换至轻量 GUI 框架（如 PyQt5/PySide6 + QLabel.setPixmap()）进行完全可控的图像渲染。

综上，该问题本质是平台特定的 OpenCV 实现缺陷，通过精准窗口管理即可彻底规避，无需降级版本或牺牲功能。