1. 微信小程序用户授权这些年我们走过的路大家好我是老张一个在小程序开发坑里摸爬滚打了快十年的老码农。今天想和大家掏心窝子聊聊微信小程序里获取用户头像昵称这件事。这事儿吧说大不大但几乎每个做小程序的开发者都得过这一关。从最早的wx.getUserInfo一个接口走天下到后来各种调整、废弃、新接口推出再到现在的“头像昵称填写”新方案整个过程简直像一部微缩的技术演进史也让我们这些开发者踩了不少坑长了不少记性。我记得最早那会儿2017、2018年的时候小程序刚火起来获取用户信息多简单啊。页面上放个按钮写上open-typegetUserInfo用户一点弹个窗问“是否允许获取你的公开信息昵称、头像等”用户点个“允许”userInfo对象里昵称、头像、性别、地区啥都有了直接就能用。那时候的代码写起来那叫一个顺畅感觉微信生态对开发者特别友好。但问题也慢慢浮现了就是“一次授权终身受用”。用户第一次授权后开发者后续再调用wx.getUserInfo不会再弹窗直接就能拿到数据。这虽然方便但也带来了隐私上的争议用户可能在不经意间、甚至忘了自己曾经授权过的情况下个人信息就被持续获取了。所以微信团队在2021年4月下了狠手做了一个重大的调整。这个调整对当时正在开发的项目冲击不小。简单说就是在这个时间点之后发布的新版本小程序你再调用wx.getUserInfo或者用那个button组件它不弹窗了它直接给你返回一套“匿名化”的用户信息。你拿到的头像是个灰色默认头像昵称可能是“微信用户”后面跟一串随机字符性别地区啥的都是空的。看起来好像拿到了数据但实际上都是假的没法用在业务里。这个变化的核心目的就是把用户信息的控制权更明确地交还给用户自己要求每一次获取敏感信息都必须经过用户当下的、明确的同意。当时为了应对这个变化微信同步推出了一个新的接口wx.getUserProfile。这个接口的设计思路就是“即用即授权”。开发者不能在页面一加载就调用必须在用户产生主动点击行为比如点击一个按钮的回调函数里才能调用。每次调用都会弹出授权弹窗清清楚楚地告诉用户你要用他的昵称和头像做什么需要填写desc参数来说明用途用户每次都需要点击“允许”才能拿到真实的用户信息。这确实更合规、更尊重用户隐私了但对用户体验来说尤其是需要频繁使用头像昵称的场景每次都要弹窗确认确实有点繁琐。而且这个接口的生命周期也并不长后来也被标记为“已弃用”这就引出了我们今天要重点讨论的最新方案。2. 旧时代的王者wx.getUserInfo 的功与过咱们先回过头好好掰扯一下wx.getUserInfo这个“老前辈”。我敢说现在还在维护的小程序项目十有八九的早期版本代码里都能找到它的身影。它的设计哲学是典型的“授权一次到处使用”这在其诞生的早期阶段极大地降低了开发门槛和用户操作成本。从使用方式上它主要有两种路径。第一种是前端组件触发在 WXML 文件里你可以这样写button open-typegetUserInfo bindgetuserinfoonGetUserInfo 一键登录/授权 /button然后在对应的 JS 文件的onGetUserInfo函数里就能从事件对象e.detail.userInfo中拿到完整的用户信息。第二种是纯 API 调用在 JS 里直接写wx.getUserInfo({ success: function(res) { console.log(用户昵称, res.userInfo.nickName); console.log(用户头像, res.userInfo.avatarUrl); } })在旧版本中如果用户从未授权这段代码会触发授权弹窗。如果已经授权过则静默成功直接返回数据。为了方便判断用户是否已经授权我们通常会配合wx.getSetting接口一起使用形成一个标准流程wx.getSetting({ success (res) { if (res.authSetting[scope.userInfo]) { // 已经授权可以直接调用 getUserInfo 获取 wx.getUserInfo({ success: function(infoRes) { // 使用 infoRes.userInfo } }) } else { // 未授权显示一个引导授权的按钮上面那种open-type的button } } })这一套组合拳在当年是教科书式的标准做法。它的优点非常突出流程简单用户体验流畅。用户只需要在第一次使用时点一下授权后续所有需要头像昵称的地方比如评论、个人中心、分享卡片都能无缝使用没有任何打扰。对于开发者而言代码逻辑清晰数据获取稳定可靠。但是它的“过”也恰恰藏在这些“优点”里。最大的问题就是“过度授权”和“授权感知弱”。用户可能在某个不起眼的场景下点了授权之后就完全忘记了这回事。而开发者却可以永久性地、在任何时间点获取用户的这些个人信息即使用户已经很久没有使用这个小程序。这在用户隐私意识日益增强的今天显然是不合时宜的。此外wx.getSetting接口在政策调整后也出现了“失真”它返回的scope.userInfo授权状态永远为true因为系统现在认为你获取的是“匿名信息”这导致开发者无法再通过这个接口准确判断用户的真实授权状态旧的逻辑完全失效。正是这些弊端推动了第一次重大的接口变革。3. 过渡时期的桥梁wx.getUserProfile 的短暂使命当wx.getUserInfo不再返回真实数据时微信给出了过渡方案wx.getUserProfile。这个接口可以看作是微信在用户隐私和开发者需求之间寻找的一个临时平衡点。它的出现明确传达了“每次获取敏感信息都需用户明确同意”的信号。使用wx.getUserProfile代码写法发生了明显变化。首先它不能通过button组件的open-type来触发也不能在页面加载等非交互场景下调用。它的调用必须捆绑在一个真实的用户点击事件上。典型的用法是这样的在 WXML 中就是一个普通的按钮button bindtaponTapGetUserProfile获取头像昵称/button在 JS 中响应对应的点击事件onTapGetUserProfile() { wx.getUserProfile({ desc: 用于完善会员资料, // 必填声明用途 success: (res) { console.log(用户信息, res.userInfo); // 这里的 userInfo 是真实的用户数据 this.setData({ avatarUrl: res.userInfo.avatarUrl, nickName: res.userInfo.nickName }) }, fail: (err) { console.log(用户拒绝了授权, err); } }) }你可以看到最大的不同是多了一个必填参数desc。这个字段要求开发者用简明的语言告诉用户你要他的头像昵称来干什么比如“用于完善个人资料”、“用于发表评论”等。这个描述会直接展示在授权弹窗里让用户的授权决策更加知情。wx.getUserProfile的优点在于合规性高授权意图清晰。每一次获取都是新鲜的、经用户确认的完全符合越来越严格的个人信息保护要求。对于用户来说他知道自己的信息被用在了哪里控制感更强。然而它的缺点在真实业务场景中也被迅速放大。最被诟病的就是“体验割裂”和“无法静默获取”。想象一下这样的场景用户进入个人资料页他想换个头像。页面显示了他当前的头像但因为这个头像是通过getUserProfile获取的而这次进入页面没有触发点击所以页面可能显示的是默认灰色头像。用户需要先点击“编辑”按钮触发getUserProfile弹窗授权同意后页面才刷新显示出他真实的微信头像。这个流程显得非常别扭。对于社交、社区类小程序用户每次发帖、评论都可能需要头像昵称频繁的弹窗授权会严重打断用户体验导致流失。正因为这些体验上的硬伤wx.getUserProfile并没有成为最终的解决方案它更像是一个特定历史时期的产物在完成了从“静默授权”到“显式授权”的观念过渡使命后也逐渐被更新的、更优的方案所取代。4. 当前的最佳实践头像昵称填写能力详解好重头戏来了。既然wx.getUserInfo已失效wx.getUserProfile也已弃用那我们现在到底该用什么答案是微信小程序最新的“头像昵称填写”能力。这不再是单纯的“获取”而是“填写”这个词的转变意味深长它把主动权完全交给了用户。这个新方案不再依赖任何 JS API比如wx.getXXX这样的接口。它完全通过微信小程序的基础组件来实现主要涉及两个组件button组件的open-type属性为chooseAvatar和nickname。4.1 获取用户头像chooseAvatar以前我们直接从接口里拿到一个头像的图片 URL。现在我们提供一个让用户“选择”头像的入口。用户点击后可以选择使用微信头像或者从手机相册上传一张图片。在 WXML 页面中你可以这样写!-- 用于触发选择头像的按钮 -- button classavatar-wrapper open-typechooseAvatar bindchooseavataronChooseAvatar image classavatar src{{avatarUrl}}/image /button注意open-typechooseAvatar是核心。当用户点击这个按钮会触发手机的原生头像选择界面。选择完成后会触发bindchooseavatar绑定的onChooseAvatar事件。在 JS 文件中你需要处理这个事件onChooseAvatar(e) { const { avatarUrl } e.detail // 这里拿到的是临时头像文件的路径 this.setData({ avatarUrl: avatarUrl // 临时路径可以用于预览 }) // 重要你需要将这个临时文件上传到自己的服务器保存 this.uploadAvatarToServer(avatarUrl); }这里有一个至关重要的变化事件回调e.detail.avatarUrl返回的是一个临时文件路径比如wxfile://tmp_avatar.jpg而不是一个永久的网络 URL。这个临时路径只在当前小程序本次运行期间有效用户关闭小程序后再打开这个路径就失效了。所以开发者必须在获取到这个临时路径后立即调用wx.uploadFile接口将这张图片上传到自己的服务器进行持久化存储然后使用服务器返回的永久 URL。这是和过去直接使用微信头像 URL 最大的不同增加了开发步骤但给了用户更换非微信头像的自由也符合数据自主管理的原则。4.2 获取用户昵称nickname昵称的获取思路类似也是通过一个专用输入组件。在 WXML 中input typenickname classnickname-input value{{nickName}} placeholder请输入昵称 /或者你也可以用一个按钮来触发昵称输入button open-typenickname bindnicknamereviewonNicknameReview 填写昵称 /button使用input typenickname是最常见的方式。当用户点击这个输入框会自动弹出带有“微信昵称”选项的输入面板。用户可以选择使用自己的微信昵称也可以手动输入任何其他文字作为昵称。在 JS 中通过绑定bindinput或bindblur事件来获取用户输入的值onNicknameInput(e) { this.setData({ nickName: e.detail.value }); // 同样需要将这个昵称同步到自己的服务器 this.updateNickNameToServer(e.detail.value); }4.3 新方案的优缺点与实战思考这套“头像昵称填写”新方案我把它用在实际项目里之后感受非常深刻。先说说优点用户体验路径清晰用户完全掌控流程。“点击头像区域-选择/上传图片”、“点击昵称输入框-输入/选择昵称”。这是一个符合直觉的“编辑个人资料”的过程而不是一个令人困惑的“授权”弹窗。隐私保护极致化小程序本身不再“获取”用户微信的头像昵称而是由用户主动“选择”是否提供以及提供什么。甚至可以不提供微信头像而用其他图片。这从根本上解决了过度采集的问题。灵活性极高开发者可以完全自定义头像和昵称的填写界面把它无缝地集成到用户的个人资料编辑页、注册流程页中体验非常原生。数据归属明确头像图片最终存储在你自己的服务器上昵称也是用户在你平台输入的内容。这些数据与你的业务绑定更紧密避免了因微信接口变动带来的风险。当然挑战和需要注意的地方也不少开发工作量增加不再是调用一个 API 那么简单。你需要处理前端组件事件、处理图片临时路径、实现文件上传到服务器、处理服务器端的存储和 URL 生成、处理昵称的同步整个链路变长了。首次体验可能更复杂对于“一键登录”场景旧方案一个按钮解决授权和登录。新方案可能需要引导用户先进入个人中心完成头像昵称的填写流程步骤多了。需要设计引导很多用户习惯了旧的授权弹窗对新流程不熟悉。你需要通过 UI 设计如清晰的提示文字“点击设置头像”、“点击设置昵称”来引导用户完成操作。兼容性注意chooseAvatar和nickname这些open-type是较新基础库才支持的。虽然覆盖率已经很高但稳妥起见在代码中还是需要做低版本兼容处理对于不支持的老版本可以降级使用其他方案如引导用户手动上传图片和输入框。5. 如何为你的项目选择合适的授权方案聊了这么多历史和新方案最后落到实际我们开发一个新项目或者改造一个老项目到底该怎么选这里我结合自己的经验给大家几个具体的建议。场景一全新启动的小程序项目无脑选择最新的“头像昵称填写”方案。这是微信官方主推且符合长远发展趋势的方案。从项目起点就采用它架构最干净没有历史包袱也最能适应未来的政策变化。你需要做的就是设计好用户信息填写页面并完善后端的上传和存储逻辑。场景二需要快速上线、对用户体验流程要求不高的工具类小程序如果你的小程序核心功能并不强烈依赖用户头像昵称或者只是偶尔在某个角落用到比如反馈页面留个昵称你可以简化处理。例如直接使用wx.getUserInfo获取匿名信息默认头像和“微信用户”昵称同时提供一个非常醒目的入口比如“点击这里设置个性化头像和昵称”这个入口链接到使用新方案的资料编辑页。这样既保证了基本功能又把是否完善信息的决定权交给了用户开发量也相对较小。场景三正在维护的、大量使用旧接口的历史项目这是最头疼的情况。我建议采用“渐进式升级”策略。评估影响首先全局搜索代码找出所有调用wx.getUserInfo、wx.getUserProfile以及使用相关button的地方。区分场景对于非核心场景如分享卡片上的头像可以先替换为默认图形或匿名信息。对于核心场景如个人中心、用户主页则需要规划重构。设计新流程在个人中心或设置页专门开辟一个区域使用新的chooseAvatar和nickname组件让用户更新信息。同时在用户首次登录或信息为空时可以温和地引导用户前往该页面进行设置。数据迁移将原先通过旧接口获取并存储的微信头像 URL在用户主动使用新功能后迁移为服务器存储的新 URL。对于昵称可以直接用用户新填写的覆盖旧的。版本兼容在app.json中设置最低基础库版本对于无法覆盖的极低版本用户保留一个降级方案例如提示升级微信。一些通用的实战技巧缓存策略用户通过新方案设置好头像昵称后一定要在你自己的服务器保存好。下次用户打开小程序时直接从你的服务器获取这些信息用于展示不要再让用户重复填写。这才是流畅体验的关键。引导文案很重要按钮或输入框旁边的文字不要写“获取微信信息”而是写“设置你的头像”、“填写你的昵称”。文案的转变能有效引导用户理解新流程。做好错误处理用户可能拒绝选择头像也可能输入违规昵称nickname输入有审核机制bindnicknamereview事件会返回审核结果。你的界面需要能优雅地处理这些情况给予友好提示。从我个人的感受来看微信这次授权方案的演变虽然短期内给开发者带来了适配的阵痛但长期看是好事。它迫使我们将用户视为拥有自主权的个体而不是数据的被动提供者。我们设计的交互流程必须更人性化技术架构也要更健壮。这个过程其实也是在帮助我们打造更健康、更可持续的小程序生态。