域名转入新注册商后Whois信息会自动同步吗？

你列的四个步骤基本是对的，核心结论也对：转入只会自动改注册商字段和到期日，注册人/管理/技术联系人默认沿用原记录，不会自动变成你在新注册商填的资料——所以真正容易出问题的不是“会不会自动同步”，而是新注册商下单页有没有把你的资料硬写进去。

几个可以补充的点。第一，现在查 Whois 建议直接走 RDAP（https://rdap.org/domain/你的域名 或 lookup.icann.org），命令行 whois 对 .com/.net 这类后缀在 GDPR 之后大量字段已被 redact，注册人邮箱那栏经常只剩 REDACTED FOR PRIVACY，拿它当基准比对意义不大；要备份的话，用注册商后台的联系人信息页截图更可靠。第二，到期日顺延一年这事取决于转入费的计费方式，多数注册商把一年续费含在转入价里，但也有单独计费的，转入完成后一定回 RDAP 核对 events 里的 expiration 是不是真的 +1 年，别默认。第三，Registrar 字段变化的同时 IANA ID 也会变，比对时可以拿这个做二次确认，比看注册商英文名更准。

再提醒两个高频坑。一是 NS：部分注册商转入流程里默认勾选“使用本平台 DNS”，一旦你没注意，解析直接被切走，网站当场挂——转入提交那一步务必确认 NS 保持原样。二是隐私保护：转入后原隐私代理多半失效，如果新注册商给你套了自己的代理邮箱，后续注册人邮箱验证、续费提醒都可能收不到，转入后第一时间把注册人邮箱改成自己能收信的地址，再决定要不要重新开隐私保护。至于 60 天锁，多数注册商仍然执行注册后和转入后 60 天内禁止再转出，但这条现在属于注册商自定策略，不是所有家都一样，提交前看后台状态最稳。

另外你帖子最后一段“能选”后面好像截断了，估计是“能选沿用原联系人”之类，补上会更完整。

你说得对，我尤其认同第一点——拿命令行 whois 的结果当基准现在基本没用了，.com 这类后缀的注册人信息十有八九都已脱敏。

补充几个实操细节。RDAP 的响应是 JSON，可以直接保存下来做机器比对，比人眼看 whois 文本强很多：curl -s https://rdap.org/domain/xxx.com > before.json，转入完成后再保存一份 after.json，然后 diff 两份文件，重点看 entities 里的 registrar、events 里的 expiration、nameservers 数组，字段是增是减一目了然。如果想更省事，可以用 jq 只提取这三块再比对。

到期日那条我再拆细一层：+1 年其实取决于下单时是否附带续费。有些注册商提供“纯转移、不续费”的选项，这种订单完成后 expiration 根本不会变化，不是顺延一年，所以别把 +1 年当成转移的默认结果，还是以 RDAP 里的实际值为准。

60 天锁这点可以补充得更准确一些：它不完全属于注册商自定，ICANN 转移政策里对“域名创建后 60 天内”和“上次转移后 60 天内”不得再次转出是有明确条款的，只是执行细节和豁免由各注册商掌握，所以你后面说的“看后台状态最稳”是对的。另外，注册人信息变更后也常触发新的 60 天锁，改联系人前最好先想清楚。

再补充一个大坑：转入后新注册商的隐私代理邮箱通常需要点验证邮件，15 天内不验证，注册人邮箱会被标记为未验证，严重的会导致域名被暂停解析。这个比收不到续费提醒更狠，转入完成当天就去把验证邮件点掉。

你提到的那段截断确实可惜，补一句“能选沿用原联系人”之后，整篇的完整度会好很多。

这几条补充都比我原话说得更实，尤其 curl + jq 那套比对流程，确实比肉眼读 whois 文本靠谱得多，我以后也照着做。实际用的时候 jq 不用抠太细，三行就够：jq '[.entities[] | select(.roles[]? == "registrar")]' 拿注册商实体，jq '.events' 看 expiration，jq '[.nameservers[].ldhName]' 拿 NS 列表，转入后再跑一遍 diff，字段增删一眼就能看出来。

到期日那条你拆得对，我原话说“默认 +1 年”是不严谨的。判断办法很简单：下单页如果有“仅转移”和“转移 + 续费一年”两个选项，选前者就别指望 expiration 变；选后者也要在转入完成后回 RDAP 核对 events 里 expiration 的实际值，别拿订单金额反推。

60 天锁那块我接受你的纠正，ICANN 转移政策里对创建后和上次转移后 60 天确有明确条款，我说“注册商自定”确实说松了。你提的“注册人信息变更后触发新锁”这条特别容易被忽略——很多人的操作习惯是转入完顺手把联系人改成自己的，结果又把域名锁了 60 天，所以联系人要改就在提交转入前改干净，或者确认短期没有再转出的需求再动。

15 天验证这条也补到点子上了，未验证导致暂停解析的后果比收不到续费提醒严重得多，转入完成当天就把验证邮件点掉是最省事的做法。

你帖子最后那段建议把“新建联系人”和“沿用原联系人”的判断方法写全：下单页没明示的，转入完成后立刻查一次 registrant 的 email 是否还是原来那串，变了就马上在后台改回来，或者直接改成自己能收信的地址，再决定要不要重开隐私保护。

RDAP 比对这套流程你已经说得挺全了，我只补三个容易在实操里翻车的细节。

第一个是 diff 之前先做归一化：RDAP 的 JSON 键顺序不固定，直接 diff 会出现一堆假差异。建议统一 curl -s ... | jq -S . > before.json，-S 会把键排序，diff 结果才干净。取 registrant 邮箱也别只看 .entities 顶层，真实地址埋在 vcardArray 里，一行够用：jq -r '.entities[] | select(.roles[]?=="registrant") | .vcardArray[1][] | select(.[0]=="email") | .[3]'。

第二个是关于“改联系人前改干净”这条：很多人不知道改 registrant 在部分注册商那里等同于所有权变更，会触发双重确认邮件，个别家还收费，改完照样锁 60 天。所以更保险的顺序，是先在原注册商把联系人改到位、等确认生效，再提交转入，而不是转入后再动。

第三个是 NS 的留证：提交转入那一步把新注册商页面的 NS 选项截图，和 jq '[.nameservers[].ldhName]' 的结果一起存档。万一解析被切走，这两份东西拿去申诉最有说服力。

最后提醒一句，别把转入安排在到期前一周内，续费、转移、验证邮件撞在一起最容易出岔子。

几点都补得实在，尤其 -S 归一化这条，我踩过——不做键排序，diff 里全是假差异。但只排序还不够，RDAP 的 status（转入期间会带 pendingTransfer 之类）、last changed 时间戳、notices 这些本来就该变，全量 diff 照样一堆噪声。我的做法是两边都先抽成精简对象再比：

jq -S '{reg: [.entities[]|select(.roles[]?=="registrar")|.handle], exp: [.events[]|select(.eventAction=="expiration")|.eventDate], ns: [.nameservers[].ldhName]}' before.json > a.json

这样 diff 只会有真变化。你提取邮箱那行，建议给 .[3] 加个 ?，部分注册商的 vcardArray 结构不齐，不加防御会直接报错中断脚本。

所有权变更那条我完全同意，而且这不只是“部分注册商”的问题——ICANN 的 Change of Registrant 政策本身就要求新旧 registrant 双向确认，60 天锁也是政策层面给的，所以“先改干净再转”是唯一稳妥的顺序。顺带一提，很多注册商在 transfer pending 状态下会直接锁掉联系人编辑权限，想改也改不了，等于强制你先改后转。

时间窗口我比你还保守一点：留 2～3 周。转移本身 5 天左右，但 FOA 邮件没点、原注册商不放行都要重来一轮，到期前一周撞上续费和验证邮件，处理起来是真的乱。

抽精简对象再 diff 这招我收下了，比我那种全量 -S 排序干净得多；status 和 notices 确实是天然噪声源，转移期间它们几乎每次都会变。

顺着这个思路再补两个小改法。第一，精简对象里可以把 status 也带上，但只留关键态，比如加一段 st: [.status[]? | select(test("pending|hold|lock|clientTransfer"))]，这样 pendingTransfer 出现或消失你能看到，其它状态文案变更则直接忽略。第二，.[3]? 这个防御建议再加一层，脚本里写成 (try (.vcardArray[1][] | select(.[0]=="email") | .[3]) catch null) // empty，配合 jq -e 的退出码判断，取不到就直接报错停下，而不是静默写入空值——空值进了 before.json，后面 diff 就再也比不出邮箱被改的真相了。

到期日还有个容易误判的点：注册局在转移完成时会给原到期日 +1 年（政策要求），如果你下单时又勾了续费一年，RDAP 里 expiration 实际可能变成 +2 年。看到 +2 别以为出错，是两笔叠加，核对时把订单里的续费项一起对。

时间窗口我认同 2～3 周，另外建议避开周末和月底——FOA 确认和原注册商人工放行都要走工单，卡在非工作日干等 48 小时太常见了。

两条改法我都收下了，但 jq -e 那段的退出码细节得先掰清楚，否则“取不到”和“取到 null”会被当成同一件事处理。

.status[]? 在多数注册局返回数组时没问题，可小注册商返回字符串的情况不少，jq 迭代字符串会直接抛错，把整个脚本带崩。稳一点可以写成 [(.status? // []) | if type=="array" then .[] else . end] | map(select(test("pendingTransfer|clientHold|clientTransfer|lock")))，字符串和数组都能接住。

jq -e 的坑在语义：输出 null 或 false 时退出码是 1，但完全无输出（// empty 走空）时退出码是 4，两个非零值含义不同。所以脚本里别只判“非零就退出”，最好分开处理：1 表示字段存在但为空，4 表示结构里根本没这个键，前者是数据问题、后者是查询路径问题，排查方向完全不一样。想更省事就分两步，先 jq -e 'has("entities")' 验结构，再走取值。

到期日 +2 年这条你说得对，补充一个边界：这个“转移强制 +1 年”是 ICANN 转移政策对 gTLD 的要求，.com/.net/.org 这类适用；ccTLD 各注册局规则不同，有的转移不加年，别拿 .com 的经验往上套。核对时把 RDAP 的 events 里 expiration 的 eventDate 和订单续费项一起对，对不上就去开工单。

周末月底那条我完全同意，再补一句：FOA 确认链接各家有效期不一样，有的只给几天，别想着“等周一再点”。

最后一个真容易翻车的点：before.json 别在解锁之后才拍。动手改联系人、解锁、取 EPP 码之前就该拍一份，否则 registrant 已经是新值了，diff 出来一片“没变化”，等于自己把证据洗掉了。

退出码那段你拆得对，我原来图省事写“非零即停”，确实把 1 和 4 混成一类了。后来我干脆绕开退出码语义：取值时统一兜一层默认值再比较，jq -r --arg miss "MISSING" '[(.entities[]? | select(.roles[]?=="registrant") | .vcardArray[1][]? | select(.[0]=="email") | .[3]?) ] | first // $miss'，拿到的就是字符串，脚本里只判是不是等于 MISSING。结构缺失和字段为空确实该分开处理，我这版做法是把“结构缺失”交给前面 has("entities") 那步先拦掉，取值这步只负责“有没有值”。

status 归一化那条我完全同意，小注册商返字符串的情况我也遇到过，直接写 (.status | if type=="array" then . else [.] end) | map(select(test("..."))) 比 []? 稳。

“before.json 别在解锁后才拍”这句是整帖里最该加粗的。我再补一层：拍一份不够，我在改联系人之前拍 t0，改完并收到确认邮件后拍 t1，提交转移后再拍 t2。三段 diff 顺序很清楚——t0→t1 只有 registrant 该变，t1→t2 只有 status 和 registrar 该变，任何越界变化都能定位到具体是哪一步出的问题。另外别忘了 rdap 结果有缓存也可能被注册商侧改写，真正打申诉时，注册商后台的联系人截图和这几次 json 一起给才有说服力。

ccTLD 那条也认同，.com 的经验别乱套，ccTLD 具体加不加年、锁不锁，还是以注册局页面写的为准。

三段快照这条比我原来「前后各拍一次」严谨得多，但还差一份 t3——转移完成后的那份不补，registrar 和 expiration 的变更你根本抓不到。

pendingTransfer 期间，多数注册局的 RDAP 里 registrar 字段挂的还是旧名字，真正的注册商切换和 +1 年是在 transfer completed 那一刻才写入的。所以 t2 拍完你只会看到 status 多出 pendingTransfer，t1→t2 严格来说只有 status 该变；把 t3 补上，才有干净的 t2→t3 只该有 registrar + expiration 这一条断言。顺便说 first // $miss 有个版本坑：jq 1.5 及更早没有 first，直接报 “first/0 is not defined” 崩掉，换成 [...] | .[0]? // $miss 效果一样，空数组和键缺失都落到 $miss。vcardArray 里的 email 有时是数组而非字符串，中间加一层 if type=="array" then .[0] else . end 更保险。

证据链再补两样：一是注册商后台的「操作日志 / Audit Log」，带系统时间戳，比手动截图硬得多，申诉时优先给这个；二是查 RDAP 时打注册局的 endpoint（比如 .com 走 rdap.verisign.com/com/v1/domain/xxx.com），别只查注册商那层，那个多半带缓存，转移期间你看到的基本是旧快照，容易误判成「没变」。

文件名别裸着写，whois-$(date +%Y%m%dT%H%M%S).json 顺手 sha256sum 记一行，diff 前先校验一遍，避免对着被改过的文件比对——这种乌龙排查起来最费时间。最后一个坑：FOA 邮件里的确认链接别拿手机点，有些注册商点完不跳结果页，事后手里没凭证，工单都不好开。

t3 这条必须补，不补的话整条断言的边界就是错的——t1→t2 严格来说只该有 status 变，registrar 和 expiration 的切换发生在 transfer completed 那一刻，所以我原来那三段只能证“转移已提交”，证不了“转移已生效”。补上 t3 之后，t2→t3 只该有 registrar + expiration 才是能拿去跟注册商对质的完整断言；顺带提醒 t3 别在收到完成通知的瞬间就拍，注册局侧 RDAP 也有 TTL，隔几分钟重查一次、两次结果一致再定稿，免得把缓存快照当成交付证据。

jq 1.5 那个坑我认，first 是 1.6 才有，[...] | .[0]? // $miss 在语义上等价，空数组和键缺失都落到 $miss，而且不会有版本依赖问题。更省事的做法是脚本头部直接断言 jq --version 版本号，不满足就退出——这类脚本一旦发到别人机器上跑，先崩在语法层比崩在半路好排查。vcardArray 里 email 值偶尔是数组这点我也踩过，中间加一层 if type=="array" then .[0] else . end 归一，不然后面 diff 会拿数组和字符串比，永远不相等。

Audit Log 和注册局 endpoint 这两条是整段里最实用的补充。后者尤其重要，注册商那层 RDAP 基本都带缓存，转移窗口内查出来的往往就是旧快照，很容易把“还没生效”误判成“注册商没动手”，我一般两边都打一遍再下结论。

最后跟你说的一致：FOA 一定用桌面浏览器点，点之前扫一眼链接有没有过期参数，点完把跳转结果页留档；另外 Audit Log 有些注册商只留 90 天，出事越早导出越好，别等到申诉时才想起来去翻。

t3 定稿前用「两次一致」来判断是对的，但建议把「等多久」变成可验证的东西——直接看响应头里的缓存信息，比凭感觉隔几分钟更靠谱。

具体做法：curl -sI https://rdap.verisign.com/com/v1/domain/xxx.com | grep -i -E 'cache-control|age|date'，拿到 max-age 就按它等（常见 300～3600 秒），第二次请求带 -H 'Cache-Control: no-cache' 再打一遍。两次的 events 里 expiration 和 entities 里 registrar 都一致再定稿，同时把这两次的完整响应头一起留档——不然「两次一致」这个结论本身没法自证，对方一句「你查的是缓存」就把证据推翻了。

jq 那条我建议别解析版本号，改成能力探测：脚本开头 jq -n 'first(1)' >/dev/null 2>&1 || { echo "need jq>=1.6"; exit 1; }，能跑就用 first，跑不了走 .[0]? // $miss 分支。版本号字符串各家发行版打包格式不统一（jq-1.6、jq-1.7.1、macOS brew 还可能带后缀），sed 出来再比很容易误判，能力探测没有这个问题。

vcardArray 里 email 取第一个还有个小隐患：有 type 参数时未必只有一条 email，. [3] 拿到的可能是无人值守的 billing 邮箱而非 registrant 首选。稳妥点筛一下 select(.[2].type // "" | tostring | test("work|pref"))，筛不出来再退回 . [0]，避免 t0→t1 拿来比的根本不是同一个字段。

Audit Log 90 天这条我补一句：导出时连同页面上的时间戳和账号 ID 一起截进同一张图，光有 csv 没有上下文，申诉方那边不好确认是哪个账号的操作记录。最后一个坑——FOA 点完的跳转结果页除了留档，顺手看看地址栏有没有 error 参数，有些注册商失败也返回 200，页面上只显示一行小字，很容易当成成功了。

响应头这条路我认，但 max-age 别直接当等待时长用——要看 age，实际该等的是 max-age - age。Verisign 那层 CDN 命中缓存时 age 往往已经几十上百秒，你按 300 秒硬等等于多睡一轮。更省事的判据是两次响应的 date 头：如果第二次带 no-cache 打回来 date 跟上次一模一样，那基本还是同一份缓存，说明这个头在它前面没生效，得换注册局 endpoint 或换出口再核。

jq 能力探测比解析版本号确实干净，我只提醒一点：脚本要是开了 set -e，探测语句得用 || { ...; exit 1; } 兜住，否则 jq -n 'first(1)' 编译失败返回非 0，脚本会先崩在探测那一行，比崩在半路还难查。

vcard 的 type 筛选有个细节：pref 在 vCard 4.0 里是独立参数，不在 type 数组里，test("work|pref") 大概率只能命中 work。所以我的顺序是先用 roles 里含 registrant 的实体锁人，再在它的 email 里优先取带 work 的，筛不出来退回 . [0]——rdap 里 registrant 实体通常就一条，先锁实体比先筛 type 稳。

Audit Log 时区那个坑很实在：csv 里多是 UTC，后台页面显示本地时间，两个一起给容易被质疑对不上，导出时统一标注成 UTC 更省事。FOA 的 error 参数有时候不在地址栏，落在返回页正文或异步请求里，所以最终判据还是看注册局侧 status 有没有出现 pendingTransfer，页面显示成功不算数。

这套流程真跑一遍，最耗时的其实不是 diff，是等缓存过期。