创业搜索架构：流量、合规、运营三重突破

　　去年十一，我蹲在工位上切第十版搜索框的 placeholder 动效，控制台报错是 `Uncaught (in promise) TypeError: Cannot read property 'length' of null`，第 37 行，src/components/SearchBar.vue——你懂的，就是那个被后端说“字段名下周改”的 `suggestionList`，结果改完当天就上线了，连个预发环境都没走。当时会议室白板没擦干净，上面还留着产品经理用蓝笔画的“搜索即服务”四个字，底下被谁拿黑笔划了两道杠，末尾补了句：“先搜出来再说”。

　　跟产品吵架是在九月二十八号下午三点十七分，他端着杯子站了很久，水汽在杯壁凝成一道歪斜的痕。我说“搜索入口埋点没接，搜词漏 30%”，他手一扬，咖啡差点洒在设计稿标注上——那稿子右下角写着“搜索框高 44px（含边框），禁用系统字体”，但没标 placeholder 的行高，也没标 focus 状态下 border-color 的十六进制值。我当场把键盘上那个早掉漆的 Caps Lock 键按下去又弹上来三次，咔嗒、咔嗒、咔嗒，没人接话。

　　有人在背后走过碰了椅子，金属腿刮地一声长响。我们就在那声里重新跑了一次 build：构建日志最后一行是 `webpack compiled successfully in 8.2s`，可 H5 搜索页在测试机 iPhone 8（iOS 15.7）上首屏转圈、按钮点了没反应、控制台一片红——不是报错，是空 console，像被谁拔了线。不是缓存没清，是搜索请求根本没发出去，request header 里连 `X-App-Version` 都没塞进去，因为公共 axios 实例初始化时被某次 commit 里一个 `// TODO: 加版本头` 注释挡住了三周。

　　那版架构所谓“三重突破”，纯属贴金。流量？搜词归因全靠 UA 字符串硬扒，埋点脚本压根没挂到 search-submit 的 click handler 上，只挂在了 form.submit，但实际业务里表单根本没 submit，全走 preventDefault + fetch。合规？我们还在用旧版百度统计 JS SDK，GDPR 弹窗逻辑写在 `mounted()` 里，但搜索框组件是异步加载的，弹窗 DOM 插入时页面都已滚动出视口。运营？所谓“热词推荐位支持动态配置”，实际配置项藏在中台页面一个叫 `/search/config/override` 的 POST 接口里，但接口响应字段是 `hot_words_list`，前端代码里写的是 `hotWords`，中间差了个 underscore，且没加 fallback。不是不知道，是每次联调后端都说“我这边返回是对的”，然后甩来一段 curl 命令，不带 -H。我们自己跑一遍 curl ——返回确实是对的，但他忘了提那条 curl 是在 postman 里手动加了 `Accept: application/json;charset=utf-8` 才跑通的，fetch 默认 headers 不带 charset，node 后端就静默转成了 406。

　　工位的显示器是竖着的，用来看长日志和接口返回体。十一那天凌晨一点，我盯着一行 `content-type: text/plain; charset=iso-8859-1` 发呆，那是个搜索 suggest 接口的 response header，而我们所有前端代码默认用 UTF-8 解码，结果中文热词变成 。不是没试过加 `responseType: 'arraybuffer'` 再 hand decode，是加了之后 Safari 直接 throw SecurityError——因为跨域响应没带 `Access-Control-Allow-Headers: Content-Type`。后端说：“我这个接口本来就不该被跨域调。” 我回：“那你别让 search.xxx.com 调啊，你让它跟主站同域。” 他说：“主站域名配不了，CDN 过期策略冲突。” 我点头，转身删掉了刚写的 decode 逻辑，改成直接 `new TextDecoder('utf-8').decode(new Uint8Array([...]))`——管它 iso 还是 utf，先让字出来。字出来了，但全是乱码，乱码比没字更糟，因为运营同学截图给老板看时，误以为是“数据源异常”，其实只是 header 里多写了 charset=iso-8859-1，而我们的 TextDecoder 忽略了 response header 的 charset 声明，硬解。

文章配图，仅供参考

　　外卖到了没人去拿，塑料袋在门口堆成一小滩油渍。我最后改的不是代码，是 Nginx 配置：在 search.xxx.com 的 upstream 里加了 `proxy_hide_header Content-Type`，再加 `add_header Content-Type "application/json; charset=utf-8"`。不是最优解，是唯一能绕过后端不肯改、浏览器不肯认、前端又不能动全局 TextDecoder 的路。上线后首屏还是转圈，但至少按钮点了有反应，控制台不红了，只是多了几条 warn：`[Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated`——因为热词兜底逻辑里，有个 sync XHR 被忘在某个 `beforeunload` 钩子里，为的是“关页面前把最后一次搜词发出去”。没人记得为什么当初要同步发，只记得上线前 QA 报过这 warn，开发说“不影响功能”，产品说“老板要看数据，必须发”，于是它活到了十一。

　　我现在每天早上开电脑第一件事：进 Chrome DevTools > Network tab，Filter 里输 `suggest`，勾上 `Disable cache`，手动刷新三次，看第三次有没有缓存穿透——不是为了性能，是为了确认那三条请求头真的一致：`X-Request-ID`、`X-Trace-ID`、`X-App-Version`。如果其中任一个缺了，我就得翻最近一次 git commit，找到那天夜里谁提交了 `feat(search): add retry logic`，commit message 里写着 “fix request headers”，实际 diff 里只加了 retry，header 修复藏在另一行注释里：“// TODO: 修 header，等后端统一字段”——这条注释还在，两年了。

　　下一步？我把 `suggestionList` 的类型校验从运行时 assert 提前到构建时，用一个 `.d.ts` 文件强声明 shape，再加个 CI step：用 ts-morph 读这个 d.ts，匹配所有 fetch 返回处的 `.then(res => res.json())` 调用链，没匹配上的就 fail。不解决根本问题，但至少下次产品经理再问“为啥搜不到热词”，我能打开终端，cat 出那一行 fail log，指着说：“你看，这不是前端漏处理，是 schema 声明和接口现实对不上，现在它已经卡在 CI 里了，你得找后端先 fix schema。”

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!