「H5」标签下共 11 篇技术文章，包括《微信小程序与 H5 调用第三方 API 的正确姿势：把平台差》、《微信小程序与 H5 调用第三方 API：先定密钥归属，再选直》、《微信小程序与 H5 调用第三方 API：白名单、CORS 与》。按发布时间倒序排列，内容持续更新。
业务代码应只依赖统一的内部请求契约，由薄适配层吸收小程序请求域名配置与 H5 CORS 等平台差异；长期密钥不进入前端，超时、错误映射和幂等重试在上线前统一定义。具体平台规则与 API.PLUS 接入参数需以官方文档为准。
小程序不走浏览器同源策略，卡点在后台配置的 request 合法域名与 HTTPS；H5 受浏览器 CORS 约束。两者共同的决定因素是密钥放在哪一侧：凡涉及 AppSecret 或长期 API Key，就应走自有服务端代理，而不是…
小程序和 H5 调用第三方 API 的正确做法是先确认两条运行时各自的约束：小程序侧受 request 合法域名限制，H5 侧受同源策略与 CORS 预检限制；两者都应经过自有后端或边缘函数转发，避免把长期密钥放到前端。文章给出代理…
正文结论：除非接口完全公开且无凭据风险，小程序与 H5 不应在前端直接持有第三方 API 密钥；更稳妥的是前端调用自有后端，由后端完成鉴权、转发、限流与日志脱敏。小程序合法域名和 H5 跨域要求需以平台文档核实。
正确做法不是在页面里直接请求第三方接口，而是拆成三段：不可信的前端、持有密钥的服务端代理、以及上游 API。小程序受平台合法域名约束，H5 受同源策略约束，两者都因为代理而简化；真正决定可用性的，是显式超时、只对幂等请求重试、把错误…
正确姿势是先判断接口是否含密钥与配额要求：公开无密钥接口才评估前端直连，涉及密钥的调用统一走自己的后端代理；小程序重点检查合法域名，H5 重点处理 CORS，并统一超时、错误与重试边界。
调用第三方 API 的关键不只是前端怎么写请求，更在于把长期密钥放在服务端、明确小程序与 H5 各自的网络约束，并为超时、重试、缓存和错误码建立契约。无法确认第三方是否支持浏览器直连时，优先采用自有网关中转。
客户端不应直接持有第三方 API 密钥，推荐由自有后端做转发与鉴权；小程序与 H5 的差异集中在请求域名配置和跨域机制上，调用逻辑本身可以共用一套契约。本文只给出与平台无关的结构建议，未提供平台文档素材，具体限制需按各平台当前文档核…
小程序和 H5 都不该直接持有第三方 API 密钥。可行做法是让前端只调用自有后端，由后端保存凭证、转发请求并统一处理错误与限流。小程序需要在后台配置 request 合法域名，H5 受浏览器同源策略与第三方 CORS 响应头约束；…
共 11 篇文章，第 1 / 2 页