子域名解析：静态响应与脚本渲染结果不同时怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e588b570626d.html
📄
子域名解析：静态响应与脚本渲染结果不同时怎样定位差异
先做一次分层对照：把同一子域名的原始 HTML 响应、脚本执行后的 DOM、以及解析记录本身分开保存，再比较三者的差异出现在哪一层。若静态响应里已有目标内容，而脚本渲染后反而消失或替换，问题通常不在 DNS，而在页面脚本、资源加载或渲染时序；若静态响应为空、脚本渲染后才有内容，则要区分是服务端按请求头分流，还是前端在客户端拼装。
先确认差异发生在哪一层，而不是急着改解析
拿一个具体页面作为样本，用两种方式各取一次结果：一种只取服务器返回的 HTML 源码，不执行脚本；另一种让浏览器或渲染环境执行脚本后再取 DOM。把两份结果并排看，重点不是“哪个更全”，而是目标片段在哪一份里出现、在哪一份里缺失。
- 两份都有目标内容：差异可能只是属性顺序、空白或注释，通常不影响后续判断。
- 只有静态响应有：脚本执行时把该节点删除、替换或隐藏了，优先查脚本对容器的操作。
- 只有脚本渲染后有：静态响应里没有该内容，需要判断它是被服务端按条件省略，还是本就由前端请求后插入。
- 两份都没有：先把范围从渲染问题移开，检查解析是否指向了预期主机、请求是否落到了正确服务。
这一步的实际动作是固定一个样本并保存两份快照。保存后你才能在下一次改动前后做同口径对比；否则每次看到的差异都可能来自不同的请求条件，无法归因。
用请求条件做对照，排除服务端分流
静态与渲染结果不同，常见原因之一是服务端根据请求特征返回了不同内容。此时不要直接改解析，而是控制变量再取一次：
- 保持 URL 不变，只改变请求头中的用户代理或接受类型，观察静态响应是否变化。
- 保持请求头不变，只改变来源路径或参数，观察是否触发不同模板。
- 若两者都稳定复现同一差异，说明分流规则在服务端；若只在某一条件下出现，说明差异是条件性的，不能推广到整个子域名。
这里要写清边界：个别样本成立不等于规模化后每个页面都成立。一个页面因为脚本时序产生差异，不能直接推断同子域名下所有页面都要按同样方式处理。规模化前应至少覆盖不同模板、不同内容类型和不同入口路径的样本，再决定处理方案。
区分“内容缺失”与“内容被替换”的下一步动作
两种差异对应不同处理方向：
- 内容缺失：静态响应中没有目标片段，脚本渲染后出现。先查该片段是否由前端异步请求获得；若是，检查该请求是否依赖登录态、地区或特定参数。若依赖，则静态响应缺失属于预期，不应按解析故障处理。
- 内容被替换：静态响应中有目标片段，脚本渲染后被其他内容覆盖。先定位操作该容器的脚本，确认它是在什么条件下执行替换。若替换只在特定视口或特定交互后发生，说明它未必影响首次渲染结果。
假设一个页面在静态响应中包含标题文本，脚本执行后标题被改为另一段文字。此时先不要动解析记录，而是记录替换发生前后的 DOM 差异，并确认替换是否依赖用户操作。若替换不依赖操作就发生，下一步应检查脚本加载顺序；若依赖操作，则它不影响首次抓取所见内容，处理优先级可以降低。
把差异转成可执行的处理方案
定位到具体层之后，处理动作才有针对性：
- 差异在解析层：核对子域名指向的主机、记录类型和生效范围。若解析指向了错误主机，静态与渲染结果都可能异常，此时先修正解析再复测。
- 差异在服务端分流：统一请求条件，或让服务端对目标内容采用一致输出。修改后重新取两份快照，确认差异是否消失。
- 差异在前端渲染：确认目标内容是否必须依赖脚本。若必须，评估脚本失败时静态响应是否仍有可读内容；若不必须，考虑让关键内容在静态响应中直接输出。
- 差异只在个别样本：不要立即全站改动，先扩大样本验证边界，再决定是否统一处理。
每个动作之后都要回到同一份样本复测，并记录结果是否稳定。若复测结果仍随请求条件变化，说明还有未控制变量，下一步应继续缩小条件范围，而不是直接扩大改动范围。
规模化前必须写清的适用条件
当样本从一两个页面扩展到整个子域名时，以下条件决定了方案能否照搬：
- 目标内容是否在所有模板中都由同一机制产生；只要有一个模板走不同路径，就不能统一处理。
- 脚本渲染结果是否依赖登录态、地区或设备；依赖越多，静态与渲染的差异越可能只是条件差异。
- 解析记录是否在所有子域名下一致；不一致时，先分别核对，不要用单个结果代表全部。
- 修复后的验证是否覆盖了原始差异条件；只验证默认条件，可能漏掉仍然存在的例外。
把上述条件写成一份简短的检查记录，标注每个样本的请求条件、两份结果的差异点和处理动作。这样在规模化时，你能快速判断新出现的例外是同类问题还是新的分流条件，而不是把每个差异都当成解析故障重查一遍。
