简介这是一份面向微信小程序开发者与个人站长的实用工具箱集合源码基于原生框架开发集成了日期换算、二维码生成、生活查询等常用工具模块方便直接运行并二次扩展。包内共1023个文件主要由273个js逻辑脚本、209个png图标素材、174个wxss样式、172个json配置及171个wxml页面结构构成另有svg、jpg、php等少量辅助文件压缩包仅3.24MB无需服务器和域名即可本地部署。当前已有63人浏览学习。除完整源码外还包含自定义轮播图、第三方小程序跳转引流及流量主广告接入示例开发者可据此快速实现工具聚合、界面定制和商业变现。对于想低成本搭建微信工具应用或学习原生小程序项目结构的读者这份资源具备较高的参考与复用价值。1. 实用工具箱集合的微信小程序源码它能解决什么坑在哪里一套实用工具箱集合的微信小程序源码现在各种渠道里都很常见但你买到的往往不是一个开箱即用的成品而是一套能跑的工程骨架首页入口、工具列表、功能页、公共组件外加一份质量参差不齐的 app.json。这类源码真正值钱的地方是帮你省掉从零搭架构的时间真正让你翻车的点永远是登录态、包体积和审核驳回而不是界面好不好看。它适合两类人要快速给客户交付工具箱类产品的承接者以及想在简历里放一个完整小程序工程的开发者。下面按拿到源码后跑通上线的顺序把该看的目录、该改的参数和该躲的坑过一遍。2. 先读 app.json 再看页面一份工具箱工程骨架的拆解拿到源码包先别急着看页面先打开根目录的 app.json。它决定这个项目能不能跑起来pages 告诉微信开发者工具启动页是哪个tabBar 决定底部导航长什么样subpackages 决定你的包会不会超限。绝大多数工具集合源码翻车不是代码逻辑问题是工程配置没对准你自己的 AppID。2.1 页面路由与 tabBar入口设计决定工具好不好加app.json 是整个项目最先要打开的那一页。常见工具箱工程的 pages 区块长这样{ pages: [ pages/toolbox/index, pages/toolbox/detail, pages/about/index ], window: { navigationBarTitleText: 实用工具箱, navigationBarBackgroundColor: #1f6eff, navigationBarTextStyle: white, backgroundColor: #f5f6fa }, tabBar: { color: #999999, selectedColor: #1f6eff, backgroundColor: #ffffff, borderStyle: black, list: [ { pagePath: pages/toolbox/index, text: 工具 }, { pagePath: pages/about/index, text: 我的 } ] } }pages 数组的第一项就是启动页。工具箱类工程通常把工具列表当首页而不是某个具体工具用户进来 1 秒内能看到功能分区。tabBar 的 list 最多挂 5 个页面但我一般只挂 2 个工具与我的。加一个独立收藏页没必要用户不关心你铲子有几把只关心能不能快速找到要用的那一把。pagePath 必须与 pages 里的路径完全一致否则编译直接报页面未找到这是买到源码后第一个可能遇到的翻车点。窗口配置里的 navigationBarTitleText 会直接显示在每个页面顶部。如果源码还保留着作者的项目名这里要全局替换。实战经验是这类源码交付时经常有几个页面单独设置了 title改完 app.json 还要逐个检查页面 JSON 里的 navigationBarTitleText不然会出现首页叫新名字、二级页面还挂旧名字的尴尬。这里没有捷径全量搜索项目名是最稳的做法。2.2 公共组件与工具页模板复用的是壳不是工具本身看第二样东西components 目录。工具箱集合类源码最常见的代码结构是把每个工具页都做成输入区加结果区加复制按钮的三段式。这个三段式骨架应该抽成一个公共组件而不是在每个页面里重复写十遍。!-- components/tool-page/index.wxml -- view classtool-page view classtool-body slot/slot /view view classtool-result text{{result}}/text button sizemini bindtapcopyResult{{copyText}}/button /view /view组件对应的逻辑文件同样简单// components/tool-page/index.js Component({ properties: { result: { type: String, value: } }, data: { copyText: 复制结果 }, methods: { copyResult() { if (!this.properties.result) { wx.showToast({ title: 暂无可复制内容, icon: none }) return } wx.setClipboardData({ data: this.properties.result, success: () wx.showToast({ title: 已复制, icon: success }) }) } } })关键在 slot 和 properties。slot 留给每个工具自己的输入区比如二维码生成器放一个输入框和按钮计算器放一堆数字按键properties 里的 result 由工具页把计算结果传进来复制逻辑、结果展示、后续要加的数据埋点全部收敛在这个组件里。新加一个工具时从复制这个组件页面开始替换 slot 内部结构就行。顺手提醒一句复制空结果时 wx.showToast 会误报成功正式用要加个判断再复制上面代码里已经处理了。如果源码用的是 behavior 而不是 Component思路一样把公共逻辑抽成 Behavior 混入每个工具页。相比之下我更推荐 Component 加 slot 的方式它在 wxml 层面隔离了输入区和结果区后面做收藏常用工具只需要在组件外层包一个收藏按钮不用逐个改工具页。2.3 选原生还是 uniapp 打包工具箱这类项目我不盲选跨端框架源码包有原生微信小程序和 uniapp 工程两类。原生工程的典型标志是根目录有 app.json、app.js、app.wxssuniapp 工程通常有 src 目录、manifest.json 以及一堆 vue 文件。买源码之前先分清这个不然拿着 uniapp 的源码往微信开发者工具里拖第一眼就是满屏编译错误。uniapp 打包出来的运行文件才能进开发者工具源码本身要用 HBuilderX 或 CLI 跑。我一般不盲选 uniapp原因集中在这个对比里对比维度原生小程序uniapp 打包微信小程序系统能力调用直接 wx.xxx返回数据结构稳定过一层 uni.xxx 封装个别 API 有差异分包控制app.json 直接写 subpackages要在 manifest 里配置报错链路长手机号与登录官方文档示例多搜得到与官方示例对齐慢一点调试微信开发者工具一步到位有时要在 HBuilderX 和开发者工具之间来回切uniapp 横向能发布到支付宝、抖音小程序代价是每端都要单独踩一遍适配。工具箱这种以微信用户为主的场景原生源码拿到手就能在微信开发者工具里跑后续自己加工具或转手交付沟通成本都低很多。我见过有人用 uniapp 做工具箱被 source size exceed max limit 2mb 这种包体积报错折腾了半个下午原因就是 uniapp 运行时要注入运行时相关代码基础体积比原生大分包配置还得双份排查。这类教训多了以后我现在只在明确要同时上 App 和多个小程序端时才选用 uniapp纯微信端一律原生优先。3. 微信小程序登录与手机号获取工具箱到底要不要加、怎么加工具箱集合类源码里登录和手机号是最容易被塞进去、也最容易被骂的功能。很多人买源码时觉得登录是标配于是把按钮挂在首页但工具箱大多是一次性工具用户用完就走强制登录会把留存打得更低。反直觉但真实的结论是这类项目大多数场景不需要用户登录只有当你做云端收藏、历史记录、会员去广告这类功能或者有必须实名才能用的工具时才需要考虑。而真要做就要按微信的规矩来不然审核那关过不去。3.1 什么时候才需要登录先想清楚你的工具箱靠什么运转工具箱的常见形态大概三种本地纯计算工具、带广告的免费工具、会员订阅制工具。其中只有会员订阅和云端同步需要知道用户是谁。如果你只是接了个小单、交付一组工具页面给人看效果那连登录都不用做。给用户免登录体验工具点开即用反而能省掉大量用户拒绝授权时的流失。确定要登录以后优先用 wx.login 静默登录而不是一上来就弹手机号。静默登录用户无感知适合拉登录态、记行为手机号快速验证组件应当放在会员购买、云端同步绑定这种明确操作里。判断标准一句话用户不点这个按钮就用不了核心功能吗如果是才放手机号。微信审核对与小程序功能无关的授权很敏感工具箱类目下尤其容易被问询。3.2 wx.login 最小闭环拿到 code 之后的事才是关键wx.login 本身只有十行代码坑全在后端换 openid 的环节。前端这样写是最常见的做法// pages/about/index.js login() { wx.login({ success: async (res) { if (!res.code) { wx.showToast({ title: 登录失败, icon: none }) return } // code 有效期约 5 分钟且只能使用一次 const { data } await wx.request({ url: https://your-domain.com/api/login, method: POST, data: { code: res.code } }) wx.setStorageSync(token, data.token) } }) }注意三点。第一wx.login 返回的 code 有效期约五分钟且只能用一次用完作废。不要把它存起来等用户下次打开再用每次进入都 login 一次成本很低。第二code 不能在前端直接解出 openid必须由后端拿着 code 去微信接口换因为换出来的 openid 会和你的 AppSecret 绑定AppSecret 一旦出现在前端代码里等于白送。第三wx.login 的成功回调在很多机型上不是必现的要做失败重试比如连续两次失败后提示用户重启小程序。这些都是血泪经验源码里经常只写一个 wx.login 就完事后端根本不给你接好。后端拿到 code 换 openid 后应该自己签发一个业务 token 返回小程序端后续请求都带这个 token。常见的翻车做法是把 openid 直接当 token 用等于把身份证号当门禁卡既不可控也不安全。如果你的源码里出现这种写法记得先改掉再上线。3.3 手机号快速验证从 button 到动态令牌的一整条链路手机号获取现在推荐的是快速验证组件前端代码反而更简单真正的活在后端。按钮写法如下!-- 会员购买页 -- button open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 微信一键绑定手机号 /button对应的事件处理函数// pages/member/index.js async onGetPhoneNumber(e) { if (e.detail.code) { // 动态令牌发给后端换真实手机号 const { data } await wx.request({ url: https://your-domain.com/api/bind-phone, method: POST, data: { code: e.detail.code } }) console.log(data.phone) // 后端返回脱敏后的手机号 } else { wx.showToast({ title: 你取消了授权, icon: none }) } }理解这段代码要先分清两个东西e.detail.code 是微信给你的一次性动态令牌不是明文手机号真实手机号要由后端拿这个 code 调用微信服务端接口去换。前端拿不到手机号明文这是刻意设计防止小程序包被反编译后批量薅用户数据。较新基础库2.21.2 起已经统一走动态令牌模式老代码里如果还有直接返回 encryptedData、iv 让你前端自己解密的写法应该尽早淘汰密钥放前端本身就是漏洞。参数上还有两个硬性要求。一是这个按钮必须由用户主动点击触发用 wx.login 后自动弹窗直取手机号不被允许。二是 button 必须在页面里真实可点不能藏在某个事件回调里用代码触发。我在排查源码时见过把 getPhoneNumber 挂在一个不可见 view 上的操作真机点不到审核也必拒。另一个常见坑开发者工具模拟器里点击没反应或者永远是测试手机号这是正常现象手机号快速验证要求在真机预览或体验版里验证模拟器支持不完整。别因为开发工具里点不出结果就以为是代码拼错了。4. 2MB 主包限制工具集合必然撞上的墙用分包拆工具箱集合比普通小程序更容易撞包体积红线。原因很简单一个工具就是一套页面加一段逻辑堆到二十个工具光是页面文件和引用的组件就能把主包撑满。开发者工具上传时那种 source size 2612kb exceed max limit 2mb 的报错几乎每个做过工具集合的人都被它卡过。这不是代码 bug是微信对主包的硬性限制套路只有一个把不常用的工具丢进分包。4.1 超限之前先看这两块主包和总包的区别微信小程序对包体有两条线主包不能超过 2MB整个小程序主包加所有分包的体积总和上限更高。所以把工具全部塞进一个包里的做法是必死的。正确思路是主包只放所有分包都依赖的东西app.json、公共组件、工具列表首页每个工具页独立成一个分包或按功能归到几个分包。判断一个页面该放主包还是分包的规则我一般这么定启动后 5 秒内要看见的放主包点进去才能用的放分包。工具箱的首页、我的页面、公共组件必须留主包具体工具页只要不是核心主打功能能分则分。做完这一步主包通常会从 2.5MB 掉到 500KB 左右立竿见影。4.2 subpackages 配置一个能直接抄的范例在 app.json 里追加 subpackages 字段即可示例{ pages: [pages/toolbox/index], subpackages: [ { root: tools/qrcode, name: qrcode, pages: [index] }, { root: tools/encode, name: encode, pages: [index, history] } ], preloadRule: { pages/toolbox/index: { network: all, packages: [tools/qrcode] } } }这个配置有三个容易忽略的细节。第一分包页面路径不要写 pages/ 前缀root 是 tools/qrcode 时页面就是 index实际编译后的路径是 tools/qrcode/index所有跳转都要用这个完整路径。第二tabBar 里挂的页面不能进分包上一章的 tab 页面必须留在主包 pages 数组里如果源码把 tab 页挪进分包编译直接报错。第三分包可以引用主包文件反过来不行。公共组件必须放在主包工具分包才能引用它所以 2.2 节那个 tool-page 组件要呆在主包 components 目录下。注意subpackages 的 root 不能以 / 开头也不能写成绝对路径工具页之间的跳转请使用完整分包路径比如 /tools/qrcode/index。preloadRule 是后续优化体验的关键。network 值有 all 和 wifi 两种all 表示不管在什么网络下都预下载wifi 表示只在 Wi-Fi 下预下载。对于用户可能在首页停留很久的工具箱把点击率最高的两三个工具分包配到 preloadRule 里首页加载完后台就开始拉包用户点进工具时白屏时间会明显缩短。流量敏感的运营者会选 wifi我一般对体积小于 100KB 的包直接 all用户等不起那几秒。4.3 图片字体本地依赖是隐形炸弹给你一张瘦身清单分包不是为了让你把 5MB 资源理所当然塞进总包微信对总包一样有上限而且总能被你撑爆。最常见的隐形炸弹是三样工具图标、背景图、自定义字体。我做资源瘦身照着这张表走资源类型常见问题处理方式本地 PNG 图标一张 30KB二十个就 600KB压缩到 WebP 或改用 iconfont 字体背景大图动辄几百 KB 还重复引用换纯色或渐变 CSS小图用网络图自定义字体一个中文字体好几 MB做子集化只保留用到的字符第三方库一个库就几百 KB按需引入别整个 import图片压缩我用 tinypng 一类工具批量处理透明背景图尽量转 WebP字体子集化用 fontmin 这类命令行工具把工具名、标题这些固定文案跑一遍只留用到的字一个 2MB 的字体能压到几十 KB。第三方库是最容易忽视的有的源码为了一个 JSON 格式化功能把整个工具库引进去我见过最夸张的工程里主包一半体积是用不上几个方法的库删掉它比压缩一天图都有效。做这些操作时每删一样东西就真机预览一次避免手滑把某个工具页依赖删掉导致分包里出现找不到模块的运行时错误。这个错误在开发者工具里往往编译期不报直到点进那个工具页才白屏排查起来很费劲。5. 上线前一晚的排查清单导航栏适配、审核驳回与真机差异源码在开发者工具里跑通不等于能上线。我拿到工具箱源码后有个习惯先跑编译再按导航栏、审核、真机三件事过一遍。这三件事恰好是工具集合类源码交付后最常出问题的位置也都是不跑真机看不出来的隐藏坑。5.1 微信小程序顶部导航栏高度不同机型会打脸写死的大小开发者工具里标题栏看起来高度统一一到真机就露馅。iPhone 灵动岛、安卓全面屏、老款 iPhone 的胶囊按钮位置全都不一样如果源码里把自定义导航栏的高度写死成 44px总有一个型号会顶到状态栏里。正确做法是运行时取胶囊按钮坐标来反推导航栏高度// app.js 或导航栏组件里 const sysInfo wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync() const { statusBarHeight } sysInfo const menuRect wx.getMenuButtonBoundingClientRect() const navBarHeight (menuRect.top - statusBarHeight) * 2 menuRect.height this.setData({ statusBarHeight, navBarHeight })原理是胶囊按钮在导航栏里垂直居中所以导航栏高度等于胶囊顶部到状态栏底部的距离乘 2再加胶囊自身高度。这段代码建议放进公共组件一次算好而不是每个页面各自取一次避免页面切换时顶部闪变。wx.getMenuButtonBoundingClientRect 在某些安卓低版本上拿不到合法矩形返回值是空的所以上面用 wx.getWindowInfo 先兜底拿状态栏高度拿不到胶囊信息时再退回固定值这是必要的降级处理不然会在 App 启动早期直接报错。另一个连带的坑是 iPhone 底部安全区。工具箱做 tabBar 或自定义底部栏时要留出 home indicator 的位置常见做法是在相关容器上使用 env(safe-area-inset-bottom)。源码如果还是写死 bottom: 0iPhone 14 之后的机型底部会被手势条压住按钮用户点不到最后一行工具。5.2 工具类目的审核驳回一半不是代码问题工具箱被驳回十次里有五次不是代码问题是类目和隐私声明。现象是提交审核后站内信给出小程序涉及的功能与所选类目不符或者请补充用户隐私保护指引。原因也简单工具类目能承载的功能范围有限比如带有查询、信息展示性质的工具部分子类要提供对应资质而凡是你用了 wx.login 或 getPhoneNumber就必须在微信公众平台后台的用户隐私保护指引里如实声明收集的信息类型和用途。解决方式是上线前就逐项核对在微信公众平台的服务类目里确认所选类目覆盖所有工具的功能在用户隐私保护指引里把手机号、性别等每一项都勾真实用到的用途写法具体到用于会员账号绑定别写用于提升用户体验这种空话。我自己遇到过一次驳回就是因为源码里带了 getPhoneNumber 但隐私指引没勾手机号这一项。代码没动后台配置补上第二次提交就过了。这类配置问题不需要改源码但改完要重新上传代码版本所以建议收集信息的功能做完就一起配好别拖到被驳回再补。5.3 模拟器与真机不一致的三个具体例子工具箱高度依赖系统能力模拟器和真机的差异会被放大这里列三个常见的。第一录音文件格式。模拟器里录音 API 返回的文件格式是假的经常给你一个 mp3到真机上你发现是 m4a后端解析地址直接挂。凡是做语音类工具必须在真机预览里跑一遍录音、上传、播放闭环并且代码里不要硬编码后缀名用拿到的临时文件名去推断格式。第二canvas 导出图片。旧版 canvas API 在部分安卓真机上导出图片偶尔返回一张全黑图模拟器却一切正常。解决是改用 canvas 2d 接口并等待绘制完成回调后再 wx.canvasToTempFilePath导出前先确认绘制已提交。注意 iOS 和安卓对 canvas 尺寸上限的容忍度不一样大尺寸导出在低端安卓上更容易失败。第三手机号快速验证组件。模拟器点击能弹成功但返回的是测试环境数据真机上才是真实链路。另外部分安卓机型对 getPhoneNumber 按钮的点击区域处理异常button 外部包了一层 view 时偶尔会出现点击穿透到 view 导致事件丢失。处理方式是让 button 尽量独立、不嵌套样式上用宽高度控制避免外层容器挡事件。这三个例子有个共同教训工具箱源码在模拟器上跑得再顺都只能算能编译不能算能上线。6. 把工具箱当成能生长的框架加工具的套路和验收习惯工具集合源码的价值在可扩展性。我接手这类工程后的习惯是把所有工具入口收敛成一个配置数组而不是每个页面各自写死一个入口。工具箱首页遍历这个数组渲染列表每加一个工具只需在数组里追加一项再在分包下新建一个工具页。入口数据格式类似{ name: 二维码生成, icon: /assets/qrcode.png, path: /tools/qrcode/index }。这样加工具只动两处一处是配置数组一处是分包页面其他地方一概不用碰。加完工具还要会用 preloadRule 做体验兜底。我会把扫码工具和二维码生成这类会伴随出现的小包用 preloadRule 绑在一起用户从首页点进其中一个时另一个已经在后台等着了。配合上一章的分包配置工具的加载白屏可以压到几乎无感。验收时我分三档先在开发者工具的代码依赖分析面板看主包体积超过 1.5MB 就继续瘦身再用体验版在真机上全点一遍所有工具重点看录音、canvas、手机号这几个真机敏感功能最后清掉开发者工具里的缓存再进一遍首页确认分包预下载没有把有限流量浪费在冷门工具上。这套流程走完源码才算真正属于你。做的时间长了我把这行当的教训收成一句话拿到源码别急着加功能先看包结构定好分不包、入不入登录再动代码。早期我为了省事把所有工具堆在主包上线前看着 2MB 报错连夜拆包那种感觉不太想再来一次。希望你不用重走这条弯路按上面的顺序拆能在半天内把一套陌生工具箱变成能上线的产品。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 15:37:16 · 阅读 1.2k 微信小程序工具箱源码实战：从配置分包到上线避坑指南
简介这是一份面向微信小程序开发者与个人站长的实用工具箱集合源码基于原生框架开发集成了日期换算、二维码生成、生活查询等常用工具模块方便直接运行并二次扩展。包内共1023个文件主要由273个js逻辑脚本、209个png图标素材、174个wxss样式、172个json配置及171个wxml页面结构构成另有svg、jpg、php等少量辅助文件压缩包仅3.24MB无需服务器和域名即可本地部署。当前已有63人浏览学习。除完整源码外还包含自定义轮播图、第三方小程序跳转引流及流量主广告接入示例开发者可据此快速实现工具聚合、界面定制和商业变现。对于想低成本搭建微信工具应用或学习原生小程序项目结构的读者这份资源具备较高的参考与复用价值。1. 实用工具箱集合的微信小程序源码它能解决什么坑在哪里一套实用工具箱集合的微信小程序源码现在各种渠道里都很常见但你买到的往往不是一个开箱即用的成品而是一套能跑的工程骨架首页入口、工具列表、功能页、公共组件外加一份质量参差不齐的 app.json。这类源码真正值钱的地方是帮你省掉从零搭架构的时间真正让你翻车的点永远是登录态、包体积和审核驳回而不是界面好不好看。它适合两类人要快速给客户交付工具箱类产品的承接者以及想在简历里放一个完整小程序工程的开发者。下面按拿到源码后跑通上线的顺序把该看的目录、该改的参数和该躲的坑过一遍。2. 先读 app.json 再看页面一份工具箱工程骨架的拆解拿到源码包先别急着看页面先打开根目录的 app.json。它决定这个项目能不能跑起来pages 告诉微信开发者工具启动页是哪个tabBar 决定底部导航长什么样subpackages 决定你的包会不会超限。绝大多数工具集合源码翻车不是代码逻辑问题是工程配置没对准你自己的 AppID。2.1 页面路由与 tabBar入口设计决定工具好不好加app.json 是整个项目最先要打开的那一页。常见工具箱工程的 pages 区块长这样{ pages: [ pages/toolbox/index, pages/toolbox/detail, pages/about/index ], window: { navigationBarTitleText: 实用工具箱, navigationBarBackgroundColor: #1f6eff, navigationBarTextStyle: white, backgroundColor: #f5f6fa }, tabBar: { color: #999999, selectedColor: #1f6eff, backgroundColor: #ffffff, borderStyle: black, list: [ { pagePath: pages/toolbox/index, text: 工具 }, { pagePath: pages/about/index, text: 我的 } ] } }pages 数组的第一项就是启动页。工具箱类工程通常把工具列表当首页而不是某个具体工具用户进来 1 秒内能看到功能分区。tabBar 的 list 最多挂 5 个页面但我一般只挂 2 个工具与我的。加一个独立收藏页没必要用户不关心你铲子有几把只关心能不能快速找到要用的那一把。pagePath 必须与 pages 里的路径完全一致否则编译直接报页面未找到这是买到源码后第一个可能遇到的翻车点。窗口配置里的 navigationBarTitleText 会直接显示在每个页面顶部。如果源码还保留着作者的项目名这里要全局替换。实战经验是这类源码交付时经常有几个页面单独设置了 title改完 app.json 还要逐个检查页面 JSON 里的 navigationBarTitleText不然会出现首页叫新名字、二级页面还挂旧名字的尴尬。这里没有捷径全量搜索项目名是最稳的做法。2.2 公共组件与工具页模板复用的是壳不是工具本身看第二样东西components 目录。工具箱集合类源码最常见的代码结构是把每个工具页都做成输入区加结果区加复制按钮的三段式。这个三段式骨架应该抽成一个公共组件而不是在每个页面里重复写十遍。!-- components/tool-page/index.wxml -- view classtool-page view classtool-body slot/slot /view view classtool-result text{{result}}/text button sizemini bindtapcopyResult{{copyText}}/button /view /view组件对应的逻辑文件同样简单// components/tool-page/index.js Component({ properties: { result: { type: String, value: } }, data: { copyText: 复制结果 }, methods: { copyResult() { if (!this.properties.result) { wx.showToast({ title: 暂无可复制内容, icon: none }) return } wx.setClipboardData({ data: this.properties.result, success: () wx.showToast({ title: 已复制, icon: success }) }) } } })关键在 slot 和 properties。slot 留给每个工具自己的输入区比如二维码生成器放一个输入框和按钮计算器放一堆数字按键properties 里的 result 由工具页把计算结果传进来复制逻辑、结果展示、后续要加的数据埋点全部收敛在这个组件里。新加一个工具时从复制这个组件页面开始替换 slot 内部结构就行。顺手提醒一句复制空结果时 wx.showToast 会误报成功正式用要加个判断再复制上面代码里已经处理了。如果源码用的是 behavior 而不是 Component思路一样把公共逻辑抽成 Behavior 混入每个工具页。相比之下我更推荐 Component 加 slot 的方式它在 wxml 层面隔离了输入区和结果区后面做收藏常用工具只需要在组件外层包一个收藏按钮不用逐个改工具页。2.3 选原生还是 uniapp 打包工具箱这类项目我不盲选跨端框架源码包有原生微信小程序和 uniapp 工程两类。原生工程的典型标志是根目录有 app.json、app.js、app.wxssuniapp 工程通常有 src 目录、manifest.json 以及一堆 vue 文件。买源码之前先分清这个不然拿着 uniapp 的源码往微信开发者工具里拖第一眼就是满屏编译错误。uniapp 打包出来的运行文件才能进开发者工具源码本身要用 HBuilderX 或 CLI 跑。我一般不盲选 uniapp原因集中在这个对比里对比维度原生小程序uniapp 打包微信小程序系统能力调用直接 wx.xxx返回数据结构稳定过一层 uni.xxx 封装个别 API 有差异分包控制app.json 直接写 subpackages要在 manifest 里配置报错链路长手机号与登录官方文档示例多搜得到与官方示例对齐慢一点调试微信开发者工具一步到位有时要在 HBuilderX 和开发者工具之间来回切uniapp 横向能发布到支付宝、抖音小程序代价是每端都要单独踩一遍适配。工具箱这种以微信用户为主的场景原生源码拿到手就能在微信开发者工具里跑后续自己加工具或转手交付沟通成本都低很多。我见过有人用 uniapp 做工具箱被 source size exceed max limit 2mb 这种包体积报错折腾了半个下午原因就是 uniapp 运行时要注入运行时相关代码基础体积比原生大分包配置还得双份排查。这类教训多了以后我现在只在明确要同时上 App 和多个小程序端时才选用 uniapp纯微信端一律原生优先。3. 微信小程序登录与手机号获取工具箱到底要不要加、怎么加工具箱集合类源码里登录和手机号是最容易被塞进去、也最容易被骂的功能。很多人买源码时觉得登录是标配于是把按钮挂在首页但工具箱大多是一次性工具用户用完就走强制登录会把留存打得更低。反直觉但真实的结论是这类项目大多数场景不需要用户登录只有当你做云端收藏、历史记录、会员去广告这类功能或者有必须实名才能用的工具时才需要考虑。而真要做就要按微信的规矩来不然审核那关过不去。3.1 什么时候才需要登录先想清楚你的工具箱靠什么运转工具箱的常见形态大概三种本地纯计算工具、带广告的免费工具、会员订阅制工具。其中只有会员订阅和云端同步需要知道用户是谁。如果你只是接了个小单、交付一组工具页面给人看效果那连登录都不用做。给用户免登录体验工具点开即用反而能省掉大量用户拒绝授权时的流失。确定要登录以后优先用 wx.login 静默登录而不是一上来就弹手机号。静默登录用户无感知适合拉登录态、记行为手机号快速验证组件应当放在会员购买、云端同步绑定这种明确操作里。判断标准一句话用户不点这个按钮就用不了核心功能吗如果是才放手机号。微信审核对与小程序功能无关的授权很敏感工具箱类目下尤其容易被问询。3.2 wx.login 最小闭环拿到 code 之后的事才是关键wx.login 本身只有十行代码坑全在后端换 openid 的环节。前端这样写是最常见的做法// pages/about/index.js login() { wx.login({ success: async (res) { if (!res.code) { wx.showToast({ title: 登录失败, icon: none }) return } // code 有效期约 5 分钟且只能使用一次 const { data } await wx.request({ url: https://your-domain.com/api/login, method: POST, data: { code: res.code } }) wx.setStorageSync(token, data.token) } }) }注意三点。第一wx.login 返回的 code 有效期约五分钟且只能用一次用完作废。不要把它存起来等用户下次打开再用每次进入都 login 一次成本很低。第二code 不能在前端直接解出 openid必须由后端拿着 code 去微信接口换因为换出来的 openid 会和你的 AppSecret 绑定AppSecret 一旦出现在前端代码里等于白送。第三wx.login 的成功回调在很多机型上不是必现的要做失败重试比如连续两次失败后提示用户重启小程序。这些都是血泪经验源码里经常只写一个 wx.login 就完事后端根本不给你接好。后端拿到 code 换 openid 后应该自己签发一个业务 token 返回小程序端后续请求都带这个 token。常见的翻车做法是把 openid 直接当 token 用等于把身份证号当门禁卡既不可控也不安全。如果你的源码里出现这种写法记得先改掉再上线。3.3 手机号快速验证从 button 到动态令牌的一整条链路手机号获取现在推荐的是快速验证组件前端代码反而更简单真正的活在后端。按钮写法如下!-- 会员购买页 -- button open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 微信一键绑定手机号 /button对应的事件处理函数// pages/member/index.js async onGetPhoneNumber(e) { if (e.detail.code) { // 动态令牌发给后端换真实手机号 const { data } await wx.request({ url: https://your-domain.com/api/bind-phone, method: POST, data: { code: e.detail.code } }) console.log(data.phone) // 后端返回脱敏后的手机号 } else { wx.showToast({ title: 你取消了授权, icon: none }) } }理解这段代码要先分清两个东西e.detail.code 是微信给你的一次性动态令牌不是明文手机号真实手机号要由后端拿这个 code 调用微信服务端接口去换。前端拿不到手机号明文这是刻意设计防止小程序包被反编译后批量薅用户数据。较新基础库2.21.2 起已经统一走动态令牌模式老代码里如果还有直接返回 encryptedData、iv 让你前端自己解密的写法应该尽早淘汰密钥放前端本身就是漏洞。参数上还有两个硬性要求。一是这个按钮必须由用户主动点击触发用 wx.login 后自动弹窗直取手机号不被允许。二是 button 必须在页面里真实可点不能藏在某个事件回调里用代码触发。我在排查源码时见过把 getPhoneNumber 挂在一个不可见 view 上的操作真机点不到审核也必拒。另一个常见坑开发者工具模拟器里点击没反应或者永远是测试手机号这是正常现象手机号快速验证要求在真机预览或体验版里验证模拟器支持不完整。别因为开发工具里点不出结果就以为是代码拼错了。4. 2MB 主包限制工具集合必然撞上的墙用分包拆工具箱集合比普通小程序更容易撞包体积红线。原因很简单一个工具就是一套页面加一段逻辑堆到二十个工具光是页面文件和引用的组件就能把主包撑满。开发者工具上传时那种 source size 2612kb exceed max limit 2mb 的报错几乎每个做过工具集合的人都被它卡过。这不是代码 bug是微信对主包的硬性限制套路只有一个把不常用的工具丢进分包。4.1 超限之前先看这两块主包和总包的区别微信小程序对包体有两条线主包不能超过 2MB整个小程序主包加所有分包的体积总和上限更高。所以把工具全部塞进一个包里的做法是必死的。正确思路是主包只放所有分包都依赖的东西app.json、公共组件、工具列表首页每个工具页独立成一个分包或按功能归到几个分包。判断一个页面该放主包还是分包的规则我一般这么定启动后 5 秒内要看见的放主包点进去才能用的放分包。工具箱的首页、我的页面、公共组件必须留主包具体工具页只要不是核心主打功能能分则分。做完这一步主包通常会从 2.5MB 掉到 500KB 左右立竿见影。4.2 subpackages 配置一个能直接抄的范例在 app.json 里追加 subpackages 字段即可示例{ pages: [pages/toolbox/index], subpackages: [ { root: tools/qrcode, name: qrcode, pages: [index] }, { root: tools/encode, name: encode, pages: [index, history] } ], preloadRule: { pages/toolbox/index: { network: all, packages: [tools/qrcode] } } }这个配置有三个容易忽略的细节。第一分包页面路径不要写 pages/ 前缀root 是 tools/qrcode 时页面就是 index实际编译后的路径是 tools/qrcode/index所有跳转都要用这个完整路径。第二tabBar 里挂的页面不能进分包上一章的 tab 页面必须留在主包 pages 数组里如果源码把 tab 页挪进分包编译直接报错。第三分包可以引用主包文件反过来不行。公共组件必须放在主包工具分包才能引用它所以 2.2 节那个 tool-page 组件要呆在主包 components 目录下。注意subpackages 的 root 不能以 / 开头也不能写成绝对路径工具页之间的跳转请使用完整分包路径比如 /tools/qrcode/index。preloadRule 是后续优化体验的关键。network 值有 all 和 wifi 两种all 表示不管在什么网络下都预下载wifi 表示只在 Wi-Fi 下预下载。对于用户可能在首页停留很久的工具箱把点击率最高的两三个工具分包配到 preloadRule 里首页加载完后台就开始拉包用户点进工具时白屏时间会明显缩短。流量敏感的运营者会选 wifi我一般对体积小于 100KB 的包直接 all用户等不起那几秒。4.3 图片字体本地依赖是隐形炸弹给你一张瘦身清单分包不是为了让你把 5MB 资源理所当然塞进总包微信对总包一样有上限而且总能被你撑爆。最常见的隐形炸弹是三样工具图标、背景图、自定义字体。我做资源瘦身照着这张表走资源类型常见问题处理方式本地 PNG 图标一张 30KB二十个就 600KB压缩到 WebP 或改用 iconfont 字体背景大图动辄几百 KB 还重复引用换纯色或渐变 CSS小图用网络图自定义字体一个中文字体好几 MB做子集化只保留用到的字符第三方库一个库就几百 KB按需引入别整个 import图片压缩我用 tinypng 一类工具批量处理透明背景图尽量转 WebP字体子集化用 fontmin 这类命令行工具把工具名、标题这些固定文案跑一遍只留用到的字一个 2MB 的字体能压到几十 KB。第三方库是最容易忽视的有的源码为了一个 JSON 格式化功能把整个工具库引进去我见过最夸张的工程里主包一半体积是用不上几个方法的库删掉它比压缩一天图都有效。做这些操作时每删一样东西就真机预览一次避免手滑把某个工具页依赖删掉导致分包里出现找不到模块的运行时错误。这个错误在开发者工具里往往编译期不报直到点进那个工具页才白屏排查起来很费劲。5. 上线前一晚的排查清单导航栏适配、审核驳回与真机差异源码在开发者工具里跑通不等于能上线。我拿到工具箱源码后有个习惯先跑编译再按导航栏、审核、真机三件事过一遍。这三件事恰好是工具集合类源码交付后最常出问题的位置也都是不跑真机看不出来的隐藏坑。5.1 微信小程序顶部导航栏高度不同机型会打脸写死的大小开发者工具里标题栏看起来高度统一一到真机就露馅。iPhone 灵动岛、安卓全面屏、老款 iPhone 的胶囊按钮位置全都不一样如果源码里把自定义导航栏的高度写死成 44px总有一个型号会顶到状态栏里。正确做法是运行时取胶囊按钮坐标来反推导航栏高度// app.js 或导航栏组件里 const sysInfo wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync() const { statusBarHeight } sysInfo const menuRect wx.getMenuButtonBoundingClientRect() const navBarHeight (menuRect.top - statusBarHeight) * 2 menuRect.height this.setData({ statusBarHeight, navBarHeight })原理是胶囊按钮在导航栏里垂直居中所以导航栏高度等于胶囊顶部到状态栏底部的距离乘 2再加胶囊自身高度。这段代码建议放进公共组件一次算好而不是每个页面各自取一次避免页面切换时顶部闪变。wx.getMenuButtonBoundingClientRect 在某些安卓低版本上拿不到合法矩形返回值是空的所以上面用 wx.getWindowInfo 先兜底拿状态栏高度拿不到胶囊信息时再退回固定值这是必要的降级处理不然会在 App 启动早期直接报错。另一个连带的坑是 iPhone 底部安全区。工具箱做 tabBar 或自定义底部栏时要留出 home indicator 的位置常见做法是在相关容器上使用 env(safe-area-inset-bottom)。源码如果还是写死 bottom: 0iPhone 14 之后的机型底部会被手势条压住按钮用户点不到最后一行工具。5.2 工具类目的审核驳回一半不是代码问题工具箱被驳回十次里有五次不是代码问题是类目和隐私声明。现象是提交审核后站内信给出小程序涉及的功能与所选类目不符或者请补充用户隐私保护指引。原因也简单工具类目能承载的功能范围有限比如带有查询、信息展示性质的工具部分子类要提供对应资质而凡是你用了 wx.login 或 getPhoneNumber就必须在微信公众平台后台的用户隐私保护指引里如实声明收集的信息类型和用途。解决方式是上线前就逐项核对在微信公众平台的服务类目里确认所选类目覆盖所有工具的功能在用户隐私保护指引里把手机号、性别等每一项都勾真实用到的用途写法具体到用于会员账号绑定别写用于提升用户体验这种空话。我自己遇到过一次驳回就是因为源码里带了 getPhoneNumber 但隐私指引没勾手机号这一项。代码没动后台配置补上第二次提交就过了。这类配置问题不需要改源码但改完要重新上传代码版本所以建议收集信息的功能做完就一起配好别拖到被驳回再补。5.3 模拟器与真机不一致的三个具体例子工具箱高度依赖系统能力模拟器和真机的差异会被放大这里列三个常见的。第一录音文件格式。模拟器里录音 API 返回的文件格式是假的经常给你一个 mp3到真机上你发现是 m4a后端解析地址直接挂。凡是做语音类工具必须在真机预览里跑一遍录音、上传、播放闭环并且代码里不要硬编码后缀名用拿到的临时文件名去推断格式。第二canvas 导出图片。旧版 canvas API 在部分安卓真机上导出图片偶尔返回一张全黑图模拟器却一切正常。解决是改用 canvas 2d 接口并等待绘制完成回调后再 wx.canvasToTempFilePath导出前先确认绘制已提交。注意 iOS 和安卓对 canvas 尺寸上限的容忍度不一样大尺寸导出在低端安卓上更容易失败。第三手机号快速验证组件。模拟器点击能弹成功但返回的是测试环境数据真机上才是真实链路。另外部分安卓机型对 getPhoneNumber 按钮的点击区域处理异常button 外部包了一层 view 时偶尔会出现点击穿透到 view 导致事件丢失。处理方式是让 button 尽量独立、不嵌套样式上用宽高度控制避免外层容器挡事件。这三个例子有个共同教训工具箱源码在模拟器上跑得再顺都只能算能编译不能算能上线。6. 把工具箱当成能生长的框架加工具的套路和验收习惯工具集合源码的价值在可扩展性。我接手这类工程后的习惯是把所有工具入口收敛成一个配置数组而不是每个页面各自写死一个入口。工具箱首页遍历这个数组渲染列表每加一个工具只需在数组里追加一项再在分包下新建一个工具页。入口数据格式类似{ name: 二维码生成, icon: /assets/qrcode.png, path: /tools/qrcode/index }。这样加工具只动两处一处是配置数组一处是分包页面其他地方一概不用碰。加完工具还要会用 preloadRule 做体验兜底。我会把扫码工具和二维码生成这类会伴随出现的小包用 preloadRule 绑在一起用户从首页点进其中一个时另一个已经在后台等着了。配合上一章的分包配置工具的加载白屏可以压到几乎无感。验收时我分三档先在开发者工具的代码依赖分析面板看主包体积超过 1.5MB 就继续瘦身再用体验版在真机上全点一遍所有工具重点看录音、canvas、手机号这几个真机敏感功能最后清掉开发者工具里的缓存再进一遍首页确认分包预下载没有把有限流量浪费在冷门工具上。这套流程走完源码才算真正属于你。做的时间长了我把这行当的教训收成一句话拿到源码别急着加功能先看包结构定好分不包、入不入登录再动代码。早期我为了省事把所有工具堆在主包上线前看着 2MB 报错连夜拆包那种感觉不太想再来一次。希望你不用重走这条弯路按上面的顺序拆能在半天内把一套陌生工具箱变成能上线的产品。希望帮到你。本文还有配套的精品资源点击获取