夜雨聆风插件是 bowenliang123/md_exporter:3.6.9。我的验证环境是本地 Dify 1.7.2，不是云服务，也不是改造版部署，而是按 Dify 官方提供的 docker-compose 方案在本机启动的一套完整环境。
本机是 macOS Apple Silicon，架构是 arm64；但插件实际运行在 Dify 的 Linux 容器里，目标平台是 Linux ARM64 / aarch64，Python 运行环境是 3.12。
最后验证时，我关闭了 macOS 网络，只通过 Dify 页面本地上传重新打包后的 .difypkg，插件依然可以完成安装。这才算是真正验证了这个包可以离线安装。
先说结论
最终生成的离线包可以在本地 Dify 1.7.2 中离线安装。
验证结果是：
bowenliang123/md_exporter 3.6.9status: Installed这个包里已经包含目标 Linux ARM64 / Python 3.12 环境需要的依赖 wheel。安装时不需要再访问 PyPI，也不是依赖本机网络临时补包。
必须先改 Dify 的 .env
这里有一个容易漏掉的前置条件。
Dify 本地 docker-compose 环境需要调整 dify/docker/.env 中的配置，否则本地上传离线插件包可能会被签名校验或上传大小限制拦住。
我这里确认使用了这几项：
# 允许安装非市场插件FORCE_VERIFYING_SIGNATURE=false# 允许插件大小最多为 500MBPLUGIN_MAX_PACKAGE_SIZE=524288000# 允许上传更大的内容NGINX_CLIENT_MAX_BODY_SIZE=500M因为离线包会把依赖 wheel 一起打进 .difypkg，体积会明显变大。如果还使用默认上传限制，可能还没进入依赖安装阶段，就已经被 Nginx 或插件包大小限制拦住。
配置完成后，需要重新启动相关容器，再上传 .difypkg 做安装验证。
一开始看到的错误是误导性的
Dify 页面和安装任务里看到的错误类似：
init environment failed too many timespackage is corrupted or your network is unstable这个提示不能直接当根因。
它只是一个汇总提示，意思是插件环境初始化失败太多次。真正要看的，是 plugin_daemon 日志里更早出现的第一个真实错误。
这次第一轮真正的错误是：
Because pandas[excel]==3.0.3 has no wheels with a matching platform tag ...manylinux_2_39_aarch64这句话已经把方向说明白了：不是 .difypkg 文件损坏，而是依赖 wheel 的平台标签不匹配。
macOS arm64 不等于 Linux ARM64
这里最容易踩的坑是：本机是 Apple Silicon，也是 arm64，于是直觉上会以为本机打包出来的依赖也能给 Linux ARM64 用。
实际不行。
macOS arm64 打出来的是 macosx_arm64 wheel，Linux 容器不能安装。Dify 的插件运行环境需要的是 manylinux_aarch64 或 linux_aarch64 wheel。
后面还遇到过一个更隐蔽的问题：有个 Docker 镜像 metadata 看起来是 linux/arm64，但容器里实际跑出来 uname -m 还是 x86_64。结果重打包后的 .difypkg 里仍然混进了大量 x86_64 wheel。
所以只看 docker image inspect 不够。
真正要确认的是容器内部事实：
dpkg --print-architecturefile /usr/local/bin/python3.12python -m pip debug --verbose这三项分别确认：
系统包架构是 arm64Python 二进制是 ARM aarch64 ELFpip 支持 manylinux_*_aarch64 tag只有这些都通过，才说明这个打包环境是真的 Linux ARM64 Python 3.12。
重新打包后的第一个问题解决了
拿到真实 Linux ARM64 打包环境后，重新打包 md_exporter 3.6.9。
这次包里的关键依赖已经变成了正确平台，例如：
pandas-3.0.3-...manylinux_2_24_aarch64.manylinux_2_28_aarch64.whlpypandoc_binary-1.16.2-...manylinux_2_17_aarch64.manylinux2014_aarch64.whlcffi-2.1.0-...manylinux2014_aarch64.manylinux_2_17_aarch64.whllxml-6.1.1-...manylinux_2_26_aarch64.manylinux_2_28_aarch64.whl同时检查最终包：
unzip -l bowenliang123-md_exporter_3.6.9-linux-arm64.difypkg | grep -E 'x86_64|macosx'结果无输出。
这说明旧问题已经解决：包里不再混入 x86_64 或 macOS wheel。
但第二个真实错误出现了
安装到 Dify 后，pandas 平台问题消失了，但 plugin_daemon 又给出了新的首个真实错误：
Failed to download and build `odfpy==1.4.1`No solution found when resolving: `setuptools>=40.8.0`Because setuptools was not found in the provided package locations ...这次问题变了。
odfpy==1.4.1 下载到的是源码包 tar.gz。Dify 离线安装时使用包内依赖，不会再去外部网络补构建工具。于是它想现场构建 odfpy，却找不到 setuptools。
所以这不是平台标签问题，而是离线包里还留下了需要现场构建的源码包。
最终修复方式
处理方式很直接：不要让 Dify 离线安装时再构建 odfpy。
我在真实 Linux ARM64 Python 3.12 打包容器里，提前把：
odfpy-1.4.1.tar.gz构建成：
odfpy-1.4.1-py2.py3-none-any.whl然后从最终包里删除 odfpy-1.4.1.tar.gz，重新封包。
最终包内检查结果：
无 x86_64无 macosx无 tar.gz关键依赖都是 aarch64/manylinux wheel 或 py3-none-any wheel其中 odfpy 已经变成：
wheels/odfpy-1.4.1-py2.py3-none-any.whl最终离线验证
最后我做了一个更严格的验证。
在本地 Dify 1.7.2 官方 docker-compose 环境中，先确认 .env 已允许非市场插件和 500MB 上传：
FORCE_VERIFYING_SIGNATURE=falsePLUGIN_MAX_PACKAGE_SIZE=524288000NGINX_CLIENT_MAX_BODY_SIZE=500M然后关闭 macOS 网络。
接着在 Dify 页面里上传重新打包后的 .difypkg，安装仍然成功：
bowenliang123/md_exporter 3.6.9status: Installedplugin_daemon 日志里也可以看到插件被正常加载和启动：
pre-loaded the plugin bowenliang123/md_exporter:3.6.9plugin bowenliang123/md_exporter:3.6.9 startedInstalled tool: md_exporter这说明这个包已经是可以在当前目标环境中离线安装的包。
这次的经验
这次最大的收获不是某一条命令，而是排查顺序。
不要把最后的汇总提示当根因。
package corrupted、failed too many times、network is unstable 这类提示只能说明安装失败了，不能说明为什么失败。
真正有价值的是第一个真实错误。
这次排查下来，错误其实分成两层：
第一层是平台问题：旧包里混入了 x86_64 或 macosx wheel，Linux ARM64 容器不能用。
第二层是离线完整性问题：odfpy 还是源码包，离线安装时需要现场构建，但包内没有构建依赖。
对应的解决方式也很清晰：
真实 Linux ARM64 Python 3.12 环境打包验证容器内 Python 和 pip tags包内只保留目标平台可用 wheel把源码包提前构建成 wheel关闭网络后做最终安装验证工程排障里，很多时间不是花在“修”，而是花在证明自己没有猜错。
这次也是一样：每次只改一个变量，每次继续前都验证。
