这个周四，Cocoro 做的稍微顺手了一点（其实是因为没有大量的异步查询了）。毕竟相较以往，没踩过的坑都踩过了不少，再踩到它也就不至于弄湿衣服了！
晚上和 @Innei 开始了一场热闹的讨论，有关于前端 API 请求器的封装。主要原因是我在微信小程序端是没有任何封装的，直接使用 wx.request 搞的，U1S1，确实有点傻。而他想打造一个通用方案，能跑在 NodeJS / 浏览器 甚至小程序上。
其中他就和我抱怨说 URLSearchParams 这个 API 不能在小程序环境上执行，很 🐶 币，感觉他恨不得弄出一套好用的库来用。相反我却是非常佛性，因为我接触过的项目，就使用过不同类型不同级别的封装程度，就压根没有一个统一的标准。
关于这个问题，我甚至还推理出了一套优劣，接下来也会弄成一篇文章发布，敬请期待吧！
他还给我看了一个大量 TS 重载的代码，我执意的说我现在写过的代码就没有什么场景用到它。然后他分享给我了一个很好的使用情形，根据不同 type 传入函数（文章/说说），返回不同 TS 类型定义的内容（文章接口包含什么，说说接口包含什么）。
search( type: 'note', keyword: string, options?: Omit<SearchOption, 'rawAlgolia'> ): Promise<RequestProxyResult<PaginateResult<Pick<NoteModel, 'modified' | 'id' | 'title' | 'created' | 'nid' >>>>
search( type: 'post', keyword: string, options?: Omit<SearchOption, 'rawAlgolia'> ): Promise<RequestProxyResult<PaginateResult<Pick<PostModel, 'modified' | 'id' | 'title' | 'created' | 'slug' | 'category' >>>>我压根没想过这样的封装，现在依旧使用着 TypeScript 最基础的类型检测和异常预判。他这样的场景，我往往会将它们（文章/说说）分离，形成独立的函数进行返回，并分别指定其返回的类型...
