简短结论：绝大多数能对上，少数会被替换

转换后觉得方块或坐标「对不上」，通常不是出了 bug，而是 Java 版和基岩版本来就在少数方块、坐标系细节上有差异。TopoBlocks 的转换是单向的 Java → 基岩版，过程中会做方块映射：绝大多数方块都能一一对应，只有个别 Java 专属方块在基岩版没有完全相同的对应物，会被替换为最接近的兼容等价物。我们从不承诺「100% 无损」，但也不会偷偷替换——每一处改动都写进完成后的逐项变更报告。想先弄清两版本的底层差异，可看 Java 版和基岩版有什么区别。

哪些「对不上」是正常的

  • 个别 Java 专属方块被替换。 基岩版没有完全等价的方块时，转换会选一个最接近的兼容等价物，而不是丢弃。报告里会逐条列出原方块和替换结果。
  • 方块朝向、含水态等细节差异。 两版本对部分方块的状态表示不同，迁移后偶有细微出入，属于版本差异而非坐标错乱。
  • 区块边界处的观感差异。 世界数据按区块存储，两版本在区块边界的处理不完全一致，远看可能觉得某处「不太一样」。

需要强调的是：地形与结构布局通常按原坐标迁移，不会整体平移或错位。 想知道更完整的「哪些能转、哪些不能」，可参考 Java 转基岩，哪些能迁移、哪些不能。

转换前后该怎么核对

为了让你「先看清再决定」，转换流程刻意分成两步：

  1. 付费前看兼容度评分——预估这张图里有多少内容能完整迁移、多少可能被替换，让你判断值不值得转。
  2. 完成后看逐项报告——把每一处被替换为兼容等价物的方块、以及移入报告说明的内容都列清楚，导入基岩版后照着核对即可，心里有数。

转换按次付费、失败自动退款，价格以 App 内为准；而且绝不覆盖你的源文件——每次都生成新的 .mcworld，原 Java 世界连同哈希都保留、可追溯，不满意还能重来。关于不同版本(如 1.20/1.21)输出的兼容性，可看 转换后的世界版本兼容吗（1.20/1.21）。想了解完整的转换步骤，也可参考深度教程 Java 转基岩。