开发备用Winery Schema解码器时：类型索引存储位置在哪？如何解读序列化编码数值？

你之前对照内置索引出现偏差，核心原因是 没有把开头的版本号位从类型编码流里拆分出来，整套解码规则可以按分层逻辑梳理：

第一步：固定字段拆分 #

所有序列化结果的第一个数组元素，就是你已知的Schema版本号（你拿到的样本里都是4，对应Winery v4序列化格式），这部分不属于类型本体的编码内容，需要从后续解析流程中剔除。
把你拿到的所有样本拆分后，真正的类型编码流是：

• Void 类型：[5, 0]
• Bool 类型：[6]
• Int / Integer 类型：[16]
• () 单元类型：[3, 0]

第二步：核心编码值的语义规则 #

这些短编码都是Winery为基础内置类型设计的快速通道编码，不需要走通用的递归Schema序列化流程，每个数值的固定含义如下：

• 编码值3：代表当前类型是带编号的空构造子组合类型，后面紧跟的数字是该类型下的构造子元数据长度。比如[3, 0]就对应()单元类型：单空构造子、长度位为0表示没有额外的构造子字段元数据
• 编码值5：代表无构造子的空类型（即Void），后面跟的0是构造子数组的长度——Void没有任何可实例化的构造子，因此长度为0，和观察到的编码完全匹配
• 编码值6：代表固定双构造子的布尔类型（即Bool），因为Bool的两个构造子（True/False）都是空构造子、数量固定为2，没有额外元数据，因此不需要后续长度位，直接用单值编码即可
• 编码值16：代表任意精度整数原生类型（即Integer），Winery在序列化Int类型时不会附加额外的范围元数据，直接复用Integer的类型定义，因此二者的序列化结果完全一致

索引错位的原因 #

你参考的bootstrapSchema内部的类型列表，是解码器自举流程用的内置类型查表结构——里面的类型顺序是内存中的枚举序号，不是实际序列化时写入的编码值。自举表的作用是当解码器遇到和内置类型完全一致的Schema编码时，直接匹配出对应的目标类型，不需要重新遍历完整的Schema结构，它和实际线上写入的编码数值是两层映射关系，直接用列表顺序和编码值对比自然会出现错位。

内容的提问来源于stack exchange，提问作者Janus Troelsen