企业官网建设流程全解析

从前端到端讲清楚吧。上个月刚给公司的营销活动页做完微信分享配置，过程中踩了不少坑，也把网上那些不够清晰的文档挨个对照过一遍。这篇就直接从零开始，把H5页面调用微信JS-SDK做分享配置的完整链路讲透，包括微信公众平台怎么配置、后端签名怎么做、前端怎么调用、以及最折磨人的签名校验问题。不管你是第一次接触还是已经配过但被各种报错卡住，这篇应该都能帮到你。

1. 微信分享配置的底层逻辑：为什么H5默认分享那么“丑”

1.1 直接分享H5链接时微信默认行为

先想一个问题：一个普通的H5页面，在微信里打开后点击右上角菜单分享给好友，会是什么效果？

默认情况下，微信只会抓取页面<title>标签里的文字作为分享标题，缩略图则完全随机，有时候能抓到页面里某张图片，有时候干脆就是灰色图标。分享描述这个字段更是无从谈起，连设置入口都没有。这也就意味着，你的活动页、商城页、内容页在微信里被分享出去时，呈现的效果完全不可控，会直接影响点击率。

我之前做过一个抽奖活动的页面，title写得不够吸引人，分享出去之后打开率特别低。后来接入了微信JS-SDK，把分享标题改成“限量1000份奖品，点击即抽”，缩略图也换成了带活动主视觉的图，同样一个链接，分享出去的打开率直接翻了接近两倍。这说明了分享配置在微信生态里的重要性，往大了说它决定了一个H5活动的传播效率。

1.2 JS-SDK在分享链路中的角色

微信JS-SDK在分享链路中的作用，简单说就是让你的页面在微信内置浏览器中运行时有权限调用微信原生能力。微信对H5页面的权限管理挡在中间层，页面必须先通过wx.config完成签名校验，证明“这个页面来自配置过JS接口安全域名的真实站点”，之后才能调用分享等能力。

注意区分两个概念：JS-SDK不是H5页面直接拿来用的工具库，它是一把“钥匙”。不带钥匙直接裸调wx.updateAppMessageShareData拿到的只会是“permission denied”之类的报错。所以整个配置流程可以拆成：微信公众平台配置域名 -> 后端生成签名 -> 前端引入SDK并初始化 -> 调用分享接口设置分享信息。四个环节缺一不可。

1.3 适用场景和边界

这套方案也有明确的适用范围。只有通过微信内置浏览器（微信内置WebView）打开的H5页面才能使用JS-SDK的分享接口；在外部浏览器、App内嵌WebView里，JS-SDK是走不通的。另有几种特殊场景，比如企业微信内部、微信小程序内嵌H5，配置逻辑在某些参数上也会有所差异，不过主流程是一致的。

2. 开始前必须先做好的账号侧配置

2.1 注册/认证服务号并获取AppID与AppSecret

微信JS-SDK的接口能力仅对认证过的服务号开放。如果是未认证的订阅号，基本可以绕过这个方案了，因为根本没有权限拿到接口能力。

具体获取方式：登录微信公众平台 -> 开发 -> 基本配置 -> 可以看到AppID（应用ID）和AppSecret（应用密钥）。AppID相当于账号身份证号，AppSecret相当于密码，前者前端可以明文出现，后者按微信安全规范要求必须保存在服务端，严禁嵌入前端代码里。

实验环境做联调时，可以用测试号先跑通流程。申请测试号也比较简单，直接在微信公众平台接口测试号页面扫码即可创建，测试号会自动分配AppID和AppSecret，还免去了认证门槛，适合前期验证签名算法和前端流程。

2.2 JS接口安全域名的坑：域名、路径与协议

这一步是“一步错步步错”的重灾区，而且微信公众平台修改配置后生效有延迟。

进入公众平台 -> 设置与开发 -> 公众号设置 -> 功能设置 -> JS接口安全域名，这里填写的域名有几个硬性要求：

• 可以填域名根，不用带路径和协议，比如正确填法是example.com，填https://example.com/page.html或https://example.com都算格式错误；
• 必须ICP备案过且和公众号主体有直接关联的域名，否则会在保存时被拒绝；
• 域名校验文件（txt文件）要放在域名根目录下可直接访问的位置。校验文件的下载和放置方式在配置页有明确指引，需要注意访问路径是https://example.com/校验文件名.txt能直接打开才算有效；
• 一个服务号最多可配置的JS接口安全域名数量有限（通常是5个），超出部分需要缩减或更换子域名配置。

我曾经因为校验文件放错目录，一直报“域名校验失败”，排查了接近半小时才发现文件被放到了子目录/static/下，而不是根目录。建议你在配置前先确认根目录能否访问到校验文件，再点击保存按钮。

2.3 测试环境如何复用线上域名绕过IP限制

有一个比较现实的问题是：本地开发时的地址是localhost或局域网IP，和线上域名对不上，签名校验必然失败。

处理常见做法是改本机hosts文件，把线上域名example.com解析到127.0.0.1，本地通过https://example.com:8080访问项目，这样页面URL的域名和线上配置保持一致，签名能通过。

另一个做法是调试期间临时把线上环境的URL传参debug=true，直接通过浏览器开发者工具做远程调试。注意这种调试方式会有一定风险，上线前务必关闭。

我常用的方案是在开发环境引入eruda这个移动端调试工具，在页面加载后呼出控制台查看日志和网络请求。它在微信内置浏览器里的表现类似PC端DevTools，排查wx.config报错非常方便。

3. 后端签名接口的实现：签出的参数必须和前端请求URL完全一致

3.1 获取access_token与jsapi_ticket的完整步骤

签名依赖的是jsapi_ticket，而jsapi_ticket的获取又依赖access_token。先说明两个凭证的区别：access_token是公众号的全局唯一接口调用凭据，有效期2小时；jsapi_ticket是JS-SDK临时票据，也是在生成签名时用来参与计算的，有效期7200秒。

获取流程分两步。

第一步，请求https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=APPID&secret=APPSECRET拿到access_token。

curl "https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=你的AppID&secret=你的AppSecret"

返回结果是一个JSON，其中access_token字段就是需要的东西，同时还有expires_in字段告诉你有效期。注意这里的AppSecret必须从服务端安全读取，绝不能出现在前端。

第二步，用拿到的access_token请求https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=ACCESS_TOKEN&type=jsapi获取jsapi_ticket。

curl "https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=上一步的access_token&type=jsapi"

这里有两个高频问题需要警惕：

• access_token和jsapi_ticket都必须做全局缓存，不能每次请求页面时都重新拉取。微信对这两个接口的频率限制很严格，超出限制会被封禁IP一段时间。建议的做法是用Redis或内存缓存，access_token缓存时长设为7000秒左右，jsapi_ticket设为7100秒左右，考虑到网络延迟和时钟偏差不要卡满7200秒精确时间。
• 获取access_token时有极小概率遇到“频繁调用”报错，这是因为公众号后台在其他地方也调用了该接口导致凭证冲突。如果确认没有别处在调用，等待几分钟再重试即可。

3.2 签名算法逐字段拆解

微信官方引入的签名算法整体来说是：将若干参数拼接为字符串，做SHA1加密，生成40位签名。看似简单，但很多人在这一步“翻车”，核心原因是参数没对齐。

签名需要的参数如下：

四者在URL键值对拼接时顺序jsapi_ticket=xxx&noncestr=xxx&timestamp=xxx&url=xxx，然后对这个字符串做SHA1。

需要特别注意的细节是url字段。微信要求“当前网页的URL，不包含#及其后面部分”。也就是说如果当前页面访问的是https://example.com/page?id=1#/home，参与签名的URL必须是https://example.com/page?id=1，要去掉hash。

但有个很容易被忽略的细节：页面URL的query参数部分必须原样保留。如果页面打开时带上了?from=wechat&channel=123，那么签名时必须用完整的https://example.com/page?from=wechat&channel=123。很多人取URL时偷懒只取了location.href.split('#')[0]，但忘了把query拼上，导致签名一直不通过。

以Node.js后端为例，签名接口的参考实现：

const crypto = require('crypto'); const axios = require('axios'); // 缓存变量 let cachedToken = null; let cachedTicket = null; async function getAccessToken(appid, secret) { if (cachedToken && cachedToken.expireAt > Date.now()) { return cachedToken.value; } const url = `https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=${appid}&secret=${secret}`; const res = await axios.get(url); if (res.data.access_token) { cachedToken = { value: res.data.access_token, expireAt: Date.now() + (res.data.expires_in - 200) * 1000 }; return cachedToken.value; } throw new Error(`获取access_token失败: ${JSON.stringify(res.data)}`); } async function getJsapiTicket(appid, secret) { if (cachedTicket && cachedTicket.expireAt > Date.now()) { return cachedTicket.value; } const token = await getAccessToken(appid, secret); const url = `https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=${token}&type=jsapi`; const res = await axios.get(url); if (res.data.ticket) { cachedTicket = { value: res.data.ticket, expireAt: Date.now() + (res.data.expires_in - 200) * 1000 }; return cachedTicket.value; } throw new Error(`获取jsapi_ticket失败: ${JSON.stringify(res.data)}`); } // 生成签名的接口调用入口 async function getSignature(reqUrl) { const appid = process.env.WECHAT_APPID; const secret = process.env.WECHAT_SECRET; const ticket = await getJsapiTicket(appid, secret); const nonceStr = Math.random().toString(36).substring(2, 16); const timestamp = Math.floor(Date.now() / 1000); const rawStr = `jsapi_ticket=${ticket}&noncestr=${nonceStr}&timestamp=${timestamp}&url=${reqUrl}`; const signature = crypto.createHash('sha1').update(rawStr).digest('hex'); return { appid, timestamp, nonceStr, signature }; }

注意上面代码里的缓存过期时间故意减掉了200秒，目的是避免缓存刚好在请求前后的临界点失效导致签名计算时ticket和微信服务器对不上。实际生产环境建议用Redis，多实例部署时内存缓存会存在不一致问题。

3.3 URL获取必须依赖前后端协作而非前端传值

最让人头疼的一个点：签名接口的url到底应该由前端传给后端，还是后端自己根据请求头获取？

网上有很多方案是前端把window.location.href.split('#')[0]传给后端，后端拿这个值去签名。这种做法容易出问题，因为前端在单页应用（SPA）中路由切换后，location.href会变化，如果传给后端去了一个过期地址，签名必然失败。

我采用的方案是：后端在接收到签名请求时，从请求头Referer或Origin字段中取得完整URL，去掉协议后取到域名和路径，再补上https://前缀，这样可以保证签名用的URL和微信实际打开的页面URL尽量一致。但前端传值也有它的必要性，特别是页面存在多层跳转时Referer可能丢，更稳的做法还是前端主动上报当前完整URL，后端只做二次校验。两者结合在开发中较为稳妥。

有条件的团队可以搭建一个内部签名服务，让多个业务线共用：前端请求签名时把页面URL作为POST参数带上，后端统一从数据库或缓存拿到ticket后返回签名结果。这样避免每个业务线各自实现一遍签名算法，也让签名参数的获取方式统一可控。

4. 前端引入JS-SDK与wx.config初始化

4.1 引入JS文件的最佳实践

微信官方提供的JS-SDK文件地址是https://res.wx.qq.com/open/js/jweixin-1.6.0.js。这里有两个选择：

• 直接通过script标签引入官方CDN；
• 下载到本地，作为静态资源放到自己的服务器上。

两种方案各有优劣。官方CDN的好处是加载速度快，国内访问稳定；缺点是如果微信内部版本升级导致接口不兼容，你无法及时觉察。本地引入的好处是可控性高，在部分隔离网络环境下也能保证资源加载成功，但需要自己做版本维护。我习惯的做法是下载到本地，并在发布前通过自动化脚本比对官方最新版本MD5，有新版本时人工评估是否升级。

在Vue或React项目中，也可以在index.html里直接用script标签引入，或者用npm包weixin-js-sdk安装后在代码中import wx from 'weixin-js-sdk'。npm包本质上是官方SDK的封装，使用上没有本质差异，主要看团队的技术栈习惯。如果你的项目是TypeScript，建议安装@types/weixin-js-sdk类型定义，能在编码阶段就发现参数名错误。

4.2 wx.config参数说明与常见报错定位

在页面加载后，先向后端拿签名参数，再调用wx.config：

import wx from 'weixin-js-sdk'; async function initWxSdk() { // 必须去掉hash const currentUrl = window.location.href.split('#')[0]; const res = await fetch(`/api/wechat/signature?url=${encodeURIComponent(currentUrl)}`); const data = await res.json(); wx.config({ debug: false, // 生产环境务必关闭 appId: data.appId, // 必填，公众号的唯一标识 timestamp: data.timestamp, // 签名时间戳 nonceStr: data.nonceStr, // 随机字符串 signature: data.signature, // 签名 jsApiList: [ 'updateAppMessageShareData', 'updateTimelineShareData', 'onMenuShareTimeline', 'onMenuShareAppMessage' ] // 需要使用的JS接口列表 }); wx.ready(() => { console.log('wx.config 配置成功'); // 这里再调用分享接口 }); wx.error((err) => { console.error('wx.config 配置失败', err); }); }

wx.config的几个参数标识说明如下：

• debug：调试开关。设为true时会弹出alert窗口显示校验结果。线上必须关掉，开发环境可以开着方便排查。
• jsApiList：声明你本次需要用到的JS接口列表。它不是随意填的，必须是微信官方JS-SDK支持的接口名。如果漏填了某个接口，调用时会报“invalid signature”或“permission denied”。

配置成功的标志是wx.ready回调被触发，配置失败则进入wx.error回调。在wx.error里拿到的err对象，常见的错误码含义如下：

排查这些错误有比较高效的方法：老版本微信官方推荐在wx.error回调里输出错误信息，但更直接的方式是先在wx.config那里开debug: true，然后逐项核对签名参数。我之前遇到“invalid signature”时，发现是后端签名时的URL带上了http://而页面实际请求的是https://，协议不同导致SHA1哈希结果完全不一样。

4.3 JS-SDK初始化时机与SPA路由切换问题

在SPA（单页应用）中有一个容易忽视的细节：wx.config只需要初始化一次，而且必须在页面加载早期完成。如果等到路由切换后才去初始化，那么签名URL就要对应当前路由的URL，否则签名算出来也过不了。

我遇到过的典型问题是：React项目的入口在/路由，但业务页面在/activity路由下。页面上线前没做路由分发处理，导致在/activity页面签名时用的仍是/的URL，签名验证一直失败。解决方法是：在进入需要分享功能的业务页面时，重新向后端请求一次签名并初始化wx.config。也就是说，wx.config不一定只调用一次，可以按页面维度反复调用，但要注意每次调用必须使用对应的URL参数。

5. 分享到好友与朋友圈的具体配置实现

5.1 新旧接口兼容处理：updateAppMessageShareData与onMenuShareAppMessage

微信官方在2017年左右升级了分享接口，推荐使用updateAppMessageShareData和updateTimelineShareData。但新接口在部分旧版本微信客户端上可能不生效，这就需要考虑新旧接口同时注册，达到兼容目的。

一般做法是先调用新接口设置分享信息，再判断是否支持新接口。如果不支持，则回退到老的onMenuShareAppMessage和onMenuShareTimeline。一个直接的判断方法是通过wx.ready回调里尝试调用新接口，看它是否报错。但“报错”不一定立即出现。

更稳妥的方式是不做接口能力探测，而是同时设置新旧接口。微信SDK在内部对新旧接口做了兼容处理，重复设置不会导致冲突。在实践中我也验证过：同时调用新旧接口，分享的信息都正常生效，没有异常报错。

分享到好友的配置写法：

wx.ready(() => { // 分享给好友 wx.updateAppMessageShareData({ title: '分享标题', // 分享标题 desc: '分享描述', // 分享描述 link: 'https://example.com/activity?id=123', // 分享链接 imgUrl: 'https://example.com/static/share-logo.png', // 分享图标，建议尺寸300*300 success: function() { console.log('好友分享配置成功'); }, cancel: function() { console.log('好友分享配置取消'); } }); // 分享到朋友圈 wx.updateTimelineShareData({ title: '朋友圈分享标题', link: 'https://example.com/activity?id=123', imgUrl: 'https://example.com/static/share-logo.png', success: function() { console.log('朋友圈分享配置成功'); }, cancel: function() { console.log('朋友圈分享配置取消'); } }); // 兼容旧版本 wx.onMenuShareAppMessage({ title: '分享标题', desc: '分享描述', link: 'https://example.com/activity?id=123', imgUrl: 'https://example.com/static/share-logo.png' }); wx.onMenuShareTimeline({ title: '朋友圈分享标题', link: 'https://example.com/activity?id=123', imgUrl: 'https://example.com/static/share-logo.png' }); });

有几个要点需要提醒。

link这个字段必须和签名时的URL在同一域名下，否则微信会直接拦截分享或分享后链接被提示“非微信官方网页”。强烈建议在link参数上带上渠道追踪参数，比如?share_from=wx_friend，方便后续统计各渠道效果。分享出去的链接如果被用户多次转发，域名和参数都保持不变，配合服务端日志可以追踪传播路径。

分享图片的imgUrl必须为完整绝对路径，同时微信要求图片比例最好为正方形，建议300*300像素以上、不超过1MB。图片服务器需要走HTTPS协议，微信在处理非HTTPS图片时可能会拒绝展示。

还有一点容易被忽略：title和desc的长度。好友分享的title建议控制在28个汉字以内，desc控制在30个汉字以内，超出部分微信会自动截断，但截断后的展示效果可能不够理想。朋友圈分享只有title字段，微信会自动拼接一段来源信息，因此标题建议控制在20个汉字以内。

5.2 分享场景差异：自定义标题与缩略图的处理逻辑

好友分享和朋友圈分享在呈现上差别很大，这也是在设计分享内容时要有差异化考虑的原因：

• 好友分享（updateAppMessageShareData）：会展示标题、描述、缩略图三要素，用户还可以在聊天窗口里看到完整卡片；
• 朋友圈分享（updateTimelineShareData）：只展示标题和缩略图，不展示描述字段。即使你在接口里传了desc，朋友圈也不会显示。

这个差异导致很多运营人员活动页配置分享后，发现朋友圈里看到的卡片文字“残缺”，其实是机制如此，不是配置有误。

在设计分享内容时，如果页面需要同时兼顾好友和朋友圈场景，我的建议是：

• 好友分享的标题做成“利益点+行动号召”的形式，比如“点击领5元现金红包”，引发点击欲望；
• 朋友圈分享的标题简短更有冲击力，比如“快帮我助力，拿到奖品就靠你了”之类，适合社交场景。

不过注意标题中的文字要符合微信平台规范，不能包含诱导分享类词语。

5.3 在React/Vue中封装分享工具函数

如果多个页面都要配置分享，把分享逻辑封装成公共工具函数是比较合理的做法。以Vue 3为例，可以抽出一个useShare的Composable函数：

// useShare.js import wx from 'weixin-js-sdk'; import { onMounted } from 'vue'; export function useShare(shareConfig) { const defaultShare = { title: document.title || '默认标题', desc: '默认描述', link: window.location.href.split('#')[0], imgUrl: 'https://example.com/default-share.jpg' }; const mergedConfig = { ...defaultShare, ...shareConfig }; onMounted(() => { // 确保wx.config已经初始化 wx.ready(() => { wx.updateAppMessageShareData({ title: mergedConfig.title, desc: mergedConfig.desc, link: mergedConfig.link, imgUrl: mergedConfig.imgUrl }); wx.updateTimelineShareData({ title: mergedConfig.title, link: mergedConfig.link, imgUrl: mergedConfig.imgUrl }); }); }); }

使用起来也很直接：

<script setup> import { useShare } from '@/hooks/useShare'; useShare({ title: '我的专属活动福利', desc: '点击参与活动，有机会赢取大奖', link: 'https://example.com/activity?user=123' }); </script>

封装的主要意义在于：把wx.config初始化、签名加载、分享设置这些重复逻辑收敛到一处，同时在团队内部保证了接口调用的规范。如果以后分享规则变化，只需要改动这个文件即可。

6. 签名校验失败、图片无法显示等经典问题排查链路

6.1 invalid signature出现后应该按什么顺序排查

遇到invalid signature，不要急着改代码，按以下链路逐个排查会快很多：

1. 先确认页面实际打开的URL是什么。在微信里打开页面后，点击右上角三个点，选择“复制链接”，看复制出来的完整链接是什么样。用这个链接作为签名URL，而不是开发者工具里看到的URL。两者在微信内置浏览器中可能不同，特别是有些页面在加载时有跳转逻辑。
2. 检查后端拿到的URL是否与第1步复制的链接去掉#hash后完全一致。注意大小写、端口、query参数顺序都不能变。
3. 检查jsapi_ticket是否过期，网络上获取到的票据是否正常。可以在后端打印日志，先确认ticket缓存的过期时间有没有写错。
4. 核对timestamp是否与服务器当前时间一致。微信的签名有效期只有几分钟，客户端时间与服务器时间偏差大于一定范围时也会失败。
5. 重新生成一次签名，确认每次签名时的nonceStr都是唯一的。如果恰好两次请求在1秒内用了相同的时间戳和nonceStr，微信会认为是重放请求而拒绝。

排查过程中建议把签名算法涉及的原始字符串打印出来，在本地用在线SHA1工具进行比对。如果在线工具算出来的值和后端返回的signature相同，就说明后端算法正确，问题出在URL取值环节。

6.2 “config:fail”的常见来源与处理方案

config:fail在微信内置浏览器里出现时，通常会伴随提示信息。最常见的是：

• config:fail invalid signature-> 按上面的链路排查；
• config:fail not authed-> 公众号没有通过微信认证；
• config:fail no permission-> 调用的接口不在权限列表内；
• config:fail 系统错误-> 微信接口服务临时故障，稍微等待重试。

还有一个特殊的失败场景出现在iOS系统微信中：如果页面在plus或iframe中加载，某些版本会限制JS-SDK初始化。需要把页面跳转到顶层窗口再初始化。

处理这个问题的代码：

if (window.self !== window.top) { window.top.location.href = window.location.href; }

不过这个处理方式要谨慎使用，毕竟大部分业务页面不需要强制跳转，只在确认页面被iframe嵌入且SDK初始化失败时启用。

6.3 分享缩略图不显示的排查记录

缩略图不显示是另一个高频问题。按照我踩过的坑，原因通常有以下几种：

其中CDN防盗链是很多人没意识到的问题。图片放在阿里云OSS或腾讯云COS上，默认会校验Referer头，而微信内置浏览器的Referer是https://open.weixin.qq.com/，如果CDN防盗链配置里没有放行这个域名，缩略图自然就加载不出来。在CDN控制台把*.weixin.qq.com加入Referer白名单基本能解决。

6.4 微信版本碎片化：老版本兼容的取舍

微信客户端的更新节奏并不完全统一，部分用户可能长时间停留在老版本。在开发中需要决定是否兼容老接口。

我的建议是要做基础兼容，但不做全面铺开。因为2020年之后微信官方基本统一了新接口行为，老接口只在高版本微信中被保留为兼容模式。只需要在wx.ready中同时注册新旧接口即可，不需要针对3.x以下的老版本做额外适配。部分老版本手机系统（iOS 9以下）对ES6语法支持不完整，导致SDK初始化异常，可以考虑在构建时做低版本语法转译。

7. 线上部署前必做的验证清单

配置完分享后，不要直接上线，在公共号后台把页面发到微信里实际测试，验证以下清单：

• 在Android和iOS微信中分别打开页面，右上角菜单里是否出现“分享给朋友”“分享到朋友圈”选项；
• 在好友聊天窗口里分享出去的卡片，标题、描述、缩略图是否正常展示；
• 在朋友圈里分享出去的卡片，标题、缩略图是否正常展示；
• 点击分享出去的卡片，能否正常打开落地页；
• 落地页打开后，再次分享是否仍然正常生效。

我习惯在团队内部搞一个测试群，把活动链接发在群里让同事帮忙点开看效果。超过几个人的反馈集合往往能覆盖多数边界情况。

8. 从分享配置延伸出去：同一套签名体系还能做什么

如果已经成功跑通了JS-SDK签名体系，它的价值不止于分享。同一个wx.config初始化之后，你还能调用微信提供的其他接口能力：

签名、配置等基础操作都是一套逻辑，改一下jsApiList就能复用。基于已经稳定运行的签名服务，做后续功能扩展的成本会低很多。

如果后续要做防分享、防刷量，也可以在服务端记录每次signature生成时对应的URL和ip，配置好频率限制策略，避免被恶意刷签名接口。

最后再分享一个习惯：签名接口上线前，一定要做异常监控。因为access_token或jsapi_ticket获取失败时，前端会大面积出现分享失效，影响传播效率，而这类问题有时候不会在常规测试中被发现。给签名接口设置监控告警，接口失败率达到某个阈值时自动通知开发，能省去很多被动发现问题的时间。