安装包档案线：包体区间、配置字段与版本谱系

这条线只收客户端本身的事实

一条安装包记录围绕一个具体的客户端展开：它的包体有多大、需要哪一档机型、当前处于版本谱系的哪一代。同一款游戏如果同时提供标准包和高清资源包，就会拆成两条记录，各自带着自己的包体与配置档位，互不覆盖。

包体兆字节、客户端形态、配置档位三项字段必须同时具备，条目才计入 7,600 条的正式计数。缺项的记录会留在待补队列里，不对外展示。

不属于这条线的内容，站点另有去处。下面几种问题进的是别的库，不要拿包体数据去回答：

• 开服表线 开服批次与时间安排，共 4,400 条条目，按时间顺序组织，与包体无关。
• 礼包码库 兑换码与兑换状态，2,400 组独立收录，不重复计入 1.2 万条主库。
• 榜单评分线 排名、六个维度的评分与攻略合集共 1,600 条，作为主库的延伸层看待。

包体按兆字节分五档，边界值写明白

档案用兆字节归档包体，不用下载耗时。同一个包在不同机器上的安装时间，会被解压速度、写盘速度和当次网络状况拉开差距；兆字节是包自身的属性，换台设备、换个时间，读出来还是同一个数。

1. 不超过 50MB 以轻量包为主，安装后占用的存储空间小，存储紧张的机型优先看这一档。
2. 51 至 200MB 标准包常见的落点，与入门、主流两档配置的重合度最高。
3. 201 至 600MB 条目最密集的一段，标准包与高清资源包都在这里分布。
4. 601MB 至 1.5GB 高清资源包集中在这一档，配置档位多为高性能及以上。
5. 超过 1.5GB 条目数量最少，图形资源占比高，安装前需要额外预留解压空间。

档位边界按左闭右开写法：不超过 50MB 含正好 50MB，下一档从 51MB 起算。所有包体先按实际字节换算，向上取整到整兆字节，再落进对应档位。

还有一种形态不进这条刻度：云玩直连不产生本地包体，它的包体字段留空，而不是填零。判断它能不能用时，看的是网络条件和图形接口支持，不是存储空间。

四档配置由三个字段合起来判定

配置档位分入门、主流、高性能、旗舰四档。判定时同时看三个字段：处理器核心数区间、内存容量区间、图形接口支持情况。三者都落在同一档的要求范围内，条目才归入该档。档位是归纳出来的收纳标签，不是性能评分，跟榜单名次没有换算关系。

同一个游戏的多个版本怎么编号、怎么合并

一款游戏在档案库里常常不止一条记录。标准包、高清资源包、云玩直连各有各的包体，版本号也未必同步。版本谱系记录的是这些条目之间的先后与归属，免得把同一款游戏算成好几款。

1. 初代记录

   游戏第一次进入档案库时建立，作为谱系链的顶端，包体与配置档位以当时的版本为准。

2. 追加记录

   后续出现新的客户端形态，或包体跨过档位边界时追加，挂在初代记录之后。

3. 现行主档

   当前对外展示的那一条。历史追加记录留在谱系链里，不做删除处理。

合并只在三个条件同时成立时发生：同一游戏、同一客户端形态、包体落在同一档。包体只要跨了一个档位，就会作为新记录保留下来，哪怕它只是多带了一组资源包。

去重与校验是分开的两步。判定重复靠上面三个条件，确认数据无误靠每月一次的字段校验。增量收录每周一次，字段校验每月一次，榜单与评分每季度重算一次，最近一次全库维护标记为 2024 年 6 月。

触发合并时，保留最新一次校验结果，旧版本转入谱系链，不再单独占据计数。校验记录挂在原条目上，不覆盖历史——同一份包体改过几次、哪一次校过，都能顺着条目查回去。

什么时候用包体数据，什么时候该换一条线

包体档案擅长回答跟客户端直接相关的问题。问题一旦转向时间安排、兑换码或游戏评价，就该换到别的库去查，硬用包体字段会得出误导性的结论。

包体数据不用于判断游戏好不好玩，也不承诺某个包能在所有机型上稳定运行。它描述的是包本身，不是运行结果。