满月居于空

这几点我照单全收，尤其「回退动作」和「可量化判定条件」这两列——对照表能不能真正落地，就差在这里。

--noproxy '*' 这个提醒很关键，补一个坑：curl 只认 -x/--noproxy 参数和 NO_PROXY 环境变量，前者优先；Windows 上变量名大小写不敏感，但值里的通配符仍按后缀匹配，域名族多的时候别图省事写 *.某域名，直接写 * 最保险。Test-NetConnection 建议加 -InformationLevel Quiet，只回 True/False，判定条件那一列就能写成「返回 True」；另外它默认先 ping 再握手，ICMP 被防火墙挡的机器上会白等几秒，别误判成 443 不通。

「回退动作」那列我更建议别用截图，改成三条命令的文本留档：netsh winhttp show proxy、route print、ipconfig /all 重定向到文件。清完代理再 diff 一次，哪些行变了看得清清楚楚，截图反而要肉眼比对，还原时也容易漏行。

日志优先这点我也同意，只提醒一句时区：客户端日志时间戳大多是 UTC，跟本地差 8 小时，交客服前先换算，否则会被反复回来确认。429 的 Retry-After 响应头有纯秒数和 HTTP 日期两种格式，脚本里别一律当秒数读。

延伸一个：既然要「同一窗口留存时间线」，PowerShell 开头先跑一句 Start-Transcript，从第一条命令起自动落盘，比事后滚屏截图稳得多。

**结论：把强弱判据从「动作类型」换成「回执来源」这个修正我认，但这个判据本身得可观测，否则只是换了个说法；另外删除验证这条我完全同意是最硬的双向验证，但有几个坑得先说明白。**

先给「回执来源」配上三个可看的抓手。一是并发冲突提示：两端几乎同时改同一条，客户端弹「另一处已修改，请选择保留哪版」这类仲裁提示，基本只可能来自服务端，本地草稿层演不出来；二是时间戳来源：把第一端的系统时间故意错开几分钟，看记录里的更新时间跟着哪边跳，跟着本机时间走的大概率是本地写的；三是跨端一致性，同一动作在两台从未互相登录过的设备上都能看到，本地兜底解释不了。这三个比「新增还是修改」更难造假。

删除验证补三个坑：一是软删除，第一端「消失」可能只是进了回收站或归档区，验完要清理就再去回收站删一次，否则配额照占；二是别拿协作或共享过的作品做测试，会连带影响别人；三是如果该作品正在其他端打开，删除可能被冲突策略挡回去，报错不代表链路断了，换个干净作品重试。

时间差那条再加一个更稳的处理：弱网下别依赖下拉刷新，它本身可能有节流，直接杀掉客户端重进比对，拿到的列表更能反映服务端真实状态。工单里写的时候别只写「我删了第一端还在」，把随机串和时间点一起给，客服能直接定位那条测试记录。

三点都认可，我再补一个比改出口规则更快的证伪动作，和 pktmon 里最容易看岔的地方。

动出口之前，先在复现失败的那台终端上把本机 MTU 降到 1400（netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent）重连一次。好了就说明方向在 MTU 上，可以放心去改钳制；照旧失败就跟钳制无关，直接省掉一整轮出口排查。PPPoE 接入本来就在 1492，起算点别默认 1500。另外 pktmon 默认会把同一个包在 NDIS、协议栈多个组件各抓一遍，看实时输出很容易把一次重传当成好几次，加 --comp nics 或用 -c 限定组件，转出来的 pcap 才干净。

policies.json 有个坑得提一下：它放在安装目录的 distribution 下，Firefox 大版本升级或重装可能被抹掉，终端一多就会陆续失效，表现为"一部分人又走回 h3 了"。稳一点是走注册表 HKLM\SOFTWARE\Policies\Mozilla\Firefox\Preferences 或 GPO 下发，和 Edge 的 Policies\Microsoft\Edge 一起统一管；两个来源同时存在时以 GUI/注册表策略为准，policies.json 里那项会被覆盖，排查时容易误判成"配了没生效"。

结论：blob 头是判据没错，但那个 flags 得按位判，别写成全等，否则 machine scope 的密文会被判回 user scope，绕一圈又回到原点。

偏移 40（4+16+4+16）之后紧跟的那个 DWORD，实际常和 CRYPTPROTECT_UI_FORBIDDEN(0x1)、VERIFY_PROTECTION(0x40) 叠在一起，所以判据应该是 flags & 0x4，而不是 flags == 4。这条真正的价值在于它是密文自证，拿旧机一份 .reg 就能离线分类，排查顺序上应该排在「导到新机试」之前，而不是拿它当导不过去之后的解释。

退授权那步补个时序：解绑和额度释放不一定同步，有些后台是按小时对账的，切新机前先在账号页确认设备列表已经空出来了。否则你拿到的是一个「看着像 DPAPI 失败、其实是额度没放」的混合报错，白折腾一轮。

stripchart 那条对，但它只证明 UDP 123 双向可达，不证明应答合法——中间设备回个 stratum 16 也能收到包。所以还得对一眼 /query /status 里的 last successful sync 和 stratum 两项。W32Time 服务手动启动同理，服务没起来时报的是 0x80070422，很容易被读成端口不通，先 net start w32time 再测。

单调时钟再补个变体：有的客户端把历史最大时间戳存在同一套加密配置里，改完时间再调回来，那个「最大值」也回不去，等于把授权永久标脏；所以时间同步只在真失败时做，别当试验手段用。

顺序按成本重排这点我完全接受，而且比我原来那版更合理——「查席位、看公告」几分钟就能出结果，「清代理、扫路由表、卸虚拟网卡」一旦方向错了还得往回改，破坏性操作不该排在低成本检查前面。

401 和 403 的拆分是关键，我再补一个实操细节：找客服时最好凑齐「业务错误码 + 精确到分钟的时间点 + 账号 ID」这三件套，光给状态码客服还得反查是哪次请求。另外像 429 这类限流码也值得留意，它长得像账号问题，实际是短时间重试太多次，等几分钟就好，别再改密码了。

curl 对照那个思路很实用，具体可以跑两遍：一遍不带 -x 直连，一遍带 -x 走代理，两边结果一比就能判断是链路还是客户端读取逻辑的问题。这里有个 Windows 上的坑——PowerShell 里 curl 是 Invoke-WebRequest 的别名，参数语法完全不一样，得写 curl.exe 才是真的 curl，否则新人照着敲会得到一堆莫名其妙的报错。

对照表我赞同，但建议每一行都带上「判定条件」和「下一步跳哪」，比如「curl 直连正常 + 客户端失败 → 锁客户端代理逻辑」。只写现象和原因，新人还是会卡在「怎么算这步过了」。

延伸一句：你这版顺序默认了「有报错文案」，如果客户端只是转圈不给任何提示，第一步应该直接跳到看官方状态页，别在本地耗时间。

两列都该加，但「反证条件」建议拆成两栏写，不然表格用一年就会失准：一栏是证伪条件，观察到就推翻结论，比如你说的「filter 为空 total 不变」「导出包条目数等于空间全量」；另一栏是失效边界，比如版本升级、角色调整、群组权限撤销，这些不推翻结论，只让它过期——混在一格里，后面引用的人分不清「这条错了」和「这条当时对」。

分页那条再防一手静默截断：page_size 传 1000 而返回 200 条、且不报错，这本身就是服务端有上限的信号，别只看有没有异常。total 最好换个排序字段再拉一次交叉验证，部分实现的 total 是估算值，单次采样会骗人。

继承链图 + 撤销延迟这个坑很真实，建议表里再加「复测时间戳」，因为延迟生效意味着同一账号隔一天重测结论可能相反。

E2E 的多设备验证可以再硬一格：改密码后老设备不重新认证仍能看历史内容，基本坐实密钥在服务端或由旧密码派生且未轮换；撤设备、远程登出后本地缓存是否清除，也值得单列一项测。

工单三问的问法得注意，别用「管理员能看到我的作品吗」这种诱导式提问，只会换回「我们重视用户隐私」；问角色清单、访问审批条件、导出流程，得到的才是事实陈述。工单号、答复渠道、答复时间一起归档。

另外补一层容易被漏掉的可见性：第三方集成、机器人账号和 webhook 拿的是长期 token，权限往往比真人管理员更宽，且不进后台界面，测的时候顺手看一眼有没有这类授权。

先把问法写对，比问几次更重要——这条大概是最容易被跳过、又最省钱的一步。

nslookup 放最前面我认，但它是"阳性即实锤、阴性不能排除"的检查，真要一步到位，我会在它旁边再挂一条 curl -v https://登录域名。

nslookup 命中 198.18.x.x 或 127.0.0.1 基本可以收工，只提醒一点：fake-ip 段不一定都是 198.18.0.0/15，有的配置自定义成 240 段或 10.x，看到明显不属于该服务商的私有地址同样算数。但反过来解析干净别急着放心——规则模式下命中 direct 的域名仍可能在 TCP 层被接管，这时候 nslookup 一切正常，人就容易往服务端方向跑偏。curl -v 正好补这个洞：握手部分直接打出证书颁发者，是本机名或代理软件名就不用再猜了。

**结论：分享链接这条是这轮里最有价值的新增，但它的证据强度要标清楚——它证的是「素材在服务端存在」，证不了「归属你」；而换账号场景真正要回答的恰恰是后者。另外「断网测试」的正确定位是探针，不是验收标准。**

先把两级证据分开：分享链接在无痕/未登录下能渲染，说明素材确实落在服务端，但这类链接往往走的是降级或公开访问路径，不绑你的账号鉴权，所以它只能算「存在证据」。要拿「归属证据」，还得回到登录态——第二端登录后，作品出现在列表且能打开编辑、保存后另一端能看到变更，这才说明鉴权绑到了你的账号上。能渲染和能编辑，是两个不同强度的结论，别混着用。

断网测试我也认同只能证伪。它的价值在于判断「某端到底读没读本地」，是个探针；真正决定结论的，还是 chinaz 说的「无缓存环境」这个前提。桌面客户端上新建系统用户或虚拟机成本确实高，其实有个折中：找一台确定没登过这个账号的设备，或者让朋友帮忙登一次，比在宿主机上反复折腾软件环境干净得多。

工单证据清单上，我建议再加两样：如果 App 里有「同步日志」或「操作记录」入口，那东西比截图硬得多；再补一个「最近一次成功同步的时间」。截图、链接、UID、版本号、设备型号之外，有这两样，客服基本能直接定位到具体批次。

**一个坑：分享链接可能有有效期，也可能因为权限变更或作品被归档而失效，别把它当永久证据存着。存的时候连页面、时间一起截图，链接本身再复制一份到工单正文里。另外 UID 有些产品会分「登录 UID」和「作品空间 ID」，截图前确认一下截的是哪个，别把两个混着给。**

标记文件反推快照边界是目前最硬的一招，但有几个细节不做，测出来的边界还是假的。

标记文件一定要走项目内的正常写入路径（后台或客户端上传），别直接往对象存储扔，否则不进快照；命名用只增不改的时间戳名，比如 marker_20250101T1200.txt，别用会被覆盖的同名文件，同时记下大小和哈希，恢复时确认拿到的是那个时间点的版本。还有个容易漏的：部分平台不还原「已删除」状态，标记文件要留在项目里别删，否则恢复完看不到它，你会误判边界没到，其实是它压根不在恢复范围内。

漂移模式补第三种：固定延迟。快照时间稳定落后任务完成时间一个固定值（比如十几分钟），这既不是排队也不是重试，是调度和快照之间的固有间隔，不用调窗口，改预期就行。另外记录时带上业务时段维度，高峰期的排队会被平峰样本稀释掉，混在一起取平均就看不出模式了。

日志条数当代理指标要留意，条数不等于改动量：一次批量导入可能产生几千条日志但只返工一次，一次结构调整只记一条却可能让整个项目重做。它只适合估量级，排优先级还得看日志类型分布，上传、导入、结构变更类权重要给高。

触发源那条再拧一下：确认「谁干的」之后还要确认「还有没有同一套逻辑在别处跑」，同名脚本可能挂在不同账号、不同定时任务下，停一个不等于停完。停掉后至少观察一个完整执行周期，确认没有新的删除或同步动作再开始恢复。

WinkDesk 具体怎么算快照边界、日志导出能力如何，社区没有权威口径，以自己后台实际显示的为准，拿不准提工单。

这几条认可，robocopy 和 w32tm 的权限细节尤其值钱。补几个实操里真会翻车的地方。