给外包客户的搜索框接上 Places API，被计费单教育了

客户是个做本地家政的小程序，搜索框要能输入小区名自动补全。我第一反应是 Places Autocomplete，文档看着挺顺，加上 session token 就能按会话计费。我拉了个测试环境，Places API 版本是当时控制台默认给的那版，量级也不大，一天几百次请求，感觉闭着眼都能过。

做法其实很朴素。前端每次输入先 debounce 400ms，然后带着一个 session token 请求后端，后端再转发给 Places。session token 用 uuid 生成，一个输入会话一把，用户选中某条结果或停止输入 3 分钟后换新的。请求片段大概长这样：

const token = crypto.randomUUID();
const url = new URL('https://maps.googleapis.com/maps/api/place/autocomplete/json');
url.searchParams.set('input', keyword);
url.searchParams.set('components', 'country:cn');
url.searchParams.set('sessiontoken', token);
url.searchParams.set('key', process.env.PLACES_KEY);

我本来以为只要 session token 带上就按会话算钱，结果第一周账单出来，Autocomplete 的请求量是会话数的三倍多。翻日志才明白，我 debounce 之后每次请求都换了新 token——因为我把 token 生成写在了请求函数里，用户每敲一个字就是一次“新会话”，等于白送钱。改成在输入框 focus 时生成、选中结果时销毁，账单这才降下来。啊这，纯纯自己给自己加戏。

为什么强调这个：Places 的计费单位是 session，不是请求次数。一次 session 里你调多少次 Autocomplete 都算一次，但前提是 token 得是同一个。代价是前端状态变复杂了，得管 token 的生命周期，还得处理用户中途关页面、切后台的情况，不然 session 会一直挂着。

失效的地方我也踩过：用户粘贴一长串地址时，oninput 只触发一次，debounce 没意义，反而会把整串直接扔给接口，返回一堆不相关结果；还有中文小区名带“号院”“二期”这种后缀，Autocomplete 经常给不出结果，得改走 Geocoding 或者自己维护一份小区词表。另外客户后来想加“按距离排序”，Places 那版返回里没带坐标，只能再补一次 Place Details，又是一笔钱。

现在这个搜索框算是能用了，但每次看到计费面板我心里还是发虚。想问问做本地生活类搜索的朋友：你们是硬扛 Places 的 session 计费，还是干脆自己爬/买一份 POI 词表做前缀匹配？后者的维护成本到底压不压得住？