切换皮肤版本会重新加载页面，而这正是正确的设计
Java版的编辑器基于 64 构建，基岩版的编辑器基于 128 构建。这个常量是写死的，所以两者无法互相传递画布，也会直接拒绝对方的皮肤——这就是为什么每个版本都是一个真实的 URL，而不是一个开关。
这里的皮肤编辑器是两个程序，而不是一个程序加一个设置项。选择 Java 或 Bedrock 会加载不同的构建并重新加载页面，这背后的原因值得了解，因为它解释了一类“为什么我的皮肤导入不了”的问题。
两个构建，两种纹理尺寸
- Java —
TEXTURE_SIZE64。接受 64 × 64，或旧版 64 × 32。其余一律拒绝。 - Bedrock —
TEXTURE_SIZE128。只接受 128 × 128，别的都不行。
这个常量不是运行中的编辑器去查询的变量，而是写死在每个构建里的。因此两者无法互相传递画布——它们之间没有可供传递的共享表示。在运行时替换这个值，只会让程序的另一半以错误的单位工作。
所以切换版本会重新加载。URL 上的 #bedrock 会打开 Bedrock 构建，这让每个版本都成为一个真实地址，可以链接、收藏和分享，而不是一个初次访问者无法触及的隐藏开关状态。
两者都无法显示对方的皮肤
这就是会变成求助提问的那部分。把 Java 皮肤加载进 Bedrock 编辑器，它不会以四分之一大小渲染，而是被拒绝。把 Bedrock 皮肤放进 Java 编辑器同样会被拒绝。
直觉上会觉得 128 × 128 就是“同样的布局，只是更大”——确实如此：每个部位都位于 Java 坐标的两倍处。阻止两个编辑器互换文件的不是布局，而是构建本身，它们的绘制、网格和导出管线各自按自己的 TEXTURE_SIZE 定尺寸。
如果你手上的文件与所在编辑器不匹配，解决办法就是切换版本——或者在图像编辑器里做一次 2× 最近邻缩放，这样能把 Java 皮肤精确映射到 Bedrock 画布上。
这对你的工作流程意味着什么
在开始绘制之前就决定目标平台，而不是之后。一个完成的 Java 皮肤距离 Bedrock 编辑器的画布只差一次 2× 放大，但编辑器不会替你完成这一步。
如果你两者都需要，就画一次然后转换：文件本身可以机械地转换；只是编辑器会拒绝它。