IP Insight 开发手记：多源检测是怎么拼起来的 IP Insight Dev Notes: How Multi-Source Detection Comes Together
第一版很糙：一个窗口，一个按钮，一个结果区。点击检测后，用 `Promise.all` 同时请求三个 API，哪个先回来先显示。代码不到 200 行。 The first version was rough: one window, one button, one result area.Click detect, fire three APIs with `Promise.all`, display whichever returns first. Under 200 lines of code.
IP Insight 开发手记：多源检测是怎么拼起来的
第一次实现 / 技术选择 / 踩过的坑
第一次实现
第一版很糙：一个窗口，一个按钮，一个结果区。
点击检测后，用 Promise.all 同时请求三个 API，哪个先回来先显示。代码不到 200 行。
但问题马上来了：三个源返回的字段格式各不相同。ip-api 给 countryCode，ipinfo 给 country，归属地一个写 "United States"，一个写 "US"。直接展示就是一团乱。
统一数据模型
解法是定义一个统一的 IPInfo 接口：
0
每个 API 写一个 adapter，把各自的格式转成统一结构。新增数据源时，只需要加一个 adapter，不碰核心逻辑。
踩过的坑
坑 1：超时没处理
一开始没设超时，某个 API 挂了，整个检测就卡住。后来每个请求独立设 8 秒超时，超时的源标记为"不可用"，不阻塞其他结果。
坑 2：并发打爆
Promise.all 同时打 5 个 API 没问题，但加上重试逻辑后，弱网环境下会雪崩。改成带并发限制的队列，一批 3 个。
坑 3：Electron 主进程 vs 渲染进程
网络请求放哪？放渲染进程简单，但 CORS 是个麻烦。最后统一走主进程的 net 模块，渲染进程通过 IPC 拿结果。顺便把 API Key 也藏在了主进程。
中间修改
v0.2.0 加了自动更新。用 electron-updater + GitHub Releases，后台静默下载，用户点一下就更新。
v0.3.0 做了中英双语。567 个 key 的字典，界面样式一点没动——这是铁律。
根据项目记录整理。部分细节待补充。
IP Insight 开发手记：多源检测是怎么拼起来的
第一次实现 / 技术选择 / 踩过的坑
第一次实现
第一版很糙：一个窗口，一个按钮，一个结果区。
点击检测后，用 Promise.all 同时请求三个 API，哪个先回来先显示。代码不到 200 行。
但问题马上来了：三个源返回的字段格式各不相同。ip-api 给 countryCode，ipinfo 给 country，归属地一个写 "United States"，一个写 "US"。直接展示就是一团乱。
统一数据模型
解法是定义一个统一的 IPInfo 接口：
0
每个 API 写一个 adapter，把各自的格式转成统一结构。新增数据源时，只需要加一个 adapter，不碰核心逻辑。
踩过的坑
坑 1：超时没处理
一开始没设超时，某个 API 挂了，整个检测就卡住。后来每个请求独立设 8 秒超时，超时的源标记为"不可用"，不阻塞其他结果。
坑 2：并发打爆
Promise.all 同时打 5 个 API 没问题，但加上重试逻辑后，弱网环境下会雪崩。改成带并发限制的队列，一批 3 个。
坑 3：Electron 主进程 vs 渲染进程
网络请求放哪？放渲染进程简单，但 CORS 是个麻烦。最后统一走主进程的 net 模块，渲染进程通过 IPC 拿结果。顺便把 API Key 也藏在了主进程。
中间修改
v0.2.0 加了自动更新。用 electron-updater + GitHub Releases，后台静默下载，用户点一下就更新。
v0.3.0 做了中英双语。567 个 key 的字典，界面样式一点没动——这是铁律。
根据项目记录整理。部分细节待补充。