订单同步只记到秒，同一秒的新记录可能被跳过

Shopify新版本调整了不含小数秒的时间筛选边界。用上一条订单时间继续同步的应用，应检查大于与大于等于的差别，并按订单ID处理重读，避免同一秒的不同订单被遗漏或重复触发后续工作。

独立站后台有订单，内部跟进表却少了一条，接口也没有报错。对用时间筛选增量拉取Shopify订单的应用，原因可能藏在“大于上次时间”这句话里：接口显示到秒，不代表这一秒里只有一条记录。把整秒当成已经读完的边界，可能跳过同秒内尚未处理的订单。

Shopify在10月19日说明，自GraphQL Admin API的2026-10版本起，不带小数秒的时间戳筛选使用排他下界“>”时，会排除完整的一秒。官方因此建议，若不能遗漏同一秒稍后创建的记录，应使用“>=”带上该时间，再按id去除重复。影响范围是这类具体查询，不是所有订单读取方式。

同一个显示时间，可以属于不同订单

平台返回的createdAt按秒展示，但内部某些资源保存小数秒。于是两个不同订单的返回时间可能看起来完全相同。如果同步程序把第一条看到的时间记为进度，下次只请求严格晚于这个整秒的记录，就可能把另一条仍在这个秒内的记录挡在外面。

新版本使这种筛选边界与返回时间的理解更一致，但依赖旧行为的应用需要检查自己的继续读取方式。尤其要找把上一轮返回时间直接拼进“>”条件的代码，而不是看到版本号就全站重做。Shopify说明，2026-07及更早版本不需要因此修改；其他比较符以及日期值、带小数秒的边界也不属于这次相同的变化。

把条件改成包含边界，会有意重读已经见过的记录。此时去重必须看订单身份，不能只看时间：两个同秒订单是两笔业务，不是重复数据。邮箱、金额或收件地址相同也不能替代订单ID，否则同一买家的多次购买可能被错误合并。

包含式读取解决了边界覆盖，却会把重复处理的问题交给应用。再次读到一个已有订单，不应再次新建销售任务、重复发送确认或重复制单。可以更新该订单对应的本地记录，但后续动作是否已执行，应根据原有业务状态判断，而不是每次收到记录就从头开始。

分页也要一起检查。若一轮查询还没读完，就把进度推进到当前电脑时间，下轮可能越过未处理部分。这里的进度应表示已经可靠处理到哪里，而不是程序最近启动于何时。保存位置与后续动作的先后关系要能解释中途失败后的恢复方式，否则不漏读取也仍可能漏工作。

对中国外贸品牌与海外运营团队，测试可以使用明确构造的同秒不同ID记录，再加一条重复ID记录：前两条都应进入本地，后一条不应重复触发动作。还应检查分页中断后继续运行的结果。这样的测试能直接覆盖本次变更，而只看接口返回成功或订单总数接近，很容易漏掉边界问题。

若同步还经历过停机，恢复后的旧订单是否仍应触发即时动作，是另一个时间问题，可结合同步恢复后积压动作的处理检查。先确认正在使用的API版本和筛选表达式，再决定是否需要这次修改；没有采用该读取方式的团队，不必为了公告增加一套新系统。