避免 Web Hook 中复杂的“解密与序列化”重复操作
飞书 Web Hook 为保障安全，所有事件推送均经过加密传输（如基于 AES 的数据加密、签名验证），这意味着每次接收事件时，都需要重复执行以下流程：
- 从请求头提取签名、加密数据；
- 调用飞书 SDK 或自定义逻辑进行解密；
- 将解密后的字符串反序列化为结构化数据（如 JSON），再提取审批 ID、表单参数等核心信息。
而飞书长链接模式（如飞书开放平台的“长轮询接口”或基于 WebSocket 的事件推送），仅需在链接初始化时完成一次身份认证与加密握手，后续所有事件均通过已建立的长链接直接推送结构化数据（无需重复解密、反序列化）。
对项目而言，这能省去大量重复的加密处理代码，减少因解密逻辑异常（如密钥过期、签名校验失败）导致的事件丢失，降低代码维护成本。
减少“服务端暴露与网络配置”成本
Web Hook 依赖“飞书服务器主动向你的服务端 URL 推送请求”，这意味着需要：
- 将服务端接口暴露到公网（或配置飞书 IP 白名单，确保飞书能访问）；
- 处理网络层异常（如防火墙拦截、公网带宽波动导致的请求丢失）；
- 若服务部署在私有网络（如公司内网），还需配置 NAT 映射、反向代理等，确保飞书能穿透内网访问。
长链接则是“你的服务端主动向飞书服务器发起连接”，属于** outbound 连接**（无需暴露公网接口）：
- 只需服务端能访问飞书开放平台的公网地址（通常公司内网默认允许 outbound 访问），无需任何网络穿透或公网暴露配置；
- 连接稳定性由飞书服务器保障（如断连后自动重连机制），无需担心防火墙拦截、IP 白名单维护等问题。
对项目而言，这能省去网络架构调整的成本，尤其适合“开发环境服务未暴露公网”的场景，降低部署复杂度。