我最近用WorkBuddy做了一款微信小程序从对话式生成代码到提交审核、最终在微信正式上线完整跑通了一个周期。这篇想把整个过程记录下来我是怎么和WorkBuddy协作的、微信登录和手机号获取到底怎么实现、备案审核有哪些坑以及我在真机调试和抓包排错中踩过的具体问题。如果你正打算用WorkBuddy这类AI编程工具做小程序但对微信生态不太熟这篇文章应该能帮你省下不少时间。1. 先聊聊WorkBuddy它凭什么把小程序的开发节奏拉起来1.1 WorkBuddy到底帮我把什么活干了先说结论WorkBuddy在我这个项目里扮演的角色不是单纯帮你补全函数的代码补全工具而是能听懂整个项目上下文、直接生成可运行工程的全栈工作台。我在对话里告诉它“做一个2048小游戏风格的积分兑换小程序”“首页要轮播图和商品分类”“登录要支持微信手机号授权”它就把小程序的原生工程骨架、页面、组件、样式、云函数一次性生成了。这一点很关键。传统开发一个小程序哪怕是一个简单商城至少也要经历注册项目、配置AppID、搭全局样式、封装请求库、设计页面结构、写交互逻辑。这串动作以前要按天算WorkBuddy这一步让我按小时算。我实际体验下来它的优势在于三点第一上下文连续。我改了个页面结构再让它调整对应的数据字段它不会忘了之前生成的组件名和页面路径这种连贯性决定了大工程能不能用AI做。第二贴近微信生态。它生成的小程序代码用的是原生WXML/WXSS/JS/JSON不是随便写个网页来糊弄这保证了后面导入微信开发者工具可以直接跑起来。第三能帮我查报错。开发和调试过程中最烦的就是编译报错尤其是一些小程序特有的问题比如组件路径写错、app.json里页面注册遗漏、基础库API不兼容。我把报错信息粘给WorkBuddy它大多数时候能直接指出问题出在哪个文件哪一行。1.2 它的边界在哪里我仍然需要懂什么但我要泼一盆冷水WorkBuddy再强也只是把“写代码”这件事加速了“懂微信这套规则”这件事没人能替你完成。我在项目里体会最深的是如果不了解微信小程序的底层机制你连问题都描述不准AI生成的东西也容易方向跑偏。比如小程序里“登录”这件事跟web开发完全是两个逻辑。web登录靠session、cookie小程序靠的是wx.login拿code、再换openid/session_key。再比如小程序对接口域名有强制要求——必须是HTTPS、必须在后台配置白名单再比如用户隐私保护指引没配置好提审直接被拒。这些规则我不会再花时间给AI解释因为它懂但用不用、怎么用得我把关。所以我的定位是WorkBuddy是主力编码员我当架构师和验收员。项目的整体结构、数据安全、合规审核这些我盯具体页面、具体函数、样式布局交给它写。我验收的节奏是每生成一个模块就拿到微信开发者工具里跑一遍而不是攒到最后再看。2. 从一句话需求到工程骨架我和WorkBuddy的真实协作方式2.1 需求描述怎么写AI才不会跑偏很多人用AI生成代码失败问题几乎都出在需求描述上。你给一句“帮我做个商城”出来的东西只能是模板味十足的示例因为它不知道你要卖什么、给谁用、有没有后台、有没有支付、有没有积分。我在需求阶段用了两板斧第一板斧把场景说清楚。我写的不是“小程序商城”而是“一个面向社区团购场景的微信小程序用户进入首页看到今日推荐商品点击商品进入详情页可以加入购物车下单时支持微信手机号快速授权后台用微信云开发存储订单数据管理员在小程序里可以查看订单列表。”第二板斧给参考物。我把自己比较喜欢的两个小程序的页面截图发给WorkBuddy告诉它“首页的布局风格接近这种分类导航要横向滚动”。AI对文字描述的理解是有限的但有截图参考时生成的页面结构和视觉风格会明显更贴合预期。这里有一个非常关键的经验让AI先出页面树再写代码。我让WorkBuddy先把小程序包含哪些页面、每个页面有哪些模块、模块之间怎么跳转列出来等我确认了页面树再让它逐个页面生成。如果一上来就让它写全部代码后期改结构成本和理解成本都很高。2.2 原生小程序还是uni-app我最后为什么选原生当时摆在我面前的有两个方案让WorkBuddy生成原生小程序工程或者生成uni-app工程再打包成小程序。这两个方案我都试过最终选了原生小程序理由有三个一是上线路径最短。原生小程序工程生成后直接用微信开发者工具打开就能编译预览不需要转译和打包那一层出问题排查起来少一个环节。二是微信能力覆盖最全。有些比较新的API和小程序插件在uni-app里可能需要额外适配和封装原生小程序是第一时间同步的。比如手机号快速验证组件、最新的隐私接口声明原生环境下踩坑少。三是AI对原生代码的生产效率更高。WorkBuddy在生成原生WXML/WXSS/JS/JSON方面的训练数据显然比多端框架更充足代码写出来更地道Bug也更容易修。当然如果你明确要做支付宝小程序、抖音小程序多端发布那uni-app还是值得考虑的。但如果你就是冲着微信上线来的我建议不要绕路。WorkBuddy生成完工程后导入微信开发者工具时页面会提示选择AppID我填的是自己已注册的小程序AppID编译后直接把基础库和调试器跑起来看效果。3. 核心功能落地的三条线登录、数据、页面细节3.1 微信登录与手机号获取的完整链路这一部分是搜“微信小程序登录获取手机号”最关心的技术点。先说明微信这几年把手机号获取的接口升级过现在推荐用的是手机号快速验证组件也就是通过button组件的open-type弹授权框直接从微信侧拿到一个code再把code交给后端调用官方接口换取手机号。前端代码很简单button open-typegetPhoneNumber bindgetphonenumberhandleGetPhoneNumber 授权获取手机号 /buttonPage({ handleGetPhoneNumber(e) { if (!e.detail.code) { wx.showToast({ title: 您取消了授权, icon: none }) return } // 把code传给后端/云函数 wx.cloud.callFunction({ name: getPhoneNumber, data: { code: e.detail.code } }).then(res { const { phoneNumber } res.result console.log(手机号, phoneNumber) }) } })后端用云函数实现更简单因为微信云开发开放能力里直接封装了接口// 云函数 getPhoneNumber/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main async (event) { const { code } event const res await cloud.openapi.phonenumber.getPhoneNumber({ code }) return res }这个流程里有个容易踩坑的地方e.detail.code只能用一次而且有效期很短。调试时如果后端没调到接口就刷新页面这个code就废掉了需要重新触发授权。所以前端要在拿到code后立刻发给后端不能中途做太多无关逻辑。再说说旧版流程搜“微信数据库解密”时很多人其实说的是这个。早期版本获取手机号或用户信息返回的是encryptedData和iv需要后端拿session_key做AES解密// 旧接口加解密原理现在已逐步废弃 const crypto require(crypto) function decryptPhoneNumber(sessionKey, encryptedData, iv) { const key Buffer.from(sessionKey, base64) const decipher crypto.createDecipheriv(aes-128-cbc, key, Buffer.from(iv, base64)) decipher.setAutoPadding(true) let decoded decipher.update(encryptedData, base64, utf8) decoded decipher.final(utf8) return JSON.parse(decoded) }新接口把解密这一步放到微信官方服务端了对开发者更安全也省了很多事。但理解这个加解密过程仍然有价值因为你在排查问题的时候看到“解密失败”“session_key错误”这类报错至少知道源头在哪。顺带提醒一句微信小程序的本地缓存Storage默认是不加密的这个“数据库解密”不能碰任何敏感数据都不应该明文放进Storage手机号、openid、用户的业务隐私数据都应该存在服务端需要时再取。3.2 服务端接口与本地缓存的交互设计小程序前后端交互我直接用了微信云开发好处是不需要自己买服务器、配域名、搞HTTPS证书。WorkBuddy对云开发的生成支持也比较成熟数据库集合、云函数、调用API这一整套都能直接生成。我的项目里做了这样几个关键设计第一请求统一封装。所有前端到云函数的调用都走一个request工具统一处理loading状态、错误提示、成功数据解包。这样代码里不会到处都是wx.cloud.callFunction后期出了问题也只需要改一个文件。第二登录态与用户数据分离。登录成功后后端返回给前端的是业务token或openid手机号只保存在云数据库的用户集合里不随着每个接口返回。这样即便是抓包看流量也看不到敏感信息。第三本地缓存只存非敏感的状态数据。比如用户浏览记录、草稿内容、接口返回的非敏感配置数据。token如果必须缓存也要做有效期控制每次启动小程序时校验一遍。在这个环节我犯过一个错一开始把用户手机号直接放到了storage里还开了缓存理由是“下次进来不用再授权”。后来提审时被微信的隐私合规检测抓到要求整改。这个教训说明两个事一是个人信息保护不是一句口号平台审核是真会查的二是作为开发者你脑子里要有一根弦——能不上传的就不上传能不缓存的不缓存。3.3 页面细节导航栏高度、动态标题、单选框这些看似不起眼的点页面细节决定一个小程序用起来像不像正经产品。这里说三个我实际处理过的点正好也都是大家高频搜索的问题。第一个是导航栏高度适配。如果你用了自定义导航栏就不能把顶部组件写死在一个固定值上因为不同机型的statusBar高度不一样尤其是有刘海的iPhone和全面屏安卓。WorkBuddy生成代码时给我留了标准适配方案const { statusBarHeight, windowWidth } wx.getSystemInfoSync() const menuButton wx.getMenuButtonBoundingClientRect() const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height这段代码的意思是把胶囊按钮的位置作为导航栏高度的锚点不管什么机型导航栏都刚好顶到胶囊按钮上方视觉上不会歪。在做自定义导航栏时一定要用到这一手。第二个是动态设置页面标题。小程序标题不只是app.json里配一次就完了很多时候要根据页面内容实时变。比如商品详情页要显示商品名积分商城页要显示实时活动名。小程序的API给了现成方法wx.setNavigationBarTitle({ title: product.name })用这个方法时要注意它只对当前页面生效页面切走后就恢复默认配置了所以需要在onShow或数据加载完成后再调用不要在onLoad里过早执行。第三个是单选框的样式定制。小程序原生的radio组件在不同平台表现有差异iOS和安卓的选中态画风不同单独写样式又容易覆盖不成功。我的处理办法是把radio的value绑定到业务数据用color属性统一选中色外层包label提升点击范围同时为不同选项设置独立的checked状态radio-group bindchangehandleTypeChange label wx:for{{types}} wx:keyvalue classtype-item radio value{{item.value}} checked{{item.checked}} color#07c160 / text{{item.name}}/text /label /radio-group说实话这些细节如果不专门处理功能也能跑但用户感受完全不一样。定制导航栏让页面更像原生应用动态标题让信息传达更准确单选框的点击热区更符合手指操作习惯。WorkBuddy能生成功能代码但这些“产品感”的部分还是需要我人工确认。4. 真机调试与抓包排查上线前最花时间的那个坎4.1 微信开发者工具里的配置细节WorkBuddy生成的工程导入微信开发者工具的路径是下载微信开发者工具稳定版就可以→ 导入项目 → 目录选择工程文件夹 → 填写自己的小程序AppID。这里有几个配置细节搞错了会浪费大量调试时间。第一个是**“不校验合法域名”开关**。开发阶段如果你还没在小程序后台配置request合法域名工具和真机都会因为域名不在白名单里拒绝请求。开发者工具左上角“详情→本地设置”里可以勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”勾上之后开发期可以自由请求。但要注意这只是开发期的临时窗口上线前必须关掉而且需要在小程序后台把真正的HTTPS域名配置好。如果你跟我一样用云开发Cloud调用不受这个域名白名单限制能省不少事。第二个是基础库版本的切换。如果你的页面用到了较新的API比如getPhoneNumber新接口、隐私协议相关API一定要把基础库版本调到2.30以上。项目里如果用户微信版本太老还要做兼容判断不能一上来就崩。第三个是调试器里的AppData面板。我检查AI生成的数据结构是否正确最直接的方式就是看AppData面板里的页面data不需要加一堆console.log。WorkBuddy生成的代码偶尔会有字段名不匹配的情况——比如页面用了item.title但数据字段是item.name打开AppData一眼就能看见。4.2 用抓包工具分析自己小程序的请求搜“小程序抓包”“charles使用教程”的人很多但我先提醒一句抓包调试只适用于分析你自己开发的小程序不要去抓别人的流量也别试图分析其他小程序的加密协议。这个边界必须守住。我对自己的小程序做抓包主要场景是排查接口返回慢、字段缺失、请求带错参数这类问题。我用的工具是Charles步骤是电脑和手机连同一个WiFiCharles开启SSL Proxying手机WiFi代理指向电脑IP的8888端口手机安装并信任Charles的SSL证书微信开发者工具里打开真机调试的小程序Charles里就会列出这个小程序发出去的所有HTTPS请求。实际排查中我发现一个典型问题小程序请求的云函数返回数据里嵌套层级过深导致前端渲染时频繁访问深层字段页面出现卡顿。这个过程必须看请求响应里的原始JSON结构光靠猜根本定位不到。抓包工具不是用来破解的而是用来看看自己的数据在链路上长什么样。4.3 真机预览和模拟器的差异在开发者工具模拟器里跑得丝滑不代表真机就稳。我遇到过的差异至少有这几类一是授权弹窗表现不同。模拟器里弹手机号授权一点就出来了但真机上有时会因为用户之前拒绝过、或微信账号状态问题弹窗不出现或按钮点击没反应。处理办法是做好拒绝授权后的引导流程用button的open-type触发的是系统弹窗没有自定义接口所以只能提示用户去设置里重新开启。二是性能差异。模拟器性能普遍比真机高很多尤其是渲染复杂长列表或图片较多页面时模拟器60帧真机掉到20帧。我在优化时做了图片懒加载、列表分页上拉加载WorkBuddy直接给我生成了基于IntersectionObserver的懒加载代码这个API在小程序里叫wx.createIntersectionObserver真机效果明显。三是体验版二维码测试。开发者工具上传代码后在小程序后台“版本管理”里可以生成体验版二维码用手机微信扫码就能真机体验。我每次给WorkBuddy下发“修改某个页面”的指令之后都会上传一版体验版然后自己拿手机跑一遍完整流程。这个习惯帮我提前发现了很多只在真机才暴露的问题。5. 备案、提审到发布微信后台里必须走完的流程5.1 小程序备案这步到底怎么走2023年以后微信小程序新上架都需要完成ICP备案这是硬性条件没有备案根本走不到提审那一步。我第一次知道这个事的时候以为要跑线下流程实际在小程序后台就能完成比想象中简单。路径是登录微信公众平台 → 左侧菜单“设置”→“基本设置”→“小程序备案”。备案需要填主体信息个人小程序提供身份信息企业小程序需要营业执照、法人身份信息然后做手机号验证和人脸核验。提交之后通常1到2周内会收到备案结果通知中间可能有短信或电话核验保持电话畅通就行。这里提醒几个容易出问题的地方备案主体必须和小程序注册主体一致。用个人名义注册的账号备案时也必须是个人身份不能混用企业身份。小程序名称、简介、服务类目要跟备案信息匹配。比如你备案的是一个电商小程序简介里就不要写“社交社区”审核人员看类目和内容不一致也是会被拒的。备案和ICP备案不是一回事。虽然都在同一套体系下但小程序平台侧有自己独立的备案流程别填了域名备案就以为完事了。我备案审核等了大概8个工作日中间没有补材料算比较顺的。如果你赶上线时间建议把备案和其他开发工作并行别等备案通过才开始写代码那是纯浪费时间。5.2 提审时的常见被拒理由以及我的处理办法小程序提审被拒是家常便饭不用沮丧但一定要搞清楚规避逻辑。我第一版被拒的原因很有代表性未配置用户隐私保护指引且在实际运行中调用了用户手机号权限。现在的提审流程里微信会把小程序用到了哪些用户信息列得清清楚楚你的隐私保护指引必须逐一声明。操作路径是小程序后台 → “设置”→“服务内容声明”→“用户隐私保护指引”。我当时只声明了“手机号”但审核提示我项目里还调用了“设备信息”“剪贴板”等功能最后我把用到的一项一项核清楚全部声明完再提审才通过。其他常见被拒理由还有类目选择不正确。比如做了商品交易但没选“电商平台”或“商家自营”类目又没提供相应的资质如营业执照会被秒拒。页面功能不完整。点击某个按钮没反应或出现空白页面审核人员会判定为功能不可用。我们开发阶段常有的“功能开发中”页面提审前一定处理完。测试账号和演示路径没写清楚。如果你的小程序需要登录才能用最好在提审备注里写明测试账号或者提供一条无需登录即可体验的路径不然审核员可能进不到核心页面。内容安全问题。小程序里有用户可输入内容或UGC模块需要接入“内容安全”检测能力包括文本检测和图片检测。微信云开发里可以直接调用安全服务接口。我第二次提审时把隐私指引、类目、功能完整性都处理好了结果一个工作日内审核就通过了然后点“发布”小程序正式上线。从用WorkBuddy生成第一行代码到上线前后一周出头其中有大概四天都在跑备案和等审核。最后再分享一个我实际测试下来的小技巧提审前用WorkBuddy把提审页面的字段和所需资料列一个清单对着后台逐项核对。工具生成的代码能帮你把产品做出来但“能不能上线”这件事靠的还是对平台规则足够的尊重和细致的准备。我的体会是AI拉高了代码产出的下限但作为开发者你对合规和用户体验的把控才是决定这个小程序能走多远的上限。
我最近用WorkBuddy做了一款微信小程序从对话式生成代码到提交审核、最终在微信正式上线完整跑通了一个周期。这篇想把整个过程记录下来我是怎么和WorkBuddy协作的、微信登录和手机号获取到底怎么实现、备案审核有哪些坑以及我在真机调试和抓包排错中踩过的具体问题。如果你正打算用WorkBuddy这类AI编程工具做小程序但对微信生态不太熟这篇文章应该能帮你省下不少时间。1. 先聊聊WorkBuddy它凭什么把小程序的开发节奏拉起来1.1 WorkBuddy到底帮我把什么活干了先说结论WorkBuddy在我这个项目里扮演的角色不是单纯帮你补全函数的代码补全工具而是能听懂整个项目上下文、直接生成可运行工程的全栈工作台。我在对话里告诉它“做一个2048小游戏风格的积分兑换小程序”“首页要轮播图和商品分类”“登录要支持微信手机号授权”它就把小程序的原生工程骨架、页面、组件、样式、云函数一次性生成了。这一点很关键。传统开发一个小程序哪怕是一个简单商城至少也要经历注册项目、配置AppID、搭全局样式、封装请求库、设计页面结构、写交互逻辑。这串动作以前要按天算WorkBuddy这一步让我按小时算。我实际体验下来它的优势在于三点第一上下文连续。我改了个页面结构再让它调整对应的数据字段它不会忘了之前生成的组件名和页面路径这种连贯性决定了大工程能不能用AI做。第二贴近微信生态。它生成的小程序代码用的是原生WXML/WXSS/JS/JSON不是随便写个网页来糊弄这保证了后面导入微信开发者工具可以直接跑起来。第三能帮我查报错。开发和调试过程中最烦的就是编译报错尤其是一些小程序特有的问题比如组件路径写错、app.json里页面注册遗漏、基础库API不兼容。我把报错信息粘给WorkBuddy它大多数时候能直接指出问题出在哪个文件哪一行。1.2 它的边界在哪里我仍然需要懂什么但我要泼一盆冷水WorkBuddy再强也只是把“写代码”这件事加速了“懂微信这套规则”这件事没人能替你完成。我在项目里体会最深的是如果不了解微信小程序的底层机制你连问题都描述不准AI生成的东西也容易方向跑偏。比如小程序里“登录”这件事跟web开发完全是两个逻辑。web登录靠session、cookie小程序靠的是wx.login拿code、再换openid/session_key。再比如小程序对接口域名有强制要求——必须是HTTPS、必须在后台配置白名单再比如用户隐私保护指引没配置好提审直接被拒。这些规则我不会再花时间给AI解释因为它懂但用不用、怎么用得我把关。所以我的定位是WorkBuddy是主力编码员我当架构师和验收员。项目的整体结构、数据安全、合规审核这些我盯具体页面、具体函数、样式布局交给它写。我验收的节奏是每生成一个模块就拿到微信开发者工具里跑一遍而不是攒到最后再看。2. 从一句话需求到工程骨架我和WorkBuddy的真实协作方式2.1 需求描述怎么写AI才不会跑偏很多人用AI生成代码失败问题几乎都出在需求描述上。你给一句“帮我做个商城”出来的东西只能是模板味十足的示例因为它不知道你要卖什么、给谁用、有没有后台、有没有支付、有没有积分。我在需求阶段用了两板斧第一板斧把场景说清楚。我写的不是“小程序商城”而是“一个面向社区团购场景的微信小程序用户进入首页看到今日推荐商品点击商品进入详情页可以加入购物车下单时支持微信手机号快速授权后台用微信云开发存储订单数据管理员在小程序里可以查看订单列表。”第二板斧给参考物。我把自己比较喜欢的两个小程序的页面截图发给WorkBuddy告诉它“首页的布局风格接近这种分类导航要横向滚动”。AI对文字描述的理解是有限的但有截图参考时生成的页面结构和视觉风格会明显更贴合预期。这里有一个非常关键的经验让AI先出页面树再写代码。我让WorkBuddy先把小程序包含哪些页面、每个页面有哪些模块、模块之间怎么跳转列出来等我确认了页面树再让它逐个页面生成。如果一上来就让它写全部代码后期改结构成本和理解成本都很高。2.2 原生小程序还是uni-app我最后为什么选原生当时摆在我面前的有两个方案让WorkBuddy生成原生小程序工程或者生成uni-app工程再打包成小程序。这两个方案我都试过最终选了原生小程序理由有三个一是上线路径最短。原生小程序工程生成后直接用微信开发者工具打开就能编译预览不需要转译和打包那一层出问题排查起来少一个环节。二是微信能力覆盖最全。有些比较新的API和小程序插件在uni-app里可能需要额外适配和封装原生小程序是第一时间同步的。比如手机号快速验证组件、最新的隐私接口声明原生环境下踩坑少。三是AI对原生代码的生产效率更高。WorkBuddy在生成原生WXML/WXSS/JS/JSON方面的训练数据显然比多端框架更充足代码写出来更地道Bug也更容易修。当然如果你明确要做支付宝小程序、抖音小程序多端发布那uni-app还是值得考虑的。但如果你就是冲着微信上线来的我建议不要绕路。WorkBuddy生成完工程后导入微信开发者工具时页面会提示选择AppID我填的是自己已注册的小程序AppID编译后直接把基础库和调试器跑起来看效果。3. 核心功能落地的三条线登录、数据、页面细节3.1 微信登录与手机号获取的完整链路这一部分是搜“微信小程序登录获取手机号”最关心的技术点。先说明微信这几年把手机号获取的接口升级过现在推荐用的是手机号快速验证组件也就是通过button组件的open-type弹授权框直接从微信侧拿到一个code再把code交给后端调用官方接口换取手机号。前端代码很简单button open-typegetPhoneNumber bindgetphonenumberhandleGetPhoneNumber 授权获取手机号 /buttonPage({ handleGetPhoneNumber(e) { if (!e.detail.code) { wx.showToast({ title: 您取消了授权, icon: none }) return } // 把code传给后端/云函数 wx.cloud.callFunction({ name: getPhoneNumber, data: { code: e.detail.code } }).then(res { const { phoneNumber } res.result console.log(手机号, phoneNumber) }) } })后端用云函数实现更简单因为微信云开发开放能力里直接封装了接口// 云函数 getPhoneNumber/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) exports.main async (event) { const { code } event const res await cloud.openapi.phonenumber.getPhoneNumber({ code }) return res }这个流程里有个容易踩坑的地方e.detail.code只能用一次而且有效期很短。调试时如果后端没调到接口就刷新页面这个code就废掉了需要重新触发授权。所以前端要在拿到code后立刻发给后端不能中途做太多无关逻辑。再说说旧版流程搜“微信数据库解密”时很多人其实说的是这个。早期版本获取手机号或用户信息返回的是encryptedData和iv需要后端拿session_key做AES解密// 旧接口加解密原理现在已逐步废弃 const crypto require(crypto) function decryptPhoneNumber(sessionKey, encryptedData, iv) { const key Buffer.from(sessionKey, base64) const decipher crypto.createDecipheriv(aes-128-cbc, key, Buffer.from(iv, base64)) decipher.setAutoPadding(true) let decoded decipher.update(encryptedData, base64, utf8) decoded decipher.final(utf8) return JSON.parse(decoded) }新接口把解密这一步放到微信官方服务端了对开发者更安全也省了很多事。但理解这个加解密过程仍然有价值因为你在排查问题的时候看到“解密失败”“session_key错误”这类报错至少知道源头在哪。顺带提醒一句微信小程序的本地缓存Storage默认是不加密的这个“数据库解密”不能碰任何敏感数据都不应该明文放进Storage手机号、openid、用户的业务隐私数据都应该存在服务端需要时再取。3.2 服务端接口与本地缓存的交互设计小程序前后端交互我直接用了微信云开发好处是不需要自己买服务器、配域名、搞HTTPS证书。WorkBuddy对云开发的生成支持也比较成熟数据库集合、云函数、调用API这一整套都能直接生成。我的项目里做了这样几个关键设计第一请求统一封装。所有前端到云函数的调用都走一个request工具统一处理loading状态、错误提示、成功数据解包。这样代码里不会到处都是wx.cloud.callFunction后期出了问题也只需要改一个文件。第二登录态与用户数据分离。登录成功后后端返回给前端的是业务token或openid手机号只保存在云数据库的用户集合里不随着每个接口返回。这样即便是抓包看流量也看不到敏感信息。第三本地缓存只存非敏感的状态数据。比如用户浏览记录、草稿内容、接口返回的非敏感配置数据。token如果必须缓存也要做有效期控制每次启动小程序时校验一遍。在这个环节我犯过一个错一开始把用户手机号直接放到了storage里还开了缓存理由是“下次进来不用再授权”。后来提审时被微信的隐私合规检测抓到要求整改。这个教训说明两个事一是个人信息保护不是一句口号平台审核是真会查的二是作为开发者你脑子里要有一根弦——能不上传的就不上传能不缓存的不缓存。3.3 页面细节导航栏高度、动态标题、单选框这些看似不起眼的点页面细节决定一个小程序用起来像不像正经产品。这里说三个我实际处理过的点正好也都是大家高频搜索的问题。第一个是导航栏高度适配。如果你用了自定义导航栏就不能把顶部组件写死在一个固定值上因为不同机型的statusBar高度不一样尤其是有刘海的iPhone和全面屏安卓。WorkBuddy生成代码时给我留了标准适配方案const { statusBarHeight, windowWidth } wx.getSystemInfoSync() const menuButton wx.getMenuButtonBoundingClientRect() const navBarHeight (menuButton.top - statusBarHeight) * 2 menuButton.height这段代码的意思是把胶囊按钮的位置作为导航栏高度的锚点不管什么机型导航栏都刚好顶到胶囊按钮上方视觉上不会歪。在做自定义导航栏时一定要用到这一手。第二个是动态设置页面标题。小程序标题不只是app.json里配一次就完了很多时候要根据页面内容实时变。比如商品详情页要显示商品名积分商城页要显示实时活动名。小程序的API给了现成方法wx.setNavigationBarTitle({ title: product.name })用这个方法时要注意它只对当前页面生效页面切走后就恢复默认配置了所以需要在onShow或数据加载完成后再调用不要在onLoad里过早执行。第三个是单选框的样式定制。小程序原生的radio组件在不同平台表现有差异iOS和安卓的选中态画风不同单独写样式又容易覆盖不成功。我的处理办法是把radio的value绑定到业务数据用color属性统一选中色外层包label提升点击范围同时为不同选项设置独立的checked状态radio-group bindchangehandleTypeChange label wx:for{{types}} wx:keyvalue classtype-item radio value{{item.value}} checked{{item.checked}} color#07c160 / text{{item.name}}/text /label /radio-group说实话这些细节如果不专门处理功能也能跑但用户感受完全不一样。定制导航栏让页面更像原生应用动态标题让信息传达更准确单选框的点击热区更符合手指操作习惯。WorkBuddy能生成功能代码但这些“产品感”的部分还是需要我人工确认。4. 真机调试与抓包排查上线前最花时间的那个坎4.1 微信开发者工具里的配置细节WorkBuddy生成的工程导入微信开发者工具的路径是下载微信开发者工具稳定版就可以→ 导入项目 → 目录选择工程文件夹 → 填写自己的小程序AppID。这里有几个配置细节搞错了会浪费大量调试时间。第一个是**“不校验合法域名”开关**。开发阶段如果你还没在小程序后台配置request合法域名工具和真机都会因为域名不在白名单里拒绝请求。开发者工具左上角“详情→本地设置”里可以勾选“不校验合法域名、web-view业务域名、TLS版本以及HTTPS证书”勾上之后开发期可以自由请求。但要注意这只是开发期的临时窗口上线前必须关掉而且需要在小程序后台把真正的HTTPS域名配置好。如果你跟我一样用云开发Cloud调用不受这个域名白名单限制能省不少事。第二个是基础库版本的切换。如果你的页面用到了较新的API比如getPhoneNumber新接口、隐私协议相关API一定要把基础库版本调到2.30以上。项目里如果用户微信版本太老还要做兼容判断不能一上来就崩。第三个是调试器里的AppData面板。我检查AI生成的数据结构是否正确最直接的方式就是看AppData面板里的页面data不需要加一堆console.log。WorkBuddy生成的代码偶尔会有字段名不匹配的情况——比如页面用了item.title但数据字段是item.name打开AppData一眼就能看见。4.2 用抓包工具分析自己小程序的请求搜“小程序抓包”“charles使用教程”的人很多但我先提醒一句抓包调试只适用于分析你自己开发的小程序不要去抓别人的流量也别试图分析其他小程序的加密协议。这个边界必须守住。我对自己的小程序做抓包主要场景是排查接口返回慢、字段缺失、请求带错参数这类问题。我用的工具是Charles步骤是电脑和手机连同一个WiFiCharles开启SSL Proxying手机WiFi代理指向电脑IP的8888端口手机安装并信任Charles的SSL证书微信开发者工具里打开真机调试的小程序Charles里就会列出这个小程序发出去的所有HTTPS请求。实际排查中我发现一个典型问题小程序请求的云函数返回数据里嵌套层级过深导致前端渲染时频繁访问深层字段页面出现卡顿。这个过程必须看请求响应里的原始JSON结构光靠猜根本定位不到。抓包工具不是用来破解的而是用来看看自己的数据在链路上长什么样。4.3 真机预览和模拟器的差异在开发者工具模拟器里跑得丝滑不代表真机就稳。我遇到过的差异至少有这几类一是授权弹窗表现不同。模拟器里弹手机号授权一点就出来了但真机上有时会因为用户之前拒绝过、或微信账号状态问题弹窗不出现或按钮点击没反应。处理办法是做好拒绝授权后的引导流程用button的open-type触发的是系统弹窗没有自定义接口所以只能提示用户去设置里重新开启。二是性能差异。模拟器性能普遍比真机高很多尤其是渲染复杂长列表或图片较多页面时模拟器60帧真机掉到20帧。我在优化时做了图片懒加载、列表分页上拉加载WorkBuddy直接给我生成了基于IntersectionObserver的懒加载代码这个API在小程序里叫wx.createIntersectionObserver真机效果明显。三是体验版二维码测试。开发者工具上传代码后在小程序后台“版本管理”里可以生成体验版二维码用手机微信扫码就能真机体验。我每次给WorkBuddy下发“修改某个页面”的指令之后都会上传一版体验版然后自己拿手机跑一遍完整流程。这个习惯帮我提前发现了很多只在真机才暴露的问题。5. 备案、提审到发布微信后台里必须走完的流程5.1 小程序备案这步到底怎么走2023年以后微信小程序新上架都需要完成ICP备案这是硬性条件没有备案根本走不到提审那一步。我第一次知道这个事的时候以为要跑线下流程实际在小程序后台就能完成比想象中简单。路径是登录微信公众平台 → 左侧菜单“设置”→“基本设置”→“小程序备案”。备案需要填主体信息个人小程序提供身份信息企业小程序需要营业执照、法人身份信息然后做手机号验证和人脸核验。提交之后通常1到2周内会收到备案结果通知中间可能有短信或电话核验保持电话畅通就行。这里提醒几个容易出问题的地方备案主体必须和小程序注册主体一致。用个人名义注册的账号备案时也必须是个人身份不能混用企业身份。小程序名称、简介、服务类目要跟备案信息匹配。比如你备案的是一个电商小程序简介里就不要写“社交社区”审核人员看类目和内容不一致也是会被拒的。备案和ICP备案不是一回事。虽然都在同一套体系下但小程序平台侧有自己独立的备案流程别填了域名备案就以为完事了。我备案审核等了大概8个工作日中间没有补材料算比较顺的。如果你赶上线时间建议把备案和其他开发工作并行别等备案通过才开始写代码那是纯浪费时间。5.2 提审时的常见被拒理由以及我的处理办法小程序提审被拒是家常便饭不用沮丧但一定要搞清楚规避逻辑。我第一版被拒的原因很有代表性未配置用户隐私保护指引且在实际运行中调用了用户手机号权限。现在的提审流程里微信会把小程序用到了哪些用户信息列得清清楚楚你的隐私保护指引必须逐一声明。操作路径是小程序后台 → “设置”→“服务内容声明”→“用户隐私保护指引”。我当时只声明了“手机号”但审核提示我项目里还调用了“设备信息”“剪贴板”等功能最后我把用到的一项一项核清楚全部声明完再提审才通过。其他常见被拒理由还有类目选择不正确。比如做了商品交易但没选“电商平台”或“商家自营”类目又没提供相应的资质如营业执照会被秒拒。页面功能不完整。点击某个按钮没反应或出现空白页面审核人员会判定为功能不可用。我们开发阶段常有的“功能开发中”页面提审前一定处理完。测试账号和演示路径没写清楚。如果你的小程序需要登录才能用最好在提审备注里写明测试账号或者提供一条无需登录即可体验的路径不然审核员可能进不到核心页面。内容安全问题。小程序里有用户可输入内容或UGC模块需要接入“内容安全”检测能力包括文本检测和图片检测。微信云开发里可以直接调用安全服务接口。我第二次提审时把隐私指引、类目、功能完整性都处理好了结果一个工作日内审核就通过了然后点“发布”小程序正式上线。从用WorkBuddy生成第一行代码到上线前后一周出头其中有大概四天都在跑备案和等审核。最后再分享一个我实际测试下来的小技巧提审前用WorkBuddy把提审页面的字段和所需资料列一个清单对着后台逐项核对。工具生成的代码能帮你把产品做出来但“能不能上线”这件事靠的还是对平台规则足够的尊重和细致的准备。我的体会是AI拉高了代码产出的下限但作为开发者你对合规和用户体验的把控才是决定这个小程序能走多远的上限。
