Facebook Messenger Platform：Webhook多事件与entry数组多对象场景问询

让我来拆解这两个问题，都是Messenger Webhook开发中容易踩坑的细节点：

Messenger平台会在以下几种情况下把多个事件打包进同一个Webhook请求：

• 积压事件批量推送：如果你的Webhook服务之前因为故障、延迟或者网络问题无法接收事件，平台会在服务恢复正常后，把积压的所有未推送事件合并成一个或多个请求发送，避免频繁发起HTTP请求。
• 同一用户的连续快速交互：当用户在极短时间内触发多个动作时——比如连续发送3条消息、快速点击消息模板里的多个按钮，平台会把这些连续的事件合并到一个请求里，而不是每条事件单独发请求。
• 多类型事件同时触发：有时候用户的一个操作会同时触发多种事件，比如用户发送消息的同时，系统触发了message_read事件（标记消息已读），或者用户关注页面后同时触发了messaging_optins事件和欢迎消息的messages事件，这些关联事件会被打包到同一个请求中。
• 多用户并发交互：如果多个用户在同一时间窗口内和你的页面/应用交互，平台会把这些来自不同用户的事件合并到一个请求里，以此优化请求数量和传输效率。

entry数组的每个对象对应一个Facebook Page的事件集合，出现多个entry对象的核心场景是：

• Webhook订阅了多个Facebook Page：如果你的应用关联了多个Facebook页面，并且所有页面都配置了同一个Webhook端点，那么当这些页面各自有事件触发时，平台会把每个页面的事件封装成独立的entry对象，合并到同一个请求中发送。比如页面A有用户发消息，页面B有用户触发postback事件，这两个事件组就会分别放在两个entry对象里，组成entry数组。
• 同一页面的跨批次事件合并：在极少数情况下，如果同一页面有两批完全独立的积压事件（比如间隔时间较长的两次事件积压），平台也可能会把它们拆分成不同的entry对象打包进同一个请求，但这种情况比较少见，最常见的还是多页面订阅的场景。

补充一句：官方文档里示例大多用单个entry，是为了简化说明，但实际开发中一定要记得遍历entry数组，不然会漏掉多页面或者多批次的事件。

内容的提问来源于stack exchange，提问作者Lee He