
写代码写到凌晨 1 点多,刚把 PPT 拼图工作台的最后一个功能调完,点提交审核,倒了杯水回来——
通知栏弹出:
-
"页面存在误导用户的内容。"
-
"分享功能不可用。"
-
"内容安全检测缺失。"

三个理由,三次打回。
那一瞬间有点恍惚——有点想骂人,又有点想笑,又有点想掀桌子。你是医生,开了个处方,病人(审核员)看了一眼,把处方单扔你脸上:药不对症,重新开。
你还不能问"哪儿不对"——文档里写了"内容安全检测缺失",但具体哪儿缺失,得你自己猜。
最无语的是,三个被拒理由,每个就一句话,没截图没定位,全靠开发者自己脑补。
我做的是个拼图小程序,纯工具,没社交、没充值、没广告——按理说是最容易过审的那种。
但微信审核这事,跟医院差不多。
你觉得自己没病,它说你有;你想解释,它不听;你想投诉,对不起,没这个窗口。
下面把这次踩过的 3 个最深的坑摆出来,每一个都附可运行的解决方案。
代码不多,但每一个都值一次审核被打回。
一、转发按钮是灰色的:菜单开错了地方
第一次上传完代码,我在开发者工具里点右上角——转发按钮是灰色的。

第一反应是:我代码是不是写错了?变量名打错了?config 没读到?心里一万个问候——以为是哪段写炸了,结果翻代码翻了二十分钟,发现不是 Bug,是我自己忘了开药。
翻了一遍 app.js——onShareAppMessage 没看到,wx.showShareMenu 也没看到。
根本原因说出来有点丢人:小程序的转发按钮必须显式声明才会显示,没配置的话,微信默认就给你隐藏。不是什么 Bug,只是我第一次搞小程序,什么都不懂而已。
但这里有个反直觉的设计:
onShareAppMessage 和 onShareTimeline 是 Page 级别的生命周期函数,写在 App 级别的 app.js 里,微信不会调用。
但是!!!
这时候测试是能正常进行分享功能的,但就是死活不会显示我自己的封面缩略图,调试了好久,每次AI都说调好了,但是一测试就还是原样,我真的原地崩溃。

这个问题折磨我最久——
整整一晚上没睡好。
代码配好了,imageUrl 也填了,路径是 /pages/index/share.jpg,图片 500×400、JPG 格式、小于 128KB——每个条件都对。
转发卡片上的封面图区域,依然是对当前页面的截图,而不是我自己设置的缩略图。
排查了一整晚:
-
文件存在 ✅
-
路径正确 ✅
-
尺寸对(500×400,5:4 推荐比例)✅
-
格式对(JPG)✅
-
大小合规(小于 128KB)✅
最后没办法换了个AIDE,再去试了下,结果一遍就找到问题核心了,然后我去测试了下,终于看到我心心念念的封面了。😭

所以正确做法是分两步:
第一步:在 app.js 里调 wx.showShareMenu,把菜单按钮从灰色变成可点。
App({
onLaunch() {
wx.showShareMenu({
withShareTicket: true,
menus: ['shareAppMessage', 'shareTimeline']
});
}
});
第二步:在每个需要支持分享的页面 JS 里,定义 onShareAppMessage 和 onShareTimeline,定义卡片内容。
// pages/index/index.js
Page({
onShareAppMessage() {
return {
title: 'PPT 拼图工作台 - 轻松制作多图拼图',
path: '/pages/index/index',
imageUrl: '/pages/index/share.jpg' // 本地图片,路径必须以 / 开头
};
},
onShareTimeline() {
return {
title: 'PPT 拼图工作台 - 轻松制作多图拼图',
query: '',
imageUrl: '/pages/index/share.jpg'
};
}
});
菜单在 App 里开,分享函数在 Page 里写——一个跨两个生命周期的事情,微信没在文档里一句话总结,全靠踩过。
imageUrl本地图片路径必须在小程序代码包里,格式/pages/index/share.jpg。图片体积别超过 128KB——本地图片有时会因为加载超时显示为空白。
二、msgSecCheck 报 40003:处方少了身份证号
小程序有图片上传和标题输入,按理说需要过一遍内容安全。
我写了 checkContentSafe,上传图片时调 imgSecCheck,标题输入时调 msgSecCheck。开发者工具里测试一切正常——直到真机触发标题检测。
errcode: 40003
errMsg: "openapi.security.msgSecCheck:fail invalid openid"
40003 是什么?
查文档:40003 是参数缺失,不是内容违规(40103 才是真违规)。盯着这三个数字看了三分钟,心里一万只羊驼奔过——又是这个该死的参数缺失。
我的云函数里只传了 content,没传 openid。msgSecCheck 这玩意儿必须要 openid,没 openid 它就罢工。
打个比方:你开了个处方,但处方上没写患者身份证号——药房拒绝配药,理由是"我不知道这药给谁吃"。
修复方案,云函数里补 openid:
// cloudfunctions/security/index.js
const cloud = require('wx-server-sdk');
cloud.init();
exports.main = async (event) => {
const { content } = event;
const { OPENID } = cloud.getWXContext();
try {
const res = await cloud.openapi.security.msgSecCheck({
content: content,
version: 2,
scene: 1,
openid: OPENID // ← 关键:必须传
});
return { errcode: res.errCode, errmsg: res.errMsg };
} catch (err) {
return { errcode: err.errCode, errmsg: err.errMsg };
}
};
OPENID 早就通过 getWXContext() 拿到了——只是没传给这个接口。
那为什么是 openid,不是别的参数? 因为微信的开放接口设计里,security.* 这类需要追溯到具体用户行为的 API,都要带 openid 作为最小追溯单元。imgSecCheck 也是同理。
这事不能怪文档写得不明显——文档里其实写得清清楚楚。
怪自己只顾着业务逻辑,把接口本身要求的参数漏了。
踩这种坑确实挺蠢的,但没办法,第一次调云函数开放接口的人,几乎都得踩一遍。
三、自动更新——避免用户手里的药还是上一版
小程序有个烦人的机制——微信有缓存。你周五发了新版本,周一老用户打开一看,代码还是上周的。Bug 修了但用户看不到,那种感觉就像你修好了水管,水表还在漏水。
本来我以为这个功能应该是小程序框架自带的功能,结果发现不是🥲。
解决办法:用微信官方提供的 wx.getUpdateManager,在 app.js 里监听新版本。
App({
onLaunch() {
this.checkForUpdate();
},
checkForUpdate() {
if (!wx.canIUse('getUpdateManager')) return;
const updateManager = wx.getUpdateManager();
updateManager.onCheckForUpdate((res) => {
// 后台静默检查新版本
console.log('[版本更新] hasUpdate:', res.hasUpdate);
});
updateManager.onUpdateReady(() => {
wx.showModal({
title: '更新提示',
content: '新版本已经准备好,是否立即重启应用?',
success: (res) => {
if (res.confirm) updateManager.applyUpdate();
}
});
});
updateManager.onUpdateFailed(() => {
wx.showModal({
title: '更新失败',
content: '新版本下载失败,请删除小程序后重新搜索打开。'
});
});
}
});

本地怎么测?开发者工具上方"编译"按钮下拉 → 选择"添加编译模式" → 勾选"下次编译模拟更新" → 重新编译。你能看到弹窗效果。
老实说,本来以为这么基础的功能应该会默认启用,结果被打脸,哈哈,幸好我及时发现并加上了。
三个病历本:踩完这些坑之后我学到的事
1. 先过审核文档关,再写代码
微信有个专门的《小程序常见审核被拒原因,把违规类型分成六类:账号基础信息、服务类目、页面内容规范、可用性完整性、隐私与数据安全、技术标准。
我在开发前没看这个文档,上传后才发现安全提示文字写得不准确,差点被拒。提前过一遍审核清单,能省下好几次"修改→重新提交→等 1 天"的时间。
2. 云函数里该传的参数,一个都不能少
msgSecCheck 的 openid、scene,imgSecCheck 的 media(媒体素材链接),getUserProfile 的 desc——这些不是"可选参数",是接口正常工作所必需的。微信官方文档(developers.weixin.qq.com/miniprogram/dev/api-backend/)里每个 API 的参数表都写得清清楚楚,但开发者看代码时最容易跳过的就是这块。
微信开放接口的文档写得非常清楚。但云函数里调用时,开发者很容易只顾着业务逻辑,把接口本身要求的参数漏掉——这是病历本里最容易反复出现的同一个症状。
3. 转发配置:菜单在 App,分享函数在 Page
这条是从坑一里学到的:wx.showShareMenu 在 app.js 里开启菜单按钮,onShareAppMessage / onShareTimeline 在每个具体页面 JS 里定义分享卡片内容。一个跨两个生命周期的事情,微信没在文档里强调,全靠踩过才知道。(也许此时看到文章的你去点开小程序,分享功能还是没有🥲,希望能尽快审核通过把🙏)
尾记
就在我所有都修改完成之后,以为这次提交版本是很稳了,结果刚准备忙碌了一天休息下的时候,微信又收到审核不过的提醒了。
迅速点进去一看,居然又是这个原因,我心里真的***。

赶紧打开电脑来测试下,到底是什么原因,直接跑起来测试下,结果控制台看到这个提示。

点击链接过去一看,顿时觉得天塌了。

看到的第一反应就是今天为了弄分享缩略图的时候把存储修改成了所有用户可读。立马去修改权限,等待几分钟再测果然就不报错了。哎,我只是想开发一个小工具,利人利己而已,咋怎么折腾!
补一刀
「PPT 拼图工作台」是个多图拼图工具,7 种布局模板,上传图片自动检测内容安全,导出时再做一次标题检测。
还在持续迭代。如果你也在做小程序,欢迎交流踩坑经验——留言我都会回。

老实说,微信的开发者文档写得真的挺烂。同一个 API,开发者社区、官方文档、API 参考三个地方的描述经常不一致——我每次写之前都得三个地方对照一遍,不然心里没底。这种踩坑的成本,本来不应该由开发者承担。但没办法,先接受,再吐槽,再写代码。
有一说一,写小程序的痛苦,写过的人才懂。文档写得烂,调试工具卡,反馈机制慢——官方回复模板永远是"请检查代码是否正确",跟医院前台说"请回家多喝水"一样让人无语。
踩了三个坑,浪费了三天,每一天都在骂自己当初怎么没想到。但项目还得继续,bug 还得修,第二天打开开发者工具,又是个新坑。
愿天下没有不写文档的 API,也没有 bug 修不掉的程序员。


3万+

被折叠的 条评论
为什么被折叠?



