MongoDB要求keyFile必须字节级完全一致且为同一份文件：用scp -p同步、sha256sum逐字符比对验证；权限严格设为400、属主mongod:mongod、SELinux上下文为mongod_etc_t；配置中security.keyFile须为绝对路径且clusterAuthMode: keyFile显式声明。
不是内容相同就够了，MongoDB校验的是字节级完全一致，且启动时必须加载同一份文件——哪怕用echo或scp -a生成/传输，都可能引入不可见差异。
keyfile必须是同一份文件，不能只是“内容看起来一样”
常见错误是：在节点A上生成keyfile，然后用cat keyfile | ssh nodeB 'tee /etc/mongod-keyfile'复制过去。这会破坏原始二进制流，尤其当终端或SSH层做字符编码转换时（比如把LF转CRLF、过滤控制字符）。sha256sum不一致就是铁证。
- 正确做法：用
scp -p（保留权限和时间戳）或rsync --checksum同步原始文件 - 验证命令必须在每个节点执行：
sha256sum /etc/mongod-keyfile，输出字符串要逐字符比对 - Windows编辑器保存的keyfile即使内容“肉眼相同”，也大概率含BOM或换行符污染，直接废弃
keyfile路径配置错一个字符就失败
security.keyFile在mongod.conf中必须写绝对路径，且不能有空格、多余斜杠或shell扩展符号。MongoDB不解析~或环境变量，也不做路径拼接。
- 错误示例：
keyFile: ~/keyfile、keyFile: "/etc//mongod-keyfile"、keyFile: "/etc/mongod-keyfile "（末尾空格） - 正确写法：
keyFile: "/etc/mongod-keyfile"，且该路径在所有节点上ls -l可确认存在 - 验证方式：用
sudo -u mongod cat /etc/mongod-keyfile在每个节点上直试——读不出就说明路径或权限已卡住
权限+属主+SELinux三者缺一不可
MongoDB 5.0+强制要求400权限，但只改权限还不够。属主错误或SELinux上下文不匹配时，ls -l看着全对，服务照样起不来。
- 顺序必须是：
chmod 400 /etc/mongod-keyfile && chown mongod:mongod /etc/mongod-keyfile（先改权限，再改属主，否则chown可能重置权限） - SELinux启用时，运行
ls -Z /etc/mongod-keyfile，上下文类型应为mongod_etc_t；不是就补：chcon -t mongod_etc_t /etc/mongod-keyfile - 父目录（如
/etc）也要让mongod用户有x权限，否则进不去目录——ls -ld /etc末三位至少含--x
clusterAuthMode没显式配对keyFile也会静默失败
从MongoDB 4.2起，clusterAuthMode: keyFile必须明确写在配置里。它默认不是keyFile，也不是自动推断的。漏掉这行，节点间心跳请求会被拒绝，但日志里往往只报No keys found for replica set这种模糊提示。
- 配置项位置：必须在
security:块下，与keyFile:同级，例如：
security: keyFile: "/etc/mongod-keyfile" clusterAuthMode: keyFile
"rs0"和rs0会被解析为不同值sudo systemctl restart mongod，reload不生效最容易被忽略的是：你以为keyfile“内容相同”就万事大吉，其实MongoDB连文件打开失败时的错误都可能伪装成auth失败——得一层层剥开看journalctl -u mongod -n 50倒数几行，才能确认到底是读文件失败、校验失败，还是心跳被拒。
