“这条数据不是我填的”“我的更新被覆盖了”“两个设备显示不一致”——这些是产品上线后最令人头疼的反馈。

最近我们在一次用户同步问题排查中，发现表面是“数据丢失”问题，实则是多端数据提交时间戳处理不一致，导致后台认为老数据为新，覆盖了正确内容。这类问题通常日志无法直接反映，需要从网络请求行为层级来全面还原。

本文是一次跨平台同步数据错乱排查的抓包实录，目标是展示如何用多工具组合方式，精确还原并定位导致数据错误的根因。

现象：多端编辑同一条数据，最终内容不一致

这是一个允许多端编辑草稿的功能，支持自动保存。用户在Mac编辑后，又在iOS端补充内容，结果上线后发现，iOS端的“旧数据”覆盖了Mac上的新输入。

后台数据库记录显示两次请求都成功落库，时间相近。没有接口报错、没有崩溃、没有异常日志。系统按流程完成了一切，但结果是错的。

拆解抓包需求：哪些信息需要被还原？

我们决定还原客户端提交数据时真实传输内容，重点关注以下几点：

1. 请求是否携带本地生成的时间戳或版本号？
2. 不同端是否使用相同时间基准？
3. 服务端是否信任客户端时间排序？
4. 是否存在重复请求/数据重放等行为？

工具分工与分析流程

抓包发现的第一个关键信息：客户端本地生成时间戳

在Charles中查看Mac客户端请求时发现，提交内容中有一个字段client_ts（客户端时间戳），用于版本判断。服务端以此值判断“哪个数据是最新的”。

随后用Sniffmaster抓取iOS端的请求，发现其client_ts值明显小于Mac请求中值，尽管是后发请求。

进一步调查发现，iOS设备的系统时间设定与服务器相差约40秒，导致其生成的时间戳落后。

由于服务端逻辑采用“较大时间戳为准”机制，这直接导致服务端认为“iOS的数据更新较新”，从而用旧数据覆盖了正确草稿。

请求行为链进一步分析：是否存在补发或重复提交

我们启用mitmproxy脚本，对请求拦截并输出数据体与Header内容：

def request(flow):
    if "/draft/submit" in flow.request.path:
        print(flow.request.content.decode())

同样，Sniffmaster本身也自带JavaScript拦截器功能，可以做到抓包的同时直接拦截请求和响应。

分析5次请求发现：

• iOS端存在一次“App重启后自动重发”的行为，补发的请求再次使用了缓存旧数据和旧时间戳；
• 请求中并无版本ID或唯一ID，无法做去重判断；
• 服务端也未对内容变化做判定，仅以时间戳排序处理。

网络层次验证：是否存在丢包或重传导致数据重发

通过Wireshark观察发现：

• 某一次iOS请求因网络抖动导致连接关闭；
• SDK自动重试机制补发上一次请求，未生成新时间戳，仅重发原数据包；
• 这次重试在服务端无日志记录为“重发”，仅认定为一次独立提交。

问题复现与多端验证策略

为了确保问题可控可复现，我们制定以下验证流程：

1. 设置iOS设备系统时间落后1分钟；
2. 在Mac上提交内容，确保服务器记录版本时间；
3. 在iOS端重启App并打开编辑页面；
4. 不修改数据，观察其是否自动提交；
5. 使用Sniffmaster和mitmproxy再次抓包确认数据结构一致性；

该流程成功复现了“旧内容覆盖新内容”的行为链。

修复策略与流程优化

本问题不在于请求报错或接口失败，而是数据同步机制未能区分“补发的旧数据”与“用户主动提交的新数据”。

综合抓包信息后，我们调整：

• 客户端提交请求增加唯一版本ID（UUID），服务端以其为准判断幂等；
• 所有平台统一调用系统时间基准（UTC）而非本地系统时间；
• SDK补发请求添加“来源标识”，避免误判为新提交；
• 针对“草稿覆盖”场景设计双向合并提示机制；

总结：可用不等于正确，抓包的价值在于还原行为路径

抓包并不总是为了处理接口错误，更多时候，它帮助我们理解系统在真实运行时的每一个步骤，尤其是那些“行为正确但结果错误”的场景。

在这次分析中，Sniffmaster在还原iOS端真实请求、解密HTTPS内容、识别字段差异方面起到了作用，但整个问题的分析离不开Charles、mitmproxy与Wireshark的协同。

最终我们不是发现了Bug，而是找到了“被误判为正确”的一系列行为。这也是抓包的意义：不仅仅看得见，还得看得全、看得准。