网站性能优化方法：把人工经验写成脚本需求时怎样描述例外情况
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8aac169768e3.html
📄
网站性能优化方法：把人工经验写成脚本需求时怎样描述例外情况
直接回答：不要只写“正常情况下如何处理”，而要把每条人工经验拆成三部分——触发条件、默认动作、例外分支。例外分支必须写明识别信号、此时改为执行什么、以及记录什么字段供下一步判断。否则脚本只能处理你见过的那一次，遇到旧页面、旧系统或旧合作关系留下的半成品就会做错决定。
先选一个对象：拿你手里最旧的那张页面当样本
假设你手上有一张三年前做的产品页，图片没有统一尺寸，部分旧外链已经失效，但正文仍有搜索流量。你要写一个脚本批量处理这类页面，第一步不是打开编辑器，而是把这张页面当成“人工判断的录像”回放一遍：你眼睛看到什么、心里比较什么、最后动手改什么。
把回放结果写成三列：观察到的信号、你做的判断、你执行的动作。例如信号是“首屏图片宽度超过容器两倍”，判断是“这张图可能被旧模板写死了宽度”，动作是“先不压缩，标记为待确认”。这三列就是脚本需求的骨架，例外情况就藏在第二列和第三列之间。
例外情况要写成“如果……则……否则记录……”
人工经验里最容易被漏掉的是“我本来想改，但看了一眼又决定不改”。写脚本需求时，这种犹豫必须变成可执行的分支，而不是一句“视情况而定”。
- 触发条件：脚本在什么数据状态下进入这条规则，例如图片文件大小、外链返回状态、模板标识。
- 默认动作：绝大多数情况执行什么，例如压缩到指定宽度、替换为新链接、跳过处理。
- 例外分支：什么信号出现时偏离默认动作。信号必须是脚本能读到的，例如“图片同时出现在三个以上页面”“外链域名与当前站点主域相同”“页面最后修改时间早于某次改版”。
- 例外动作：偏离后改为执行什么，例如只记录不修改、转入人工队列、先备份原值。
- 记录字段：例外发生后写入日志的字段，供下一步决定是继续自动处理还是回头改规则。
假设一条规则是“把宽度超过1200像素的首屏图压缩到1200像素”。例外可以写成：如果该图同时被三个以上页面引用，则只记录不压缩，并写入引用页面数量和原图路径。这个动作的结果是：你拿到一份“共用图片清单”，下一步可以决定是统一换图，还是为每个页面单独生成副本。
用“旧合作关系”类例外检验规则是否写全
旧系统或旧合作关系留下的页面，常带有外部约定的痕迹：友链位置、联合品牌标识、历史活动入口。这些内容对性能优化来说可能是负担，但不能直接删。写脚本需求时，要把“谁在依赖这个元素”作为例外条件之一。
可以这样描述：默认动作是删除已失效的活动横幅；例外是如果横幅所在区块包含合作方标识或跳转域名不在本站控制范围内，则改为仅隐藏并记录区块标识、合作方域名、首次发现时间。这个例外不承诺任何收录或排名结果，它只保证脚本不会替你做越权决定。
这里有一个需要说明的适用条件：上述判断依赖你能读到区块标识和跳转域名。如果旧系统把这些信息写死在图片里，脚本无法识别，就应该退回到“整块保留并标记人工复核”，而不是猜。
把例外写成短例子，验证下一步是否可执行
下面是一个假设的规则片段，用来说明描述方式，不代表任何真实工具的运行结果：
规则：处理首屏图片
如果 图片宽度 > 1200 且 引用页面数 = 1，则 压缩到1200并覆盖原文件
如果 图片宽度 > 1200 且 引用页面数 > 1，则 不修改，记录路径、引用页面数、原宽度
如果 图片宽度无法读取，则 跳过，记录路径和读取失败原因
写完后做一次纸上推演：拿三张不同类型的旧页面，逐行走一遍规则，看是否每张都能落到某个分支，且每个分支都有记录。如果某张页面走完后你仍然不知道下一步该做什么，说明例外描述还缺一个识别信号或一个记录字段。
动作与结果的关系在这里很直接：你补充的每个例外分支，都会让脚本少做一次错误修改，同时多产生一条日志。日志不是负担，它是你下一轮调整规则的依据。如果日志里某类例外反复出现，你可以把它提升为新的默认动作；如果某类例外只出现一次，就保留人工处理，不必为它增加脚本复杂度。
比较改动前后时，别把例外日志当成效果证据
例外日志只能说明脚本遇到了什么，不能单独证明性能变好或变差。一次改动前后比较要考虑季节、搜索需求变化和数据采集差异。例如同一张页面在活动期和非活动期的访问构成不同，图片请求量下降可能来自流量减少，而不是压缩生效。
更稳妥的做法是：先把例外日志和性能数据分开存放，分别回答两个问题——脚本是否按预期处理了旧页面，以及页面指标是否朝预期方向移动。前者看日志分支命中情况，后者看同一组页面在可比时间段内的变化。两者都成立时，再决定是否扩大脚本处理范围；只有日志命中而没有指标变化，或只有指标变化而日志显示大量跳过，都说明下一步应该先查原因，而不是直接推广。
回到你手里那张旧页面：先把它的人工判断写成一条带例外分支的规则，跑一次，看日志里出现的是你预料中的分支还是新分支。新分支就是下一篇脚本需求要补的例外。
