内容摘要：上周帮朋友改一个活动落地页，纯静态 HTML，托管在 GitHub Pages 上。他提了个需求：用户在手机浏览器里点“立即参与”，得直接跳到微信小程序，别让用户再手动搜。我第一反应是——这事没那么简

上周帮朋友改一个活动落地页，静态纯静态 HTML，网站托管在 GitHub Pages 上。小程序他提了个需求：用户在手机浏览器里点“立即参与”，静态得直接跳到微信小程序，网站别让用户再手动搜。小程序我第一反应是静态——这事没那么简单。

静态页面没有后端，网站没法动态生成 URL Scheme，小程序也没法调用服务端接口拿 access_token。静态微信官方那套“获取 URL Scheme”的网站接口，必须用服务端凭证去换。小程序静态站天然缺这一环。静态但需求摆在那，网站总得想办法。小程序

先搞清楚微信允许什么

微信开放标签 wx-open-launch-weapp 是官方给 H5 跳小程序留的口子。前提条件不少：域名要备案、要绑定公众号、要引入 JSSDK、要做签名校验。签名这一步又绕回服务端——需要 jsapi_ticket，而 ticket 得用公众号的 access_token 去换。静态站还是卡在这。

我试过用云函数做中转。腾讯云、Vercel、Cloudflare Workers 都行。把签名逻辑塞进一个无服务器函数，静态页调用它拿配置，再初始化 JSSDK。这方案能跑通，但多了个依赖，部署链路变长。朋友那个项目就一个页面，为这单独搭个函数，有点重。

退一步：URL Scheme 的静态化思路

另一个路子是 URL Scheme。格式类似 weixin://dl/business/?t=xxx，在手机浏览器里点开就能唤起微信并打开指定小程序。问题在于那个 t 值——它对应的是服务端生成的 scheme code，有效期最长 30 天。静态站没法实时生成，但可以预生成一批，写死在页面里轮流用。

我实际测过：生成 100 个 scheme，每个有效期 30 天，按天轮换。页面加载时用 JS 随机取一个，用户点击就跳。这办法土，但能用。缺点是 scheme 数量有限，高并发场景下可能被微信限流。朋友的活动页日活撑死几百，完全够。

还有个细节：URL Scheme 在 iOS 和 Android 上的表现不一样。iOS 上如果微信没装，会直接报错；Android 上部分浏览器会拦截。得加个兜底——检测 navigator.userAgent，非微信环境才显示跳转按钮，微信内直接引导用户长按识别小程序码。

小程序码是个笨办法，但稳

静态站最稳的方案其实是放小程序码。用户长按识别，或者截图后用微信扫一扫。体验上多一步，但零依赖、零签名、零后端。我见过不少活动页就这么干，转化率没比直接跳转低多少。用户被教育这么多年，长按识别已经成肌肉记忆了。

如果非要在静态站里做“一键跳转”，我的建议是：能用云函数就用云函数，别硬扛。静态站的“静”是优势，但碰到微信生态的鉴权体系，该加中间层就加。纯静态跳小程序，本质上是在跟微信的安全模型对抗，能绕过去的路子都带着点将就。

朋友最后选了云函数方案。一个 20 行的 Node.js 脚本，部署在 Vercel 上，免费额度足够。页面里嵌一段 JS，异步拿签名，再渲染开放标签。用户点按钮，微信直接拉起小程序，整个过程不到 1 秒。他满意了，我也松了口气——这活儿要是硬用纯静态做，得写多少 hack。

所以，静态站跳小程序，技术上可行，但别指望“纯静态”。要么接受小程序码的笨办法，要么加个轻量后端。中间路线也有，比如预生成 scheme 轮换，适合低并发场景。选哪条，看你对“静态”这两个字的执念有多深。