基岩版没有独立的披风包——披风只能依附于皮肤一起发布
不存在仅含披风的 .mcpack 格式。每个披风都必须搭配一个引用它的皮肤条目，因此披风包本质上就是每个条目多带一张 PNG 的皮肤包，披风文件尺寸是 64×32，实际可见的那一面只是位于 (1, 1) 的 10×16 区块。
在 Java 版中，披风与皮肤是相互独立的。但在 Bedrock 版中并非如此：不存在披风包格式。披风是皮肤条目上的一个字段，因此分发披风就意味着分发一个穿着它的皮肤。
这带来了哪些限制
披风包本质上是一个每个条目都指定了披风纹理的皮肤包。其清单文件、skins.json 和语言文件与任何其他皮肤包完全相同——唯一的区别是每个条目多一个键，压缩包中多一张 PNG。
这些限制是结构性的，而非表面上的：
- 你无法单独发布一个披风。 每个披风都需要一个皮肤作为载体，即使那个皮肤你根本不在意。
- 披风在游戏中不能独立选择。 选择披风就意味着选择它所属的那个皮肤条目。一个皮肤搭配两个披风是无法表达的。
- N 个皮肤 × M 个披风 = N × M 个条目，而不是 N + M。为四个皮肤提供三种披风，意味着包中有十二个条目，每个都有自己的键、自己的语言文件名称，以及自己的一对 PNG。
最后一点在包规模扩大时最为致命。披风包会迅速膨胀，而且体积是乘法增长而非加法增长。
两种纹理尺寸不同
皮肤是 64 × 64（或旧版 64 × 32）。披风则始终是 64 × 32。两者不可互换。构建器会拒绝将 64 × 64 的皮肤放入披风槽位，但反过来却会蒙混过关：将 64 × 32 的披风放入皮肤槽位会被当作旧版皮肤读取，所以请自己分清两者。
在那个 64 × 32 的披风文件中，可见面是 (1, 1) 处的 10 × 16 区域——其余部分是背面、边缘和填充。此处的预览在展示哪个披风是哪个时，会精确裁剪到那个矩形，因为在缩略图尺寸下，周围的填充占据了图像的大部分，什么信息也传达不了。
纤细和经典模型依然适用
每个条目都带有自己的模型，判断方式与普通皮肤包相同——根据纤细手臂留空的两列（x 54–55，y 20–31）来推测——并且每个条目都有一个经典/纤细切换开关，用于修正判断错误的皮肤，比如那些几乎没有绘制这两列的经典皮肤。因此披风包还必须为每个条目正确判断纤细/经典模型——披风不会改变手臂的读取方式，而模型判断错误在这里的表现与其他地方完全一样：一个 Alex 皮肤配着 Steve 的手臂，穿着正确的披风。
实际形态
如果你的目标真的只是“把这个披风给到大家”，那么包只是分发手段，而非产品本身。搭配一个最简洁合理的皮肤，用披风而非皮肤来命名条目，并接受玩家选择它时就是在同时选择两者。
如果你的目标是一套搭配好的外观——皮肤和披风一起设计——那么 Bedrock 版的模型其实才是正确的，那种感觉像限制的配对关系恰恰就是它的特性。