与 v4（具体而言是 v4 Update API）相比，Google 安全浏览 v5 的一个重大改进是数据的新鲜度和覆盖率。由于保护功能在很大程度上依赖于客户端维护的本地数据库，因此本地数据库更新的延迟时间和大小是导致未能获得保护的主要原因。在 v4 中，典型客户端需要 20 到 50 分钟才能获取最新版本的威胁列表。遗憾的是，钓鱼式攻击的传播速度非常快：截至 2021 年，60% 的攻击性网站的生命周期不到 10 分钟。我们的分析表明，大约 25-30% 的钓鱼式攻击防护功能缺失是由于此类数据过时所致。此外，部分设备无法管理 Google 安全浏览威胁列表的全部内容，而该列表会随着时间的推移而不断扩大。
如果您目前使用的是 v4 Update API，则可以从 v4 无缝迁移到 v5，而无需重置或清除本地数据库。本部分介绍了如何执行此操作。
转换列表更新
与 v4 不同，v5 中的列表仅通过名称进行标识，而 v4 中的列表则通过威胁类型、平台类型和威胁条目类型的元组进行标识。这样，当多个 v5 列表可能共享相同的威胁类型时，便可灵活处理。平台类型和威胁条目类型已在 v5 中移除。
在 v4 中，您可以使用 threatListUpdates.fetch 方法下载列表。在 v5 中，应改用 hashLists.batchGet 方法。
您应对请求进行以下更改：
- 完全移除 v4
ClientInfo对象。请勿使用专用字段提供客户端的标识，而应使用众所周知的 User-Agent 标头。虽然此标头中没有规定提供客户端标识的格式，但我们建议您只需添加原始客户端 ID 和客户端版本，并以空格或斜线字符分隔即可。 - 对于每个 v4
ListUpdateRequest对象：* 在上表中查找相应的 v5 列表名称，并在 v5 请求中提供该名称。- 移除不需要的字段，例如
threat_entry_type或platform_type。 - v4 中的
state字段与 v5 中的versions字段直接兼容。在 v4 中使用state字段发送到服务器的字节字符串，在 v5 中只需使用versions字段即可发送。 - 对于 v4 约束条件，v5 使用一个名为
SizeConstraints的简化版本。应舍弃region等其他字段。
- 移除不需要的字段，例如
您应对响应进行以下更改：
- v4 枚举
ResponseType只需替换为名为partial_update的布尔字段即可。 minimum_wait_duration字段现在可以为零或省略。如果是，系统会要求客户端立即发出另一个请求。只有当客户端在SizeConstraints中为最大更新大小指定的约束条件小于最大数据库大小时，才会发生这种情况。- 需要调整适用于 32 位整数的 Rice 解码算法。区别在于，编码后的数据采用不同的字节序。在 v4 和 v5 中，32 位哈希前缀按字典顺序排序。但是，在 v4 中，排序时这些前缀会被视为小端序，而在 v5 中，排序时这些前缀会被视为大端序。这意味着，客户端无需执行任何排序，因为字典排序与使用大端序的数字排序相同。如需查看 v4 的 Chromium 实现中此类示例，请点击此处。可以移除此类排序。
- 还需要针对其他哈希长度实现 Rice 解码算法。
转换哈希搜索
在 v4 中，您可以使用 fullHashes.find 方法获取完整哈希。v5 中的等效方法是 hashes.search 方法。
您应对请求进行以下更改：
- 将代码结构调整为仅发送长度为 4 个字节的哈希前缀。
- 完全移除 v4
ClientInfo对象。请勿使用专用字段提供客户端的标识，而应使用众所周知的 User-Agent 标头。虽然此标头中没有规定提供客户端标识的格式，但我们建议您只需添加原始客户端 ID 和客户端版本，并以空格或斜线字符分隔即可。 - 移除
client_states字段。不再需要此函数。 - 不再需要添加
threat_types和类似字段。
您应对响应进行以下更改：
minimum_wait_duration字段已移除。客户端可以随时根据需要发出新请求。- v4
ThreatMatch对象已简化为FullHash对象。 - 缓存已简化为单个缓存时长。请参阅上文，了解如何与缓存交互。