Redis MODULE LIST 怎么核对扩展模块：版本字段、加载状态与线上风险

线上 Redis 实例出现了一个应用没有登记过的扩展模块，先别急着重启或卸载。用 MODULE LIST 读取当前实例的模块清单，再对照发布记录核对 name、ver 和 path，通常能先分清“确实加载了什么”和“它是否应该存在”。

MODULE LIST 只负责报告当前实例已加载的模块；它不会替你判断模块是否安全，也不会证明模块文件来自哪次发布。安全核对要把返回字段与变更单、文件路径和重启后的复测结果连起来。

先确认 MODULE LIST 返回的是什么

在有权限的维护窗口执行：

redis-cli -h 127.0.0.1 -p 6379 MODULE LIST

返回值是一个数组，数组中的每一项描述一个已加载模块。不同 Redis 版本和模块实现可能附带不同字段，但排查时最值得先记录的是模块名、版本、动态库路径以及加载参数。不要只截图第一行；完整输出才能支持后面的变更核对。

把模块名、版本和路径连成一条核对链

可以把每一项看成一条简单的数据路径：MODULE LIST 产生模块项，模块项再拆成 name、ver、path，最后与发布记录逐项比对。下面这段 shell 只是帮助人工留档，不能替代权限审计：

redis-cli MODULE LIST > module-list.txt
grep -E 'name|ver|path' module-list.txt

这里的关键不是 grep 出多少行，而是确认同一模块的三个字段仍属于同一条返回记录。若模块名对得上、版本对不上，先查发布单；若版本对得上、路径变了，则要检查启动参数、容器镜像和挂载目录。

看到多余模块时先做只读确认

发现陌生模块不要直接执行卸载命令。先保存命令输出、实例标识和采集时间，再查配置文件或启动编排中是否声明了对应模块。一个模块可能由镜像默认配置加载，也可能由运维脚本在启动时注入；只看当前命令无法判断来源。

升级或回滚时如何判断风险

变更前记录模块清单，变更后在同一实例再次执行 MODULE LIST。至少检查三个结果：预期模块仍存在，ver 与目标版本一致，path 指向本次发布允许的目录。若回滚后模块版本回去了但路径没有回去，说明运行环境仍可能混用了新旧文件。

对于带参数的模块，还要比较参数顺序和内容。参数变化可能影响命令注册、数据格式或启动行为；不要因为 name 没变就把这次变更判定为无风险。

一份可落地的回归检查清单

1. 在变更前执行 MODULE LIST，保存完整输出和实例身份。
2. 逐项核对 name、ver、path 与发布记录。
3. 变更后重复执行命令，比较模块数量、版本、路径和参数。
4. 发现不一致时暂停后续发布，先确认镜像、启动参数和挂载目录。

如果实例由多个副本组成，不要只检查一台。逐台采集清单后再比较，某个副本独有的模块往往比“全部实例都加载了错误版本”更容易被忽略。

相关问题

MODULE LIST 能证明模块文件安全吗？

不能。它证明模块当前已被实例加载，并提供运行时返回字段；文件来源、哈希、权限和审批记录仍要在部署系统和主机侧核对。

为什么只看模块名不够？

同名模块可能对应不同版本、不同路径或不同参数。至少把 name、ver、path 放在同一份变更记录里比较。

小结

MODULE LIST 适合做运行时盘点：它先给出当前加载状态，再把模块名、版本、路径和参数交给发布核对。把变更前后两次输出留存下来，才能把“模块在不在”推进到“它是不是这次应该加载的版本”。