支付对接：路径对了，门才开得了#

生产环境点充值，返回一截「路径无效」类错误。直觉会去查金额、商户配置、回调地址。我们顺着日志看完整请求，发现更简单——请求根本没打到支付函数那扇门上。

怎么引发的#

中间层用的是云厂商常见的「HTTP 触发 / 网关转发」模式。业务侧拼 URL 时，基址和路径可以有两种合法组合：

• 基址已经指向具体函数入口时，后面不应再拼一套业务 path；
• 基址只是通用服务域名时，才需要带上函数认识的 path。

我们当时把「看起来像环境域名」的地址当成了支付入口，再拼业务 path。网关侧找不到对应转发规则，就统一回路径错误。函数其实在，换一种入口探测，会变成缺凭证而不是找不到路径——说明门牌和钥匙是两件事。

怎么排查、怎么改#

排查顺序后来固定成三条，以后也打算照此执行：

1. 打日志或临时探测，确认实际请求的完整 URL（不要只看本地示例配置）。
2. 用「空路径 / 错误函数名 / 正确入口」对比响应：是找不到路由，还是缺鉴权，还是业务拒绝。
3. 代码里区分「网关函数入口」和「Express 风格子路径」：前者不再二次拼接；密钥只放服务端环境，不进前端、不进仓库正文。

文档和检查清单同步改了表述：写清推荐入口形态，避免后人再抄错基址。密钥本身仍只在部署环境注入——文章里也不会出现任何真实地址或令牌。

顺便记住的边界#

支付通道「配置齐了」和「用户能付成」之间，还隔着回调验签、幂等入账、前端轮询等。这次故障停在更上游：门都没敲对。以后再遇到笼统的 404 / 路径类错误，先问「敲的是哪扇门」，再问「门后的生意成不成」。