微信小程序前端无法直调 create_room 或支付接口，因需服务端 access_token 或签名凭证，而小程序无法安全生成和管理；ThinkPHP6 需手动透传语言、严格路径加载语言包、Session 绑定；V3 支付签名失败主因是 body 格式、timestamp、私钥路径不合规；access_token 必须用 Redis 缓存并加锁刷新。
微信小程序后端接口不能直接用前端调用微信官方接口，所有涉及用户身份、支付、直播、消息推送等能力的接口，都必须由 ThinkPHP 后端代为调用 —— 因为这些接口强制要求 access_token 或签名凭证，且需服务端安全管控。
为什么小程序 wx.request 不能直接调 create_room 或 pay/unifiedorder
微信的 /wxa/business/create_room、/v3/pay/transactions/jsapi 等接口全部校验服务端凭证：access_token（平台级）或 Authorization 头（V3 支付）。小程序发起的请求无法携带有效 access_token，强行拼 URL 会稳定返回：
{"errcode":40001,"errmsg":"invalid credential, access_token is invalid or not latest"}-
{"code":"INVALID_SIGNATURE","message":"The signature is invalid."}（V3 支付）
根本原因不是跨域或 header 限制，而是微信设计上就禁止前端直连——token 有效期仅 2 小时、需私钥签名、证书路径不可暴露，这些都无法在小程序 JS 层安全实现。
ThinkPHP6 中必须手动透传语言偏好（LANG_AUTO_DETECT 失效）
小程序请求不带 HTTP_ACCEPT_LANGUAGE，也不自动发送 Cookie，所以 ThinkPHP 默认的多语言自动检测机制完全不生效。你不能依赖 Lang::detect()，必须显式控制。
立即学习“PHP免费学习笔记（深入）”；
- 小程序每次请求带上 header：
X-Language: zh-cn或 query：?lang=zh-cn - 在中间件中读取并设置：
\think\Lang::setLang($request->header('X-Language', 'zh-cn')) - 语言包路径必须严格为
lang/zh-cn/common.php，文件内必须return [...]，不能有输出 - Session 绑定更稳妥：首次设置后存入
$request->session('lang', $lang)，后续直接读 session，避免前端漏传
支付 V3 接口签名失败的三个高频原因
ThinkPHP6 集成微信支付 V3 最常卡在签名环节，错误表现为 INVALID_SIGNATURE 或 HTTP 401。不是算法写错，而是细节没对齐：
-
body必须是原始 JSON 字符串（非 PHP 数组），且不能有空格或换行；建议用json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) -
timestamp必须是当前秒级时间戳（time()），不是毫秒；且需和请求头WECHATPAY-TIMESTAMP完全一致 - 私钥路径必须是绝对路径，且 PHP 进程有读取权限；推荐用
app()->getRootPath() . 'cert/apiclient_key.pem'，别用相对路径或__DIR__
access_token 缓存必须用 Redis，不能靠文件或内存
微信平台级 access_token 是全局共享凭证，多台服务器部署时若用文件缓存，会出现 token 覆盖、过期不一致、并发刷新冲突等问题。
- 缓存 key 建议固定为
wechat:live:access_token（直播）或wechat:pay:access_token（支付） - 过期时间设为 7000 秒（2 小时减 200 秒缓冲），避免刚失效就触发重拉
- 刷新逻辑必须加锁：先
setnx尝试占位，成功再发请求，失败则 sleep 后重试，防止雪崩 - 永远不要把
access_token存进 Session 或 Cookie —— 它不属于用户态，而是服务端凭据
最易被忽略的是：微信所有业务接口（直播、支付、客服消息、模板消息）都强依赖同一套 access_token 生命周期管理逻辑。写一次健壮的获取+缓存+刷新封装，比在每个控制器里重复写 cURL 更省事，也更安全。
