批量调用能省掉往返开销，却处理不了"用上一个结果做下一次输入"的依赖关系

把多个独立的API调用打包成一次批量请求，可以省掉重复的网络往返开销，但这种优化有个硬伤：批量里的每个调用必须互相独立，一旦某个调用需要用另一个调用的结果作为输入（比如先取朋友列表，再用这份列表去查每个朋友的信息），批量机制就完全无能为力，因为客户端发出请求那一刻，前一个调用的结果根本还不存在。Facebook的解法不是继续在批量机制上打补丁，而是干脆引入一种类SQL的查询语言（FQL），把”先查A、再用A的结果查B”这种组合逻辑整个下推到服务端一次性完成。这提示一个判断问题本质的方法：当一个优化方案在某类场景下总是”差一口气”，可能不是这个方案没做好，而是它从根子上就不适合处理这一类需求，需要换一层抽象来解决。