处理 WA Lookup 返回的 avatar_url 值

avatar_url 字段是 ws_avatar 响应中最常让集成开发感到意外的部分，因为它不仅是可选的，而且 URL 与布尔值在存储方式上也截然不同。

WA Lookup 仅在上游服务为该账户提供头像时才会返回 avatar_url。因此，读取 ws_avatar 响应的集成需要一种数据模型，其中 URL 是可选的，并与随附的头像布尔值分开。

分别建模布尔值和 URL

头像布尔值和 avatar_url 字符串回答的是不同的问题：是否检测到了头像，以及从哪里可以获取它。如果将它们合并为一个可为空的列，那么当 URL 缺失时，第一个问题的答案就会丢失，而缺失在实际情况中是常态而非边缘情况。使用两个列可以确保两个答案都清晰可读。

决定是否存储 URL

有些集成只需要布尔值，在这种情况下，直接舍弃 URL 可以完全避免关于保留策略的一系列问题。如果您确实需要保留它，请务必在旁边记录检查日期，因为个人资料信息会发生变化，存储的 URL 只是检查时状态的快照，而非永久地址。

将获取操作视为独立事项

获取 URL 指向的内容与执行检查是不同的操作，它们有各自的故障模式和时间要求。将两者分开处理，可以确保在日志中不会将获取问题误判为检查问题，这在您排查批处理异常时非常重要。

在集成边界处理缺失值，避免到处编写分支逻辑

在集成的边界处对响应进行一次标准化处理——将可选字段转换为您的代码能够明确理解的表示形式——而不是在每个调用点都进行存在性检查。缺失值非常常见，分散的检查往往会成为导致可避免错误的主要来源。

常见问题解答

avatar_url 应该永久存储吗？

如果您选择存储它，请务必将其与检查日期一起存储，因为个人资料信息会发生变化，该值只是一个快照，而非永久地址。

avatar_url 缺失说明了什么？

说明上游服务在检查时未提供该账户的头像 URL。头像布尔值仍然会报告是否检测到了头像。

获取操作是检查过程的一部分吗？

不是。检查操作仅返回字段；获取 URL 指向的内容是一个独立的操作，具有其自身的故障模式。