Fast NBT

Fast NBT 可以降低 Minecraft 日常 NBT 操作的开销：读取标签、将其转换为游戏对象，以及从区块、数据包、方块状态和 ItemStack 中加载数据。

CompoundTag

• 各种 get 方法。原版游戏会先调用 contains 检查键是否存在，再调用 get——这需要查找映射表两次。Fast NBT 将这两个操作合并为一次，并应用内联优化，大幅提升查找速度。
• 迭代。不再使用 keySet 配合 get 进行迭代，而是同时遍历键和值，因此写入和合并复合标签时，不必再为每个条目单独查找。
• 相关类。其他相关类中使用这些 get 方法的操作也得到了优化。

ItemStack、方块状态与 NBT I/O

• 加载 ItemStack。从 NBT 读取 ItemStack 时，会直接从底层映射表读取 tag 和 ForgeCaps，不再通过两次 contains 调用进行探测；getOrCreateTagElement、getTagElement 和 removeTagKey 也只需查找一次。
• 方块状态。NbtUtils.readBlockState 和 getDataVersion 会直接读取 Name 和 Properties，不再经过原版的 contains / getString 调用链。
• 区块分区调色板。通常，每个调色板条目在每次加载或保存区块时，都要经过完整的 DFU 编解码链：分派编解码器、注册表查找、每个属性一个 MapCodec，以及 DataResult / Either / Pair / Optional 的分配。Fast NBT 会直接从映射表中解析规范的 {Name, Properties} 标签。这是该模组带来最大性能提升的部分。
• NBT I/O。无限制读取器——包括每次区块加载，以及读取 level.dat 和玩家数据时——会跳过一次字节计数流程，因为其结果最终会被丢弃。

因此，性能提升主要体现在批量解码 NBT 的场景：世界和区块加载、服务器自动保存（需要重新编码每个区块），以及携带带标签 ItemStack 的物品栏、方块实体和实体数据。调色板处理路径中临时对象减少，也意味着垃圾回收压力更小。

这不是通用性能模组：它不会触及 NBT 以外的内容，也无法改善受磁盘或网络速度限制的工作负载。收益取决于整合包需要解码的 NBT 数量；在纯原版世界中，收益最小。

配置

首次启动时会生成 config/fastnbt.toml，并为每项优化提供独立开关：

enabled = true              # master switch for everything below

[features.itemStack]
    enabled = true

[features.blockState]
    enabled = true

[features.blockStateCodec]
    enabled = true

[features.nbtIo]
    enabled = true

CompoundTag 的重写没有单独的开关；全局 enabled 标志负责控制它们。

如何确保安全

• 只有规范数据会走快速路径。任何非规范数据都会作为解码错误报告，而不会被擅自猜测；与原版完全一致，Properties 中方块不具备的键会被忽略。对于区块调色板，调用方会将解码失败的条目设为空气，因此即使世界引用了未安装模组中的方块，仍然可以加载——每个条目只会记录一行日志。
• 编码绝不会被替换。调色板优化只会加快解码速度，因此保存的区块和网络数据包仍与原内容逐字节一致。
• 注入冲突。这些优化会替换或重定向原版方法，且没有提供非破坏性变体；因此，如果其他模组也针对同一方法，最后应用的修改会生效。发布前请在大型整合包中进行测试。

采用 GNU LGPL v3.0 或更高版本授权。