权限节点

基本信息

三层权限模型

ServerUtilitiesPermissionHandler.hasPermission()（ServerUtilitiesPermissionHandler.java:41-66）的判定顺序：

1. 客户端短路：若上下文有 world 且 isRemote，或 FMLCommonHandler.getEffectiveSide() == CLIENT → 只按 DefaultPermissionLevel.ALL 判定
2. 补全 profile：getId() == null 时用 EntityPlayer.func_146094_a(name) 反查 UUID；名字也 null 则拒绝
3. 查 rank 图，ALLOW → true，DENY → false
4. 其余 → 委托 DefaultPermissionHandler

客户端短路是刻意的：防止客户端通过预测调用探测服务端权限配置。

固定节点分组（69 个）

按 ServerUtilitiesPermissions.java:43-132 的注释分节整理。

Display（1）

Homes / Warps（10）

Back（9）

Claims（13）

CLAIMS_BYPASS_LIMITS 是全部 69 个常量中唯一默认等级为 NONE 的固定节点（ServerUtilitiesPermissions.java:183）—— 默认谁都没有，必须显式授予。

Chunkloader（3）

Chat（11）

Other / 管理面板 / 传送（17）

bypass_player_limit 由 MixinNetHandlerLoginServer 提供（Mixins.BYPASS_PLAYER_LIMIT），bypass_whitelist 是配对节点。

Rank 可配置值（25 个）

ServerUtilitiesPermissions.registerConfigs()（:311-365）把 25 个节点注册为带类型的可继承值（ConfigInt / ConfigBoolean / ConfigString / ConfigTimer / ConfigEnum），而非开关。第一参数是「客户端/下限」定义，第二参数是「服务端默认」值。

[!NOTE] 冷却/预热的服务端默认全是 NO_TICKS（无冷却），客户端定义里的 5 分钟/3 分钟等只是类型示例。这与 commands-config 中「客户端与服务端配置分离」的设计一致 —— 服务端才是权威。

ConfigTimer 的双参数形式是 (当前值, 上限)，ConfigInt 的三参数形式是 (默认值, 下限, 上限)。

5 个聊天样式节点的例外

CHAT_TEXT_BOLD / ITALIC / UNDERLINED / STRIKETHROUGH / OBFUSCATED 这 5 个常量既没有 registerNode，也没有 registerRankConfig，但被真实读取：

// handlers/ServerUtilitiesServerEventHandler.java:157
if (Ranks.INSTANCE.getPermissionResult(player, ServerUtilitiesPermissions.CHAT_TEXT_BOLD, false)
        == Event.Result.ALLOW) {
    text.getChatStyle().setBold(true);
}

5 处分别在 :157、:162、:167、:172、:177（依次对应 bold / italic / underlined / strikethrough / obfuscated）。相邻的 CHAT_TEXT_COLOR 则确实注册为 rank 配置（:324），走 RankConfigAPI.get(player, ...) 取值。

getPermissionResult（ranks/Ranks.java:513-516）对查不到的节点返回 value.isNull() ? DEFAULT : ...，而 getPermission 最终落到 ServerUtilitiesPermissionHandler.getConfigValue()（:82-90），未命中 rank 时委托 DefaultRankConfigHandler。因此这 5 个节点的实际效果取决于 rank 图中是否存在同名条目 —— 本仓既不预注册默认等级，也不提供自动 GUI 条目。

这是「声明 ≠ 注册」的一个边界案例：代码在用它们，所以不能算死代码；但权限系统从未正式登记它们，/dump_permissions 与 Aurora 权限页也不会列出。已按事实记录，未做推断补全。

前缀机制

registerPrefixes()（:367-389）注册 5 个前缀，末尾 new CustomPermissionPrefixesRegistryEvent(CUSTOM_PERM_PREFIX::add).post() 允许外部模组追加：

动态生成的节点

registerPermissions()（:271-308）遍历游戏注册表生成海量节点，节点总数等于已注册方块 × 2 + 已注册物品 × 1 + 排行榜数：

<id> 由 formatId()（:395-403）生成：取注册名转小写并把 : 换成 .；取不到名字时回退为字面量 minecraft.air。

白名单/黑名单决定默认等级（这是本模组唯一的按方块差异化默认权限）：

白名单内的默认 ALL、外的默认 OP（方块）；黑名单内的默认 OP、外的默认 ALL（物品，即默认不屏蔽水桶）。

排行榜节点由 ServerUtilitiesLeaderboards.registerLeaderboard()（:213-219）在每次注册排行榜时动态创建，默认 ALL。节点名由 getLeaderboardNode()（:427-431）拼装：本模组内置排行榜不带域名前缀（serverutilities.leaderboard.<id>），外部模组注册的则带（serverutilities.leaderboard.<modid>.<id>）。

节点过滤

Ranks.getPermissionNodes()（Ranks.java:522-545）在枚举节点时会过滤掉前缀派生的平凡节点：若节点以某前缀开头、且其默认等级恰好等于该前缀的默认等级、且描述为空串，则不加入可授予列表。这样 serverutilities.claims.block.edit.minecraft.stone 这类成千上万的节点不会淹没管理员的 rank 编辑界面。

[!IMPORTANT] 本模组的权限体系完全不依赖原版 Forge 权限系统，而是自己实现 IPermissionHandler。原版 canCommandSenderUseCommand 只在 ranks.command_permissions = false 或 rank 未给出明确 ALLOW/DENY 时作为兜底。因此本仓中没有 ForgePermissions / PermissionAPIPermission 之类的注册代码（grep -rn "ForgePermissions" src/ 无匹配）。

相关条目

• Rank 指令 - 修改 rank 与其权限值的 8 条子命令
• 服务端配置 - ranks.enabled / command_permissions / override_chat 三个总开关
• 服务端指令总表 - CmdBase.Level 与节点的对应
• Aurora 配置 - 权限列表页展示的就是本页的节点