网页自动化最让人疲惫的时刻，往往不是页面完全打不开，而是它看起来还在那里，脚本却突然认不出来了。这次我遇到的就是这种情况：一个作品详情页已经更新，页面上的就绪容器和下载菜单仍然存在，但它们的类名后缀换了一轮，原本能工作的下载流程开始等待旧的选择器。
表面看，这是把两个字符串改成新字符串的修补题。可如果我真的这样处理，下一次页面再发布一次构建，脚本还会重新失效。真正要修的不是这一次变化的类名，而是自动化对不稳定细节的依赖。
页面没消失，识别方式先失效了
当时的场景很具体：页面已经加载出来，作品也确实存在，但脚本把“页面是否就绪”的判断钉在一个带哈希后缀的类名上。页面更新后，旧后缀变成了新的后缀，等待逻辑就像在一扇已经换了门牌的门前反复等候。下载菜单也遇到了同样的问题，菜单项的主体没变，类名后半段却发生了漂移。
这类问题很容易被误判为网络慢、页面没加载完，或者登录状态不对。因为自动化没有告诉我“元素存在但选择器过时”，它只能继续等待，最后把一个识别问题伪装成超时问题。如果不处理，后果不只是这次下载失败：就绪判断可能提前放弃，菜单点击可能找不到入口，后面的签名地址捕获和原图保存也就没有机会发生。
我一开始也本能地想过，直接把当前页面里的新完整类名复制进脚本。这是最快让眼前案例恢复的方法，却把下一次变化的成本原样保留下来。错误捷径不是“改得不够快”，而是把一次页面观察误当成了长期接口。
先确认漂移范围，再动手替换
这次处理的第一个判断，是不能只盯着报错位置。用户明确要求同时核查同一套自动化能力里其他类似的哈希类名，所以我先盘点真正的硬编码。第一次搜索用得太宽，把普通文本和无关内容也卷了进来，结果看起来很热闹，却不容易判断哪些地方真的会被页面改版击中。后来我收窄模式，只查带具体类名结构的选择器，才把真正需要处理的入口分离出来。
这个小转折很值得保留。搜索不是越宽越好，关键是搜索结果能不能改变决定。过宽的搜索会制造一种“问题很多”的错觉，让人要么把不相关内容一起改掉，要么因为噪声太大而漏掉同类风险。在修改共享流程之前，我会先用精确模式确认同一类脆弱依赖到底出现在哪里。
盘点后，目标不再是某个报错字符串，而是几种相同的风险：就绪容器的完整哈希类名、更多操作入口的完整哈希类名、下载菜单项的完整哈希类名，以及其他脚本中提交按钮、视频卡片和工具栏按钮上的类似写法。它们不一定都要在这次一起改，但至少要被看见、被分级，不能让“修好一个”掩盖“同类问题还在”。
稳定的不是名字，而是语义关系
替换策略最后落在两层匹配上。第一层用稳定的前缀或属性关系缩小范围，第二层再检查完整的类列表是否符合预期。这样做不是为了让选择器写得更复杂，而是为了同时处理两个风险：后缀会变，以及页面里可能存在相近但用途不同的子元素。
比如，页面可能在同一块区域里放置文字节点、图标节点和真正可点击的菜单项。只写一个很宽的包含关系，可能会误把子节点当成目标；只写当前完整哈希，又会在下一次发布后失效。因此我选择“前缀粗筛，加结构校验”的方式，是因为它把页面真正稳定的部分留下来，把构建系统随机生成的部分拿掉，同时不放弃对误匹配的防护。
这件事表面上是选择器语法，实际上是在判断什么可以被依赖。构建工具生成的短后缀没有业务含义，前缀、属性和层级关系才更接近页面的语义。一个选择器是否可靠，不看它今天能不能命中，而看页面只改变视觉构建细节时，它是否仍然能表达同一个意图。
我没有把所有选择器都改成最宽松的模糊匹配。那样看似抗漂移，实际可能把错误元素交给后续动作，造成更难排查的下载错位。稳定性不是“少写条件”，而是保留那些真正有解释力的条件。
兜底路径要在失败时能指路
选择器再合理，也不能假设页面永远符合预期。真实页面可能处在登录过期、验证码、加载未完成或接口没有返回签名地址等状态。过去的报错如果只说“找不到菜单”，下一步就很模糊：使用者不知道应该继续等、重新登录，还是切换到另一条路径。
所以这次修复把失败分成了不同类型。页面未就绪和登录状态异常不应该指向同一个排查方向；菜单找不到、签名地址没有被捕获，也应该给出明确的人工兜底路标。自动化路径失败时，可以改用浏览器里的手动请求拦截方式取回原图，这条路径在当天已经验证过，不是临时猜测。
如果不准备兜底，自动化系统就会把所有异常都压成“再试一次”。这种重试有时只是在重复等待，甚至让人误以为页面有问题。可靠的自动化不要求主路径永远成功，而是要求失败发生时，下一步仍然清楚且可执行。
这里也有一个边界：兜底不是把主流程做得更复杂，也不是遇到任何异常都绕过校验。它应该只承担主路径无法安全判断时的恢复责任，并且把触发条件说清楚。这样既保留自动化的效率，也避免把未知状态直接当成成功。
真实页面证明修复不是纸面上的
改完选择器后，我没有只看代码差异。先用单测确认旧哈希不再被依赖，相关的前缀匹配和错误分流都符合预期；单测共 24 个，全部通过。接着才找真实作品链接做端到端实测，并先确认测试对象确实来自真实生成记录，而不是文档里的示例编号。
实测采用 0 积分条件和保守的诊断模式，结果在 3.7 秒内取回了 2880×5120 的原图。这个结果的价值不在于速度数字本身，而在于它走过了真正的作品详情路径：页面识别、菜单操作、地址捕获、下载和产物检查都没有被假页面替代。最后还做了原图完整性抽查，确认文件不是只生成了一个看似成功的空壳。
我把验收拆成了 3 层。第一层是代码层，确认没有继续钉死旧哈希；第二层是行为层，确认真实页面能走通下载路径；第三层是产物层，确认尺寸和文件完整性符合预期。只做第一层，容易得到“代码看起来对了”；只做第二层，可能把一次偶然成功当成修复；只看第三层，又无法判断中间到底走了哪条路径。
这件事让我重新意识到，测试对象本身也是证据的一部分。一个看似有效的链接，如果来源不明，成功也不能说明真实流程被覆盖。验证不是最后补上的仪式，而是从选择测试对象开始就参与了判断。
从一次漂移提炼成一套规则
这次之后，我会把网页自动化的选择器检查归纳成一个小流程。先找页面中承担业务语义的属性、前缀和结构关系，再查同一能力范围内有没有同类的完整哈希硬编码；然后为每个关键入口写清正常路径和失败路标；最后依次做静态检查、真实页面操作和产物完整性检查。
这个流程的顺序不能随意交换。先改字符串再找同类问题，很容易漏掉共享风险；先上真实页面再确认测试对象，可能把一次偶然成功写进结论；只做单测不做下载产物检查，则无法知道后半段是否真的工作。
方法可以复用到任何会重新构建前端类名的页面：不要把随机后缀当成接口，不要因为一次命中就相信选择器长期稳定，也不要把错误提示写成只有作者自己看得懂的内部暗号。对于每个关键动作，我都会追问 3 件事：它依赖的到底是名字、属性还是关系？页面改变时哪部分最可能漂移？如果主路径失败，使用者能否按提示完成恢复？
一个流程成熟的标志，不是它能在今天跑通，而是下一次页面变化时，系统能少依赖临场记忆。
下次我会怎么做
下次再遇到网页更新，我会先停下“复制新类名”的冲动。第 1 步，确认失败点对应的是页面状态、身份状态还是选择器状态；第 2 步，用精确模式盘点同类硬编码，区分当前必须修和需要登记的风险；第 3 步，优先寻找属性、前缀和结构关系，并保留防误匹配的校验；第 4 步，给主路径写一条明确的人工兜底；第 5 步，先单测，再用真实页面和真实来源的对象操作，最后检查产物。
我会特别记录“为什么这样匹配”，而不只记录“改成了什么”。因为页面下次再变时，真正有用的不是一串旧选择器，而是当时对稳定语义和随机细节的区分。工具真正改变的不是速度，而是能不能把判断过程留下来，让下一次不用从零开始。
这次修复最终解决的是一次选择器漂移，但留下的规则更重要：把页面的偶然外观和稳定意图分开，把失败后的路标提前准备好，再用真实行为和真实产物证明修复有效。这样，自动化才不是跟着网页每次改版逐个打补丁，而是在变化中仍然知道自己要找什么。