飞书审批API调用必须使用tenant_access_token，有效期2小时需缓存并自动刷新；事件订阅需公网HTTPS回调、严格验签；审批事件字段嵌套深，applicant.user_id实为open_id；回调须3秒内响应且幂等处理。
飞书审批 API 调用必须先拿到 tenant_access_token
飞书所有服务端 API（包括审批流提交、查询、撤回）都不接受 app_access_token 或用户 token，只认 tenant_access_token。它有效期 2 小时，需缓存并自动刷新——很多人卡在第一步，调 https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal/ 返回 {"code":10005,"msg":"Invalid app_id or app_secret"}，八成是 app_id 和 app_secret 拿错了位置（控制台「企业自建应用」页里有两个字段：App ID 和 App Secret，别和「开放平台」的搞混）。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用 PHP 的
cURL或Guzzle发 POST 请求，Content-Type: application/json，body 是{"app_id": "cli_xxx", "app_secret": "xxx"} - 把返回的
tenant_access_token存到 Redis 或本地文件，加锁防并发重复刷新 - 每次调审批 API 前检查缓存是否过期（比当前时间早 30 秒就刷新）
监听飞书审批事件得靠「事件订阅」+ 自建 HTTPS 回调地址
飞书不会主动推送事件到你服务器，而是 HTTP POST 到你配置的回调 URL。但这个 URL 必须是公网可访问的 HTTPS 地址（不支持 HTTP、localhost、内网 IP），且要通过飞书签名验证——没过验签，飞书会持续重试直到超时，日志里全是 400 或空响应。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- PHP 接收请求后，先从
$_SERVER['HTTP_X_LARK_SIGNATURE']和$_SERVER['HTTP_X_LARK_TIMESTAMP']取签名和时间戳 - 用
hash_hmac('sha256', $timestamp.$body, $app_secret)算签名，和 header 里的比对（注意：body 是原始 raw data，不是$_POST） - 验签通过再
json_decode(file_get_contents('php://input'), true)解析事件体，event.type为approval_instance_status_changed_v4才是审批状态变更
approval_instance_status_changed_v4 事件里关键字段容易误读
事件体嵌套深、字段命名不直观，比如审批通过不叫 approved，而是在 event.approval_instance.status 里，值是 approved 或 rejected；更坑的是，申请人信息藏在 event.approval_instance.applicant.user_id，但这个 user_id 是飞书的 open_id，不是 user_id（除非你开通了「获取用户 ID 权限」并调 user.internal.get 换）。直接拿它查自己数据库，大概率查不到人。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 优先用
event.approval_instance.applicant.open_id做关联，它稳定且无需额外权限 -
event.approval_instance.approval_nodes是审批节点数组，每个节点有status（approved/rejected/pending），别只看根节点 - 如果需要真实姓名或手机号，必须提前在应用权限里勾选「通讯录」，再用
user.internal.get查，别指望事件体自带
PHP 处理飞书回调必须设好超时和幂等性
飞书要求回调响应必须在 3 秒内返回 200 OK，否则视为失败重发；而且同一事件可能多次投递（网络抖动、超时等），没做幂等处理会导致重复审批入库、重复发通知。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- PHP 脚本开头加
set_time_limit(2)，避免慢查询拖死响应 - 用事件里的
event.uuid当唯一键，写入 MySQL 或 Redis 做“已处理”标记（带过期时间，比如 1 小时） - 不要在回调里直接执行耗时操作（如发邮件、调第三方 API），改成写队列（Redis List + Worker）异步处理
飞书事件结构松散、验签逻辑硬、token 管理琐碎——这些地方不抠细节，跑通一次容易，长期稳定很难。
