采集用 Python，为什么后端选 Fastify，不统一成 Python？

标准回答

采集和离线处理与在线 API 是不同工作负载：前者需要数据处理和抓取生态，后者组织请求、鉴权、缓存与搜索调用。这个职责分工可以支持双栈，但语言选择仍要结合当时熟悉度和维护成本。Python 也能承担在线服务，不能用绝对性能论断替代真实理由。

即使把接口框架换快，若一次搜索主要耗在 ES 查询或缓存穿透上，整体响应也未必明显改善。优化应针对实测热点。

**说明在线请求花在哪里：**若大部分时间等待 Elasticsearch 或其他 I/O，瓶颈可能不在路由框架。先看链路耗时，再讨论语言和框架。

**解释边界契约：**两边通过数据结构、存储或明确接口衔接，字段与错误约定需要一致。简历没有说明具体通信方式，应补齐实现。

**承认双栈成本：**构建、依赖、监控和排错都增加工作；如果今天重做，应根据团队与产品规模重新评估是否还值得，而非机械重复当时选择。

事件循环中的重计算会影响其他请求，应按实际方案拆分或移出；异步 I/O 不会自动加速 CPU 计算。

框架支持 schema 校验等能力，但需说明项目实际用了哪些；不要把框架默认支持当作已经启用。

不要声称 Fastify 在任何业务里都比 Python 快，也不要把 Python 说成只能用于采集。