企业官网建设流程全解析

做微信小程序，只要你的产品不是那种纯工具型、压根不需要传播的小工具，早晚都会收到一条运营需求：分享卡片能不能好看点？能不能带上描述文案？能不能在用户点转发的时候把参数带上，让被分享的人打开后直接看到对应内容？

微信默认的分享卡片，确实太“朴素”了。它通常只取页面标题和当前页面的截图缩略图，标题一长就会被截断，缩略图也经常截到页面空白区域，分享出去既没有吸引力，也没法表达你想传达的关键信息。用户扫一眼根本不知道这个卡片里是什么，自然不愿意点开，更不用说帮你转发裂变了。

这篇要讲的，是我在真实项目里跑过一整个版本迭代后沉淀下来的一套方案：基于微信小程序纯原生 API 实现全局自定义分享，支持每个页面按路由配置不同的分享图片和文字描述，同时保留了“复制链接”这条兜底路径，解决那些实在没法走分享卡片场景的分发需求。如果你正在被默认分享卡片丑哭，或者想让几十个页面的分享逻辑统一收口，这篇文章应该能给你一个可以直接抄作业的完整参考。

1. 为什么要重新设计分享逻辑

1.1 微信默认分享卡片到底缺什么

先看微信小程序原生的分享能力。只要你在一个 Page 里定义了onShareAppMessage这个方法，用户点击右上角菜单里的“转发”，或者点击带open-type="share"的 button，微信就会弹起分享面板。不定义这个方法，右上角菜单里的“转发”是置灰不可点的。

没做任何自定义的时候，微信默认返回的title是当前页面的标题，imageUrl是当前页面截图。听起来好像也够用，但实际体验很尴尬：页面截图里有大量留白和导航栏，缩略图在聊天列表里小到看不清；标题超过一屏被截断；最关键的是，用户打开你分享的链接后落地页是原页面，无法区分这个用户是来自谁的分享、从哪个入口进来的。

我之前做内容社区类小程序时就吃过这个亏。运营想统计每个分享渠道的转化率，结果后端拿到的打开记录全是孤零零的页面路径，压根不知道是哪个用户分享出去的。所以全局自定义分享要解决的第一件事，不是好看，而是可追踪、可运营。

1.2 “全局”不是一个方法，是一套机制

很多开发者的第一反应是：那我在App.onLaunch里写一个onShareAppMessage是不是就全局生效了？不行，微信原生 API 的分享回调只认 Page 实例，你在 App 级别配置是不会被调用的。

所以这里说的“全局”是指：把分享逻辑做成一个公共的处理器，统一包装到每一个 Page 实例中去。每个页面不必重复写onShareAppMessage里那堆 return，只需要在配置表里加一行匹配规则，或者压根什么都不用加，走默认兜底配置。既做到统一收口，又保留单页覆盖能力。

1.3 纯原生转发意味着什么

市面上有大量分享插件、邀请返利 SDK、积分裂变组件，但微信官方对分享相关接口管控很严，第三方方案要么依赖后端接口，要么需要圈层授权。使用微信纯原生转发，核心优势有三个：

• 不引入额外 SDK，包体零增加，稳定性和审核风险都可控；
• 分享面板和好友卡片样式是微信自己渲染的，没有兼容性差异；
• 转发路径完全可控，通过path参数可以把分享带过去的用户路由到指定页面并携带参数。

这套方案不需要任何跨端框架，也不依赖云开发，一份原生小程序工程直接能用。我下面所有的代码示例都是标准原生小程序语法，如果你用的是 uni-app 或 Taro，原理完全一致，只是生命周期写法需要映射过去。

2. 分享配置表：把每个页面的分享行为收口到一个文件

2.1 配置表的结构设计

我在项目里的做法是，在项目根目录下建一个share/index.js，里面导出一份配置对象。key 是页面路由，value 是这个页面的分享配置。配置支持静态值，也支持函数动态生成，因为很多页面需要把当前页面的数据拼进标题或链接里。

// share/index.js export default { // 首页 'pages/index/index': { title: '这里是一个值得分享的首页', desc: '不管你有没有点进来，看看不吃亏', image: '/assets/images/share-default.png', path: '/pages/index/index' }, // 商品详情，path 需要带 id 'pages/detail/detail': { title: '这个商品我看了很久，推荐你也看看', desc: '限时活动正在进行中', image: '/assets/images/share-goods.png', path(options, page) { const id = page.data.goodsId || 0 return `/pages/detail/detail?id=${id}&from=share` } }, // 默认兜底 default: { title: '来自小程序的分享', desc: '快来看看吧', image: '/assets/images/share-default.png', path: '/pages/index/index' } }

这里的配置字段我做了精简：title是分享标题，desc是分享描述，微信原生onShareAppMessage的返回值里并没有desc这个字段，但在某些自定义转发 UI 场景下还是能用到的，后面会细说。image是分享图片，path是用户点开卡片后进入的落地页路径。

2.2 动态配置与静态配置的取舍

配置项写成函数有什么好处？比如商品页的分享标题，你希望带上商品名，但商品名是异步请求回来的，存在于页面的 data 里。把配置写成函数，在执行分享回调的那一刻去拿page.data，就能保证取到的是当前最新数据，而不是页面 onLoad 时的旧数据。

还有一种更极端的场景：用户点了某个按钮触发分享，从res.target.dataset里可以拿到按钮上绑定的自定义参数。配置函数也可以接收res参数，从而根据触发来源决定分享路径。

2.3 为什么不用“每个页面自己写分享函数”

每个页面自己写onShareAppMessage是最直接的写法，但问题在于项目一大，你会发现至少有 30% 的页面分享逻辑是完全重复的，甚至有人复制粘贴后忘了改路径，导致所有分享卡片都跳回首页。配置表的好处是：

• 运营想调整某个页面的分享文案，开发只需要改一行配置，不用翻代码找页面；
• 分享逻辑统一走同一个处理函数，后期如果要埋点统计点击率，只需在处理器里加一个监听；
• 新增页面时，默认会走 default 配置，不会出现漏配，用户也不会看到空白的默认卡片。

3. 把 onShareAppMessage 逻辑做成公共混入

3.1 用 Page 构造器包装页面配置

原生小程序没有 mixin 这个概念，但我们可以封装一个函数，在页面注册时统一注入分享逻辑。思路很简单：页面原来的配置对象传进来，我们用一个新的onShareAppMessage覆盖掉页面配置里的同名方法（如果页面有自定义，就调用页面配置里的方法后再做合并），然后返回新的配置对象给Page()。

// share/withShare.js import defaultShare from './index' export function withShare(pageConfig = {}) { // 保存页面原本的 onShareAppMessage 和 onShareTimeline const originalShare = pageConfig.onShareAppMessage const originalTimeline = pageConfig.onShareTimeline // 根据路由匹配配置 function resolveShareConfig(route, pageInstance, res) { const config = defaultShare[route] || defaultShare.default if (typeof config === 'function') { return config.call(pageInstance, res, pageInstance) } if (typeof config === 'object') { const result = { ...config } if (typeof result.path === 'function') { result.path = result.path.call(pageInstance, res, pageInstance) } if (typeof result.title === 'function') { result.title = result.title.call(pageInstance, res, pageInstance) } return result } return defaultShare.default } // 统一处理分享给好友的逻辑 function builtInShare(res) { const route = this.route || (getCurrentPages().slice(-1)[0] || {}).route || '' const config = resolveShareConfig(route, this, res) // 如果页面想自定义返回内容，调用页面原方法后再合并 let pageReturn = {} if (typeof originalShare === 'function') { const ret = originalShare.call(this, res) if (ret && typeof ret === 'object') { pageReturn = ret } } // 图片统一处理：优先页面返回，其次配置 const imageUrl = pageReturn.imageUrl || config.image const path = pageReturn.path || config.path || `/${route}` const title = pageReturn.title || config.title || '分享' return { title, path, imageUrl } } // 统一处理分享到朋友圈的逻辑 function builtInTimeline() { const route = this.route || '' const config = resolveShareConfig(route, this, {}) let pageReturn = {} if (typeof originalTimeline === 'function') { const ret = originalTimeline.call(this) if (ret && typeof ret === 'object') { pageReturn = ret } } return { title: pageReturn.title || config.title || '分享', query: pageReturn.query || '', imageUrl: pageReturn.imageUrl || config.image } } return { ...pageConfig, onShareAppMessage: builtInShare, onShareTimeline: builtInTimeline } }

然后用这个函数注册页面：

// pages/index/index.js import { withShare } from '../../share/withShare' Page(withShare({ data: { ... }, onLoad() { ... } }))

这样一来，每个页面都自动具备了分享能力。

3.2this.route的兼容性陷阱

这里有一个细节很多人第一次会踩坑：在自定义的withShare处理器里，onShareAppMessage被以普通函数形式定义，this指向的是页面实例，那么this.route在绝大多数情况下可以拿到当前页面路由。但如果你的配置是在某个工具方法里通过闭包方式调用，this可能丢失，稳妥的做法是通过getCurrentPages()去拿栈顶页面的 route。

我代码里写的this.route || getCurrentPages().slice(-1)[0].route就是这个意思。这样做还有一个好处：当页面 A 分享出去的 path 是落地页 B，而 B 页面没有配置分享时，回调里拿到的路由是 B，配置表会走到 default，不会误用 A 的配置。

3.3 页面级临时覆盖的姿势

有些页面的分享逻辑比较复杂，例如婚礼请柬页面需要把新人名字和日期动态拼进标题，评论详情页需要分享后带上评论者的昵称。遇到这种情况，我建议仍然保留页面上自定义的onShareAppMessage，然后在公共处理器里做合并：页面自己的返回结果优先，配置表作为兜底。

这样写的好处是，简单页面可以完全依赖配置表，复杂页面可以只写自己特殊的那部分，公共的图片、路径处理逻辑仍然由withShare统一接管，不会出现“为了一个特殊页面，把全局逻辑改坏”的局面。

4. 分享图片和文字描述的组合策略

4.1 图片格式与尺寸限制

分享给好友的卡片，官方要求图片比例建议 5:4，大小不能超过 5MB，格式支持 JPG 和 PNG。朋友圈分享onShareTimeline则建议使用竖版图，比例大概在 6:5 左右，因为朋友圈卡片是竖排展示的，横图会显得很小。

实际开发中，分享图不显示是最常见的问题。我前后排查过多起“为什么分享卡片是黑屏/白板”的情况，最后归纳出一个最稳的实践：不要直接传网络图片链接作为 imageUrl，先把图片下载到本地临时文件，再传给分享 API。

微信官方文档说 imageUrl 支持网络路径，但真实环境里，特别是 iOS 端，网络图片经常会出现加载失败、被压缩到模糊、甚至干脆显示空白的问题。而且网络图片还牵扯到域名白名单、防盗链、HTTPS 证书等一系列问题。所以我的做法是：

function downloadShareImage(url) { return new Promise((resolve) => { wx.getImageInfo({ src: url, success(res) { resolve(res.path) }, fail() { // 如果下载失败，回退到默认图 resolve('/assets/images/share-default.png') } }) }) }

在分享函数执行时，先 await 这个 download 过程，拿到的本地临时路径再填进imageUrl。本地临时文件有生命周期限制，但会话级别的分享完全够用，不需要担心失效问题。

4.2 用 canvas 生成动态分享海报

如果你的分享图片需要带上用户昵称、二维码、商品价格这类动态内容，那就得走 canvas 绘制海报的路线。这也是很多电商小程序在做的方式：点分享按钮 -> 页面弹出半透明蒙层显示海报 -> 长按识别。

核心流程分四步：

1. 在页面里放一个隐藏的 canvas 组件（Canvas 2D 接口更稳，旧版wx.createCanvasContext也可以）；
2. 把背景图、文字、二维码等元素依次绘制上去；
3. 等 canvas 绘制完成后，用wx.canvasToTempFilePath导出临时图片；
4. 把临时图片作为分享 imageUrl 或者给用户长按保存。

简单示例用 Canvas 2D：

<canvas type="2d" id="shareCanvas" style="width: 300px; height: 240px;"></canvas>

async function drawSharePoster() { const query = wx.createSelectorQuery() const canvasNode = await new Promise((resolve) => { query.select('#shareCanvas').fields({ node: true, size: true }).exec((res) => { resolve(res[0]) }) }) const canvas = canvasNode.node const ctx = canvas.getContext('2d') const dpr = wx.getSystemInfoSync().pixelRatio canvas.width = canvasNode.width * dpr canvas.height = canvasNode.height * dpr ctx.scale(dpr, dpr) // 绘制背景 ctx.fillStyle = '#fff' ctx.fillRect(0, 0, canvasNode.width, canvasNode.height) // 绘制文字 ctx.fillStyle = '#333' ctx.font = '16px sans-serif' ctx.fillText('这是分享文案', 20, 60) // 导出 wx.canvasToTempFilePath({ canvas, success(res) { console.log(res.tempFilePath) } }) }

几个我踩过的坑，提前给你避雷：

• canvas 节点的宽高和导出宽高要区分开，导出时如果不乘以pixelRatio，在部分安卓机型上会导出模糊图；
• 文字绘制前先ctx.font设置字号，不设置的话默认字体在 Android 和 iOS 上渲染效果差距很大；
• 二维码如果由后端接口返回 base64，canvas 不能直接画 base64，得先转成图片文件路径或者用网络图片 URL（也要先下载）。

4.3 标题和描述的克制写法

分享标题建议控制在 14 个字以内。微信聊天列表里的分享卡片，标题超过大概一行就会截断，超过两行直接显示省略号，你精心写的长文案根本展示不出来。描述文字只出现在特定场景（比如分享到某些支持卡片描述的应用时），在微信好友对话里基本不展示，所以不要把关键信息放在描述里，核心内容必须放在标题和图片上。

我自己常用的组合套路是：“推荐语 + 具体对象 + 利益点”。比如“我在这家店发现了一款神仙小零食，满 99 还减 20”，比“优惠活动”这种泛文案点击率高得多。这些文案建议运营维护在配置表里，不要散落在代码中，方便随时 AB 测试。

5. 复制链接：分享卡片以外的兜底路径

5.1 哪些场景必须复制链接

做了这么久小程序开发，你会发现“分享到微信好友”并不是万能的。至少有三种场景，你不得不依赖复制链接：

• 用户想在小程序外（比如 PC 端的微信聊天窗口）分享一个内容链接；
• 运营想要在公众号文章、微信群里放一个可点击的短路径，而不是一张截图；
• 某些 web-view 页面或特殊内嵌场景，微信原生分享面板被屏蔽，只能通过复制让用户手动去粘贴。

复制链接的交互很简单：wx.setClipboardData把一段带 path 和 query 的链接塞进剪贴板，再引导用户去微信聊天窗口粘贴发送。这里的“链接”不是真正的https://网址，而是小程序内部路径，比如/pages/detail/detail?id=1001&from=copy。接收方点开后，微信会直接拉起对应小程序页面。

5.2 路径参数的拼接与解析

拼接链接时要注意：path必须以/开头，参数用?连接，多个参数用&分隔。值最好经过encodeURIComponent编码，因为有些参数（比如昵称、活动标签）可能包含中文和特殊字符，不编码的话会解析错。

function buildSharePath(route, query = {}) { const base = `/${route}` const queryString = Object.keys(query) .map((key) => `${key}=${encodeURIComponent(query[key])}`) .join('&') return queryString ? `${base}?${queryString}` : base } // 使用 const sharePath = buildSharePath('pages/detail/detail', { id: 1001, inviteCode: 'abc123' }) wx.setClipboardData({ data: sharePath, success() { wx.showToast({ title: '链接已复制，快去粘贴给朋友吧', icon: 'none' }) } })

落地页在onLoad(options)里取参数：

Page({ onLoad(options) { const id = Number(options.id) const inviteCode = options.inviteCode || '' // 在这里埋点统计来自复制的访问 } })

这里有一个容易忽略的点：复制链接的内容如果被粘贴在微信聊天里发送，接收方点开的瞬间，微信会先唤起对应的小程序。如果你的小程序已经打开，它会直接切到当前会话并触发落地页的onShow而不是onLoad，所以落地页的参数初始化逻辑最好同时写在onLoad和onShow里，或者在onLoad里把参数存下来供onShow使用。

6. 上线后踩过的坑：问题排查实录

6.1 分享卡片图片不显示

这是最高频的问题，没有之一。现象是转发出去的卡片标题正常，但缩略图一直是白板或者黑灰块。

先检查排查链路：

• 配置里的 imageUrl 到底传没传？很多情况是onShareAppMessage里根本没 return imageUrl，微信用页面截图顶上，在部分机型上截图时机太早拿到的是空白；
• 网络图片有没有被下载成本地临时文件？没有的话 iOS 大概率空白；
• 图片路径有没有以/开头？本地路径写成了相对路径会出现读取失败；
• 图片大小有没有超 5MB？超了会被微信直接丢弃。

6.2 分享出去的 path 丢了参数

页面配置函数里动态拼 path 时，如果数据是异步获取的，分享回调时 data 还没 setData 回来，拼出来的 path 就是残缺的。解决办法：在拿到数据后主动更新全局 store 里的一份“分享上下文”，配置函数读取这份上下文，而不是只依赖页面 data。

6.3 二维码分享图在安卓上长按无法识别

canvas 导出的临时图片是wxfile://开头的临时路径，用户如果直接长按临时文件，部分安卓机型会弹出“图片已保存”而不是“识别图中二维码”。

解决办法：不要用临时路径直接做展示，先用wx.saveImageToPhotosAlbum引导用户保存到相册。保存动作必须在用户点击按钮后触发（属于用户主动行为），否则会被微信拦截。

6.4 基础库版本兼容

onShareTimeline（分享到朋友圈）需要基础库 2.11.3 以上才支持，Canvas 2D完整可用也需要 2.9.0 以上。如果你的小程序用户里存在低版本微信，最好在分享按钮点击时做一次版本判断，低版本用户隐藏朋友圈分享入口，只保留好友转发和复制链接。

6.5 问题速查表

这套方案上线后，我们小程序的分享卡片点击率比之前默认截图提升了大概三分之一，尤其是给每个页面配置独立分享图之后，运营再也没有抱怨过“这个分享出去太难看了”。分享这件事情，永远值得在产品里多花一点心思，它可能是你成本最低的增长手段。

最后分享一个我的个人习惯：不要把分享逻辑写死在某个页面里后再复制到下一个页面，而是从第一个页面开始就建好配置表和公共处理器。后面每新增一个页面，你只需要考虑“这个页面分享出去的标题应该是什么”，而不用关心微信 API 怎么调、图片怎么处理。这个基建成本大概半天，但省下的修改和排障时间，远超你的预期。