py2app不会自动打包系统级dylib（如libpng.dylib），必须在setup.py中用binaries或frameworks显式声明路径，并用install_name_tool修复@rpath，否则运行时因路径失效报错。
py2app 不会自动扫描或打包系统级动态库（如 libz.dylib、libpng.dylib、libjpeg.dylib），它只处理 Python 模块和明确声明的依赖项。你看到的“找不到”不是路径问题，而是这些 dylib 根本没进包。
py2app 默认不收集任何系统 dylib
不同于 PyInstaller 对部分 C 扩展有基础 hook 支持，py2app 的依赖分析完全基于 import 语句 + packages/includes 配置。像 Pillow、OpenCV 这类通过 ctypes 或 C 扩展隐式加载 .dylib 的库，py2app 看不见它们底层依赖的系统库。
- 例如：Pillow 加载 PNG 图片时调用的是系统
libpng，但你的代码里没import libpng—— py2app 就不会打包它 - 又如：某些科学计算库链接了
openblas或gfortran的 dylib，这些也不会被自动识别 - macOS 的 Framework（如
Qt5Core.framework）同样不会被自动包含，除非你显式用frameworks参数声明
如何让 py2app 包含缺失的 dylib
必须手动干预，靠 setup.py 中的 options 字段补全：
- 用
binaries列表显式添加 dylib 文件路径：['/usr/lib/libz.dylib', 'lib']表示把该 dylib 复制到 app 内部的Contents/MacOS/lib/目录下 - 用
frameworks添加完整 Framework：['/usr/local/opt/qt5/lib/QtWidgets.framework']（注意路径要真实存在） - 若 dylib 在 Homebrew 路径下（如
/opt/homebrew/lib/libpng.dylib），确保你用的是当前环境能访问到的路径，而不是系统默认路径 - 打包后检查
YourApp.app/Contents/MacOS/及子目录，确认 dylib 已写入；再用otool -L your_script查看可执行文件是否仍引用外部路径
运行时 dylib 路径失效的典型表现
即使 dylib 被打进去了，程序启动仍可能报 Library not loaded: @rpath/libpng.16.dylib —— 这说明二进制文件里记录的加载路径（@rpath）没被正确重写。
立即学习“Python免费学习笔记（深入）”；
- py2app 不会自动修改已编译 dylib 的
LC_RPATH或LC_ID_DYLIB，需要你提前用install_name_tool修复 - 常见修复命令：
install_name_tool -add_rpath "@executable_path/lib" your_dylib.dylib，然后才放进binaries - 更稳妥的做法是：在打包前用
otool -L检查所有依赖 dylib 的加载路径，确保它们都指向相对位置（如@rpath/xxx.dylib），而非绝对路径（如/opt/homebrew/lib/xxx.dylib） - 如果 dylib 来自第三方 SDK（比如硬件厂商提供的
vendor.dylib），大概率需要你自己重签名 + 重设 rpath，否则 macOS Gatekeeper 会拦截
比 dylib 更容易被忽略的是 Python 扩展模块的 .so 依赖
比如你用了 cv2，py2app 会打包 cv2.cpython-*.so，但它内部依赖的 libopencv_core.4.5.dylib 等并不会跟着进来 —— 这些才是真正的“系统动态库”。
- 不要只盯着
/usr/lib，先用otool -L cv2/.so查出所有依赖项，再逐个加进binaries - Homebrew 安装的 OpenCV，其 dylib 通常在
/opt/homebrew/opt/opencv/lib/；MacPorts 则在/opt/local/lib/ - 如果你用
pip install opencv-python，它的 dylib 是静态链接进.so的，一般不额外缺 dylib —— 但换成opencv-contrib-python或源码编译版就另当别论
真正麻烦的从来不是“怎么加”，而是“加哪些”——你得先用 otool -L 和 find 把所有隐式依赖挖出来，再一个一个喂给 binaries。漏一个，程序就在某台机器上静默崩溃。
