ThinkPHP如何对接企业微信_API接口认证与消息推送【教程】-ThinkPHP-PHP中文网

thinkphp对接企业微信客服消息的核心难点是鉴权分离与消息发送的强约束条件：必须区分使用access_token（管理类接口）和kf_access_token（客服接口），且/kf/send_msg需满足用户48小时窗口、5条/48h配额、external_userid、open_kfid匹配及后台权限配置等多重条件。

thinkphp如何对接企业微信_api接口认证与消息推送【教程】

ThinkPHP 对接企业微信 API 的核心难点不在框架本身，而在于鉴权链路的时序控制和消息接口权限的精确匹配。直接套用 gettoken 示例代码大概率失败——因为企业微信要求：自建应用调用客户消息接口（如 /kf/send_msg）必须走「微信客服」专用鉴权体系，而非通用 /gettoken。

`access_token` 和 `kf_access_token` 必须区分使用

企业微信里有两个关键 token：

access_token：用于管理后台类接口（如获取用户列表、部门信息），由 corpid + corpsecret 申请
kf_access_token：仅用于微信客服相关接口（如 /kf/send_msg），必须用 corpid + kf_secret 获取，且需提前在管理后台「微信客服 → 接口调用配置」中启用对应应用

常见错误现象：

调用 /kf/send_msg 返回 {"errcode":40014,"errmsg":"invalid access_token"}
明明 gettoken 成功了，但发消息报错 48002（接口未授权）

正确做法：

在 ThinkPHP 的配置文件中独立维护两套凭证：

'weixin' => [
  'corpid' => 'wwxxxxxx',
  'corpsecret' => 'xxxxxxxx', // 通用 secret
  'kf_secret' => 'yyyyyyyy',  // 微信客服专用 secret
]

封装两个独立的 token 获取方法：getAccessToken() 和 getKfAccessToken()，各自缓存并校验有效期（7200 秒）
绝对禁止混用：向 /kf/send_msg 传 access_token

`/kf/send_msg` 接口必须满足用户状态与配额限制

这个接口不是“想发就发”，它受微信侧强策略管控：

用户必须处于以下任一状态：
- 刚刚给客服发过消息（48 小时窗口期内）
- 当前会话由智能助手接待中（需先调用 /kf/switch_session）
单个用户 48 小时内最多接收 5 条消息（含图文、小程序等所有类型）
touser 字段必须填微信客户的 external_userid，不是企业微信的 userid

实操建议：

微信公众号自动发布增强版

一键发布 Markdown/HTML 文章至微信公众号草稿箱，支持自动配图、排版美化、UTF‑8编码

下载

发送前务必查用户最近一次主动消息时间（可通过回调事件或 /kf/list_msg 拉取）
在数据库记录每条消息的 msgid 和发送时间，避免超限重试
若需突破 5 条限制，只能引导用户再次发起对话（例如回复关键词“人工”）

示例请求体（ThinkPHP 中构造）：

$data = [
  'touser' => $external_userid,
  'open_kfid' => 'wk_xxxxxx', // 客服账号 ID，非应用 ID
  'msgtype' => 'text',
  'text' => ['content' => '订单已发货，请注意查收'],
];

注意：open_kfid 必须和申请 kf_access_token 的客服账号一致，否则返回 48003。

ThinkPHP 缓存 token 时必须隔离存储与原子更新

access_token 和 kf_access_token 都有 2 小时有效期，但刷新时机不同、失败影响面也不同：

通用 access_token 失效会导致整个组织架构同步中断
kf_access_token 失效只影响客服消息，但高频刷新可能触发限流（企业微信对 /gettoken 类接口有 2000 次/天限制）

推荐做法：

使用 ThinkPHP 的 Cache::store('redis') 分别存两个 key： weixin:access_token 和 weixin:kf_access_token
获取 token 时加锁（Cache::lock('weixin:token_lock', 10)），防止并发重复刷新
刷新失败时保留旧 token 并记录日志，而不是抛异常中断业务

容易踩的坑：