本文详解 Spigot 插件中 PlayerJoinEvent 的条件执行陷阱：因错误使用 else if 导致封禁检查逻辑被跳过，导致无法连接 MongoDB 并发送自定义踢出消息；提供修复方案、代码优化与最佳实践。
本文详解 spigot 插件中 `playerjoinevent` 的条件执行陷阱：因错误使用 `else if` 导致封禁检查逻辑被跳过，导致无法连接 mongodb 并发送自定义踢出消息；提供修复方案、代码优化与最佳实践。
在 Spigot 1.19（及后续版本）中处理 PlayerJoinEvent 时，一个常见但隐蔽的逻辑错误是误用 if-else if-else 链，导致关键分支（如封禁校验）永远无法执行。你的原始代码中存在典型的条件互斥覆盖问题：
if (!player.hasPlayedBefore()) { ... }
else if (player.hasPlayedBefore()) { ... }
else if (player.isBanned()) { ... } // ❌ 永远不会进入！
由于 player.hasPlayedBefore() 是布尔值，其非真即假，前两个分支已完全覆盖所有可能——player.isBanned() 的判断被彻底屏蔽。即使该玩家已被 BanList 封禁，此逻辑也不会触发。
✅ 正确做法是将封禁检查独立为并行判断（使用单独的 if），因为它与“是否首次加入”无逻辑互斥关系：
@EventHandler
public void onPlayerJoin(PlayerJoinEvent event) {
Player player = event.getPlayer();
// ✅ 独立判断：无论是否首次登录，都需检查是否被封禁
if (player.isBanned()) {
// 注意：此处应使用 player.getName() 而非 event.getPlayer()（后者是 Player 对象，不能直接作为字符串查询）
String playerName = player.getName();
// ⚠️ 重要：MongoDB 连接不应在事件中实时创建（性能/资源泄漏风险）
// 推荐在插件启用时初始化并复用 MongoClient（见下方优化建议）
try (MongoClient mongoClient = new MongoClient("mongodb://admin:password@185.209.223.136:2002")) {
MongoDatabase database = mongoClient.getDatabase("test");
MongoCollection<document> collection = database.getCollection("bans");
// ✅ 修正查询：使用 playerName 字符串，而非 Player 对象
Document query = new Document("name", playerName);
Document projection = new Document("staff", 1).append("reason", 1);
try (MongoCursor<document> cursor = collection.find(query).projection(projection).iterator()) {
if (cursor.hasNext()) {
Document doc = cursor.next();
String staff = doc.getString("staff", "Unknown");
String reason = doc.getString("reason", "No reason provided");
// ✅ 取消默认加入消息（可选），并立即踢出
event.setJoinMessage(null); // 防止默认欢迎消息干扰
player.kickPlayer(
ChatColor.RED + "You have been banned from this server!\n" +
ChatColor.YELLOW + "Reason: " + reason + "\n" +
ChatColor.GOLD + "Issued by: " + staff
);
return; // ? 关键：提前返回，避免后续逻辑执行
}
}
} catch (Exception e) {
plugin.getLogger().severe("Failed to check ban status for " + playerName + ": " + e.getMessage());
player.kickPlayer(ChatColor.RED + "Server error occurred. Please try again later.");
}
return;
}
// ✅ 此处才处理正常欢迎逻辑（仅当未被封禁时）
if (!player.hasPlayedBefore()) {
event.setJoinMessage(ChatColor.GREEN + "Welcome to the server " + player.getName() + "! We hope you enjoy your stay.");
} else {
event.setJoinMessage(ChatColor.GREEN + "Welcome back to the server " + player.getName() + "!");
}
}</document></document>
? 关键修复与优化要点：
- 逻辑解耦：封禁检查必须脱离 else if 链，改为前置独立 if，确保优先执行且不受其他条件影响；
- 查询参数修正：new Document("name", event.getPlayer()) → new Document("name", player.getName())，否则 MongoDB 查询将失败（Player 对象无法序列化为有效字符串匹配）；
- 资源安全：使用 try-with-resources 管理 MongoClient 和 MongoCursor，避免连接泄漏（生产环境强烈建议使用连接池或单例客户端）；
- 尽早终止：调用 player.kickPlayer() 后务必 return，防止后续 setJoinMessage() 覆盖或引发异常；
- 健壮性增强：添加 try-catch 捕获数据库异常，并提供降级踢出消息，避免因 DB 故障导致玩家卡在登录流程；
- 性能提示：player.isBanned() 仅检查 Bukkit 内置封禁列表（banned-players.json），若你使用的是自定义 MongoDB 封禁系统，请勿依赖此方法——应直接查询数据库，并移除该条件，改用 collection.countDocuments(query) > 0 判断。
? 进阶建议：
将 MongoDB 客户端初始化移至 onEnable() 中，作为插件成员变量复用；同时考虑引入异步查询（Bukkit.getScheduler().runTaskAsynchronously）避免阻塞主服务器线程——尤其在高并发场景下，同步数据库操作可能导致 TPS 下降。
遵循以上结构与规范，即可稳定、高效地实现基于外部数据库的实时封禁拦截与定制化踢出响应。
