旧服务器的备份硬盘在去年夏天坏过一次，从那以后我就把查询入口的逻辑重写了一遍。这里列的是这半年攒下来的记录。
2018 年 11 月第一次在旧站后台见到这个词，当时查询接口还是一次性返回全表，四千多条记录一起吐出来，浏览器卡了整整 9 秒。
迁移脚本跑了三遍才对齐。第一遍字段名多了一个空格，第二遍编码从 GBK 转 UTF-8 时丢了两个生僻字。第三遍我在凌晨两点核对完 117 行差异。
老周在电话里说，他那边网络一断，下载就得从头来。我把文件切成 2MB 的分段，加了断点记录，现在断网再连上能接着走。
硬盘坏的那次，恢复出来的旧资料里有三分之一的查询关键词对不上。我一条条比，最后补回 686 条，剩下的只能标成未知来源。
有人输入全角空格，服务端判非空，数据库却查不到。第一版把空格全清了，第二版又误伤了带空格的资料名。第三版才分清哪些该留。
打印出来钉在桌边。最慢的一条 4.7 秒，是资料编号没有索引时做模糊匹配。现在同样的查询是 42 毫秒，翻了大约一百倍。
以前一次列 40 个文件，用户找不到还怪加载慢。改成 15 条一页，下一页按钮放右下角。说实话，这个决定我犹豫了两周才做。
试过三个高亮库，最后全删了。现在就是在返回串里做一次分割拼接，正则只匹配汉字和数字。快，而且不出错。
之前直链被转发到别处，日志里出现了 1200 多次外部请求。加上签名和时效之后，一周内掉到个位数。老用户抱怨过，后来也习惯了。
资料标题里一个"·"被显示成问号。查了四十分钟，发现是导出时用了错误的字符集。改完那一行，我把咖啡喝完才走。
有人说他要找三年前的一份资料，翻了六页才看到。现在匹配度高的在前，时间是次要权重。这个改动争议最大，但我坚持了。
旧注释是 2017 年写的，很多对不上代码。我花了一个下午，把 34 个函数逐条补上说明，删掉 11 条过期的。写完关门，天已经黑了。
我不太相信所谓"一步到位"的重构。这套查询层改到现在，走过的弯路能列一整页。真正有用的改动，多半是被某一次事故逼出来的。
数据恢复那次让我明白，备份不是存起来就算完，要能读得出来、对得上号。所以后来每加一条下载通道，我都自己断一次网，看它能不能接上。