Open WebUI 升级后自定义函数失效，先别急着回滚版本。多数情况不是函数本身的逻辑错误，而是升级过程改变了运行环境、插件加载路径或依赖版本，导致已有函数无法被正确加载和注册。处理时先做备份，再按错误信息定位，最后才考虑更换基础镜像或重新编译插件。
升级后自定义函数失效，优先排查插件加载路径和运行环境差异。可以先对比新旧镜像，检查插件依赖和编译链，再决定是否迁移基础镜像。迁移时建议固定基础镜像版本，重新编译自定义函数，并在测试环境验证后切换，避免把环境变更与服务故障混在一起。
先确认失效范围：是全部函数还是个别函数
打开 Open WebUI 服务日志，搜索函数加载相关的报错。如果所有自定义函数都消失，问题通常出在插件加载器或镜像升级后的目录变更，常见原因是新版镜像调整了插件存放位置或移除了旧目录。如果只是个别函数失效，则需要检查该函数的依赖是否仍然存在，以及是否引用了旧版本的动态链接库。可先通过界面或 API 手动触发一次函数，看错误输出的具体堆栈，不要凭感觉去改代码。保留升级前的镜像和插件目录，便于之后做二进制的比对。
这一步的验证方式是：在升级后的环境里再次上传同一个函数文件，如果替换掉原文件后能恢复，说明是旧文件在新环境中不被识别，需要重新生成或重新编译；如果替换后仍不能加载，则要检查插件目录的挂载关系和权限。
迁移基础镜像前，先对比新旧运行时
插件在旧镜像里运行正常，升级后失效，通常不是功能代码变了，而是运行它的基础环境变了。可以用 docker inspect 查看新旧镜像的元数据，包括系统包版本和 Go 版本，再结合插件源码里使用的依赖做判断。若自定义函数是用 Go 插件方式加载（.so），go build 时的版本和运行时的 Go 版本不一致，就会产生“plugin was built with a different version”的加载错误。遇到这类问题，建议先把基础镜像固定到与旧镜像相近的版本，再把插件重新编译为对应版本的二进制。
迁移基础镜像不是单纯把 FROM 换掉。你需要确认新镜像里是否包含插件运行所需的系统库，比如 libc 版本、网络库、证书目录等。对于 Go 插件，还要注意编译时是否开了 CGO_ENABLED=1，因为静态编译与动态链接在新环境中行为不一致。
操作时可以这样：先拉取一个不确定的基础镜像，启动一个临时容器，在容器里直接执行函数加载命令；成功后，再把函数目录挂载到正式容器中。这个顺序能帮你把「镜像兼容」和「数据持久化」分开排查。
重新编译并正确挂载自定义函数
如果你的自定义函数是 Go 插件，重新编译时注意三点：第一，使用与运行镜像内 Go 版本一致或向后兼容的工具链；第二，保持插件导出符号不变，避免因函数名大小写变化导致注册失败；第三，明确指定目标操作系统和架构，例如 GOOS=linux GOARCH=amd64。下面是一个通用的构建片段，具体参数需要按你的函数目录调整：
cd /path/to/your/custom-function
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -buildmode=plugin -o custom-fn.so .
ls -lh custom-fn.so将编译产物放到 Open WebUI 的插件目录。如果你用 Docker 部署，可以用 docker cp 复制进去，或者在启动容器时通过 -v 参数挂载宿主机目录。挂载比复制更适合后续调试，因为它允许你在不重建容器的情况下替换插件文件。建议在正式切换前，先在一个测试容器里重复“启动实例 → 调用函数 → 读取日志”的循环，确认新镜像对插件没有隐藏的版本依赖。
验证函数恢复使用的流程
- 查看容器启动日志，确认插件目录被正常扫描，没有错误信息。
- 在界面上找到函数列表，确认目标函数已经重新出现，且状态不再显示“加载失败”。
- 调用一次简单函数，观察返回结果是否与升级前一致。
- 再调用一个依赖外部服务的函数，确认网络和权限配置没有随迁移丢失。
- 连续观察一段时间，确认函数未被后台任务意外卸载。
整个过程里，需要始终保留一份升级前的镜像和插件目录快照。这样万一迁移失败，可以快速回滚，而不是在不确定的状态里反复调整。理解这些步骤的边界：如果你使用的是非 Docker 部署，或函数不是 Go 插件，那么“迁移基础镜像”的部分就换成系统依赖升级或解释器版本调整，排查思路仍然适用。