做小程序第二天按理说应该从“能跑起来”进入“能做出点真正功能”的阶段了。我接触过不少从零自学过来的朋友也带过团队接手过各种半路项目基本到了Day2大家都会集中遇到几类问题要么是上手第一天已经把页面写了个大概今天想接后端数据却发现跨域、域名白名单、request合法域名一个一个排队蹦出来要么是想实现点微信特色功能比如动态改标题、带参数跳转、调起支付结果被各种权限和签名校验卡在原地还有一部分人已经开始考虑上线和推广了结果发现还没注册小程序、类目没选对、支付通道没开通。可以说第二天才是真实开发的第一天第一天只是装环境加“Hello World”。这篇文章我就结合自己实际搞过的项目把小程序开发第二天的关键任务做一次系统梳理。内容以微信小程序为主兼容uni-app这种跨端框架的常见差异。涵盖开发环境升阶、动态设置页面头部标题、微信支付v3对接、抓包调试、组件踩坑、多端适配以及从开发到上线的合规避坑。深度算不上拔尖但每一条都是从真实项目里熬出来的经验适合正在学小程序、准备接私活做小程序商城的开发者参考。1. 内容整体设计与思路拆解1.1 Day2到底该做什么打通数据链路和微信能力很多教程把小程序开发讲成单纯的前端页面编写实际上小程序的技术栈和传统H5最大的不同在于它有一套完整的宿主能力包括登录态、支付、分享、定位、蓝牙、NFC等等每个能力背后还有对应的权限申请、签名校验、服务器配置。第二天的核心任务应该是把这些“微信侧”的东西打通而不是继续埋头写页面。我见过太多自学者的错误路线先花两周把前端UI写得漂漂亮亮第七天才发现自己压根没注册小程序账号更别提AppID去哪拿了要么就是做到支付环节才发现自己没有商户号类目也不支持电商那才叫一个崩溃。所以Day2的正确设计思路应当围绕“链路”展开从开发工具的工程配置到远程接口联调再到微信登录态和支付沙箱最后回到真机预览和日志调试。这一整天走完等于把一个真实商业小程序从开发到交付的主路径踩通了。主路径上的技术选型也很关键。如果你是一个人做小程序商城、点单这类业务我建议直接用原生小程序配合云开发省去自己搭服务器的麻烦如果你有后端基础或者复用的是公司现有的API可以选uni-app或Taro这种跨端框架便于后续复用代码。这里有个需要反复强调的点Day2不是纠结框架的日子而是一个把端到端链路跑通的日子。框架可以换链路的逻辑是通用的。1.2 为什么绝大多数新手会卡在Day2被忽略的“环境上下文”所谓“环境上下文”包含的东西很杂微信开发者工具的登录状态、AppID是否有效、小程序是否开启了开发者模式、request接口的域名有没有加入白名单、本地调试器的缓存问题、微信基础库版本差异、开发版和体验版的权限区别。这些如果没有提前理清往往功能写了半天一刷新就全部归零问题和代码半毛钱关系都没有。举个最常见的例子在开发者工具里调试时一切正常代码一传到手机上就白屏打开调试器发现一堆“https://xxx不在以下request合法域名列表中”的报错。你是写了代码没错但你忘了在小程序管理后台把接口域名配置进白名单而且线上环境要求必须是HTTPS、备案过的域名本地调试可以把“不校验合法域名”勾上真机预览就绕不过去了。这就是典型的环境上下文问题。再比如“扫普通链接二维码无法打开小程序”大部分情况不是代码逻辑问题而是二维码的配置类型、路径、参数没有在小程序后台“二维码跳转”规则里提前挂好。Day2如果能把这些环境上下文全部理顺后面写业务代码就会很顺畅。我会把我在实操过程中整理的检查清单放在后面“常见问题”部分直接照着查就能解决一大部分疑难杂症。2. 核心细节解析与实操要点2.1 动态设置页面标题navigationBarTitleText的实时用法刚接触小程序时大多数人都是在配置文件app.json或页面json里写死标题比如“首页”“购物车”。但真实业务里标题经常要动态变化比如二手交易平台要根据不同的商品名称显示页面标题资讯类小程序要根据文章标题动态更新头部。微信提供的API很直接wx.setNavigationBarTitle。// 在页面的 onLoad 或 onReady 中调用 wx.setNavigationBarTitle({ title: 这是新的标题 })这段代码简单到没什么好说的但有几个注意点一是调用时机最好不要早于onReady部分基础库在页面未完成渲染时设置标题会有概率失败二是标题字符串有长度限制超长部分会被截断我遇到过一个项目直接把商品名全文塞进去结果中文字数超过系统限制显示成省略号反而影响观感三是wx.setNavigationBarTitle只在当前页面生效页面卸载后回到上一个页面标题会自动恢复为上一个页面的配置值不用手动清理。与动态标题紧密相关的一个东西是顶部导航栏高度。有些自定义导航栏的项目需要精确计算状态栏高度才能把自定义按钮对齐到胶囊右侧。标准做法是const systemInfo wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync() const statusBarHeight systemInfo.statusBarHeight // 胶囊按钮位置 const menuButton wx.getMenuButtonBoundingClientRect()拿到statusBarHeight和menuButton之后就能算出导航栏总高度大概公式是navHeight (menuButton.top - statusBarHeight) * 2 menuButton.height。这个公式是社区里比较通用的算法适用于绝大多数机型。需要注意的是不同机型的胶囊尺寸会有细微差异建议上线前用iPhone X系列和普通安卓机各测一遍。2.2 微信支付v3对接从商户号到回调验签的全链路避坑微信支付是小程序电商场景里绕不开的大山也是Day2阶段很多自学开发者最恐惧的部分。先别被“v3”这个前缀吓到它相比v2的核心变化就三点用RSA密钥对替换了MD5签名、用API v3密钥做回调报文解密、用平台证书验签。虽然安全性提升明显但对接的复杂度也同步上来了。先理一下接入微信支付v3需要准备的东西已认证的小程序账号、微信支付商户号、API v3密钥、商户API私钥apiclient_key.pem、商户证书序列号、微信支付平台证书。这五个缺一不可。商户号需要单独申请在微信支付商户平台里把“AppID账号绑定”完成否则小程序调起支付时会报“商户号与AppID不匹配”。真正的后端核心逻辑是两步第一步调用微信支付接口生成预支付订单第二步把后端签名好的参数返回给小程序的wx.requestPayment。我用一段伪Node.js代码展示后端大概流程// 1. 构造统一下单参数 const payParams { appid: 小程序AppID, mchid: 商户号, description: 商品描述, out_trade_no: 订单号需要唯一, notify_url: https://你的域名/api/pay/notify, amount: { total: 1 // 单位分1元就传100 }, payer: { openid: 用户的openid } } // 2. 使用商户私钥生成Authorization请求头 // 3. POST到 https://api.mch.weixin.qq.com/v3/pay/transactions/jsapi // 4. 拿到响应中的 prepay_id这里最容易翻车的点在签名。微信支付v3要求把请求方法、请求路径、请求时间戳、随机串、请求体摘要SHA256后的Base64拼接成一个字符串再用商户私钥做SHA256withRSA签名。拼串的格式一旦错了接口就会返回“请确认参数是否正确”之类的模糊报错。建议第一次对接时把官方签名文档放在旁边逐字对照不要凭记忆写。支付回调的验签和解密同样麻烦。微信会用一个特殊的Wechatpay-Signature头带签名需要用平台证书验签。验签通过后通知报文里的resource字段是加密的要用API v3密钥做AES-256-GCM解密。我遇到过的典型问题是在本地开发环境回调调试时拿不到平台证书实际上可以通过接口下载平台证书也可以直接在商户平台下载证书文件省去证书自动更新逻辑。新手阶段建议先用商户平台手动下载证书。2.3 单选框、上传组件与图片保存三个被问烂的痛点热词里出现了“微信小程序单选框”“uview 上传组件u-upload”“uniapp微信小程序保存图片:savelmagetophotosalbum:fail”这几个问题虽然在不同的项目里出现但本质都是对小程序组件能力和隐私权限理解不透。先说单选框。原生radio-group和radio用起来没什么门槛但实际项目里很少有直接使用默认样式的大多会做成卡片式选择。实现思路很简单自己用view模拟选中态点击时把索引存下来用wx:if或动态class控制选中样式。这样做的好处是视觉完全可控也不会受到平台差异影响。然后是上传组件。uview的u-upload组件确实好用但很多人在H5端测试通过后一换到小程序真机就发现图片不显示。原因多半是返回的图片临时路径tempFilePath在H5有效在小程序端需要先上传到服务器换取正式的URL地址不能直接拿临时路径渲染。正确做法是在on-choose-complete回调里把文件通过wx.uploadFile传到自己服务器返回的URL再塞回fileList里。最后是保存图片报fail的问题。这个错误常见原因有两类。第一类是相册权限没开小程序管理后台需要配置“相册仅写入权限”的申请原因用户拒绝授权后API会直接失败第二类是下载网络图片时没有先通过wx.downloadFile拿到本地临时路径而是直接把远程HTTPS链接丢给wx.saveImageToPhotosAlbum这在小程序里是不允许的。常规操作方式wx.downloadFile({ url: https://远程图片地址, success(res) { wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success() { wx.showToast({ title: 保存成功 }) } }) } })2.4 开发必备技能抓包与反编译入门热词列表里出现了一堆抓包、反编译相关的内容。“微信小程序抓包”这个小技巧很多场景下都挺实用的。比如你要调试WebView里的H5页面或者想确认小程序到底请求了哪些接口抓包能帮上大忙。我自己在Windows环境比较常用的方案是电脑上装一个抓包工具Fiddler或Burp Suite都行看个人习惯。开启HTTPS解密安装并信任根证书。手机和电脑连同一个局域网把手机WiFi代理指向电脑IP和抓包工具监听的端口。微信里打开小程序流量就会经过抓包工具。这个过程中有一个很隐蔽的坑小程序默认不信任安装的用户证书Android 7.0以上默认只信任系统证书抓包工具装上了却解密不了HTTPS内容。常见的绕过方式是把用户证书转成系统证书但需要Root权限手机厂商不同操作差异很大。所以我通常的建议是优先抓WebView里的H5接口或者检查小程序是否允许了“不校验合法域名”的调试选项否则为了抓包去折腾Root反而得不偿失。反编译这块我只说自己看法建议停留在学习目的上。小程序的反编译工具链已经比较成熟能找到一堆“反编译小程序获取源码”的教程。但从合规角度讲反编译别人未授权的小程序源码属于侵权行为如果用来做代码参考还好拿去改名上架就是给自己埋雷。真有学习需求的话可以申请一些开源项目来读或者对自己开发过的小程序做备份恢复练习效果比反编译别人的代码好得多。3. 实操过程与核心环节实现3.1 从云开发到自定义后端接口联调的完整套路Day2的实操环节我建议先把一个完整的小流程串起来从数据库读到列表展示到页面点击跳转到详情再拿到详情数据渲染。这个流程看起来简单但牵扯到的点很密集串完它基本就对小程序的数据流有了底感。如果你用的是云开发不需要配置域名白名单直接在前端使用wx.cloud.callFunction或者wx.cloud.database()读取数据即可。第一天建好环境后第二天完整走一遍数据读取和权限校验是比较舒爽的体验。比如const db wx.cloud.database() db.collection(goods).where({ status: on_sale }).get().then(res { console.log(res.data) })云开发的便利之处是自带文档数据库、云函数和存储强调一下如果在Day2已经决定用云开发后续要为每个集合配置好权限避免默认“所有用户可读”造成数据泄露。我接手过一个开源校园跑腿项目就是买家和卖家的手机号全暴露在集合里了那问题放到生产环境绝对算安全事故。如果你走传统后端路线需要确认几件事后端接口是否支持HTTPS、域名有没有ICP备案、开发者工具里有没有勾选“不校验合法域名”。联调阶段我习惯先在开发者工具里把“不校验合法域名”打开快速调通逻辑等到要发体验版之前再去管理后台配置正式域名这样效率最高。注意真机预览不受“不校验合法域名”这个选项影响真机联调时要在后台临时把域名加进去配置后大概五分钟内生效。接口数据格式建议统一为下面这种结构方便前端统一处理错误状态{ code: 0, message: ok, data: { list: [], page: 1, total: 100 } }前端请求封装层面用Promise包一层wx.request是比较通用的方案。我自己的习惯是封装一个request.js统一带token、统一处理HTTP错误码、统一在401时跳转登录页。这样后面十几个页面共用一套逻辑不会每个页面重复写一堆错误处理。3.2 动态标题与导航栏高度自定义导航栏实践如果你的项目对头部样式要求比较高比如要做一个渐变色的导航栏或者要在头部放搜索框、放自定义按钮那就得放弃默认导航栏开启自定义导航栏。操作方法是在页面json里配置{ navigationStyle: custom }配置了之后原来的标题、返回按钮全部消失整个页面内容会延伸到顶部状态栏和内容重叠。这时候前面说的statusBarHeight和menuButton就派上用场了。一个标准的自定义导航栏结构大概长这样view classnav stylepadding-top: {{statusBarHeight}}px; view classnav-bar styleheight: {{navBarHeight}}px; view classnav-title{{title}}/view /view /view计算完成后导航栏的真实高度由三部分组成状态栏高度、胶囊按钮高度、上下留白间距。用一个统一方法计算一次存到全局变量或store里所有自定义页面共用即可。需要注意别在页面onLoad里反复计算改成App启动时算一次更高效。动态设置标题这个能力哪怕没有自定义导航栏也可以和默认导航栏配合。默认导航栏下wx.setNavigationBarTitle直接生效自定义导航栏下标题文字是由自己渲染的改的是数据绑定值。两者机制不同别混着写。3.3 uni-app多端踩坑软键盘遮挡、PDF预览与跨端兼容热词里有“uniapp 微信小程序 手机软键盘会遮挡住查询内容”“uniapp小程序打开pdf报错”以及“uniapp微信小程序保存图片:savelmagetophotosalbum:fail”。这些都是uni-app开发微信小程序时的高频问题本质上和跨端编译后的差异有关。软键盘遮挡问题常见出现在搜索页面输入框在下半屏键盘一弹就把结果列表挡住。常规解法有三条。第一输入框所在容器使用adjust-position属性让页面自动上推但这种方式在某些安卓机型上不稳定第二监听onKeyboardHeightChange拿到键盘高度动态给列表底部加padding第三把输入框固定到底部时用cursor-spacing属性给输入光标预留间距。三种方案可以组合使用效果最稳。PDF预览报错是另一个梗。小程序原生不支持直接预览PDF常见做法是用wx.downloadFile下载到本地再通过wx.openDocument打开。但uni-app里有人直接传了远程URL给openDocument导致一直失败。正确步骤一定是先下载再打开。如果打开的是后端返回的Base64流需要先转成本地临时文件再处理。跨端兼容上我再多说一句uni-app虽然能一套代码编译成H5、小程序、App但微信小程序独有的API如wx.setNavigationBarTitle在H5端没有对应实现代码里一定要判断平台或使用条件编译否则浏览器控制台会报一堆undefinded错误。条件编译的写法是// #ifdef MP-WEIXIN wx.setNavigationBarTitle({ title: 微信小程序端 }) // #endif // #ifdef H5 document.title H5端 // #endif3.4 微信小程序跳转链接从生成到触发的完整流程“微信小程序跳转链接 weixin://dl/business 从生成到触发的全流程避坑”热词里已经把这个主题点得比较明白了。这套方案主要用于App或外部H5唤起小程序。比如你在公众号文章里放一个小程序卡片或者在App里通过URL Scheme拉起小程序都属于这套体系的运用。微信官方对“跳转小程序”支持几种形式URL Scheme、URL Link、云开发的动态链接、微信开放标签wx-open-launch-weapp。最容易被忽略的是有效期和调用条件。URL Scheme有保质期过期就失效了。曾经有个项目上线后用户突然反馈无法跳转查了半天发现是Scheme过期导致的。生成方式在后端调用接口// 调用微信接口生成URL Scheme // 需要小程序AppID、AppSecret以及path参数 const res await axios.post( https://api.weixin.qq.com/wxa/generatescheme?access_tokenACCESS_TOKEN, { jump_wxa: { path: pages/index/index, query: id123 }, is_expire: true, expire_type: 1, expire_interval: 30 // 30天有效 } )拿到scheme之后在外部浏览器里直接location.href scheme就能调起小程序。但我提醒一句iOS和安卓的触发行为不一样有些安卓浏览器会先弹窗询问是否打开微信iOS则直接跳转。生产环境最好做失败兜底页面比如展示一个小程序码让用户扫码否则跳转失败时会白屏很久。扫普通链接二维码无法打开小程序的问题同样属于跳转链路配置问题。在小程序后台的“工具 - 生成小程序码 - 扫普通链接二维码打开小程序”里需要把二维码的URL规则和要打开的小程序页面关联起来。配置的URL必须和实际二维码扫码后的链接完全匹配路径参数也要严格对应不然就会提示“无法打开”。4. 常见问题与排查技巧实录4.1 误区频发点AppID、证书与实名认证Day2阶段遇到最多的问题都集中在账号和证书上。热词列表里“由于小程序违规支付功能暂时无法使用”“hbuilder运行微信小程序提示不是开发者”等等这些都是从账号层面出的问题。“提示不是开发者”大多是因为微信开发者工具扫码登录的微信号不在该小程序的项目成员列表里。解决办法用小程序管理员账号登录微信公众平台在“成员管理”里添加开发者微信号。这里的权限分“开发者”和“体验者”开发调试阶段建议至少加上“开发者”权限否则只能说“体验者”才能预览。“由于小程序违规支付功能暂时无法使用”属于比较严重的账号处罚通常是因为虚拟支付、类目选择不当、用户投诉等原因被平台限制。出现这类问题后第一件事不是马上写申诉材料而是先到微信公众平台查看站内信和违规详情搞清楚具体是哪个功能、哪条规则触发了处罚。等整改完成再提交申诉否则申诉一次被驳回一次时间成本很高。4.2 常见问题速查表我整理了第二日开发经常遇到的问题和对应解法方便大家直接对照排查问题现象常见原因解决思路真机预览请求失败请求返回空白或报错域名未配置为request合法域名在小程序后台添加HTTPS备案域名或临时开启调试模式动态标题无效调用API后标题没变调用时机过早或页面未就绪移到onReady中调用并确认不是自定义导航模式支付返回“商户号与AppID不匹配”调起支付时弹窗报错商户号未绑定AppID登录商户平台完成AppID绑定保存图片失败报savelmagetophotosalbum:fail未申请相册权限或直接保存网络链接先下载再保存完善隐私申明PDF打不开uni-app报错或白屏未先下载到本地直接openDocument先wx.downloadFile后wx.openDocument上传图片不显示小程序端图片裂开使用了H5的临时路径上传服务器获取真实URL扫普通链接二维码打不开提示无法打开小程序后台未配置二维码跳转规则在小程序后台“扫普通链接二维码打开小程序”里配置规则自定义导航栏不显示返回没有返回按钮navigationStyle改成custom后默认返回键消失自定义返回按钮调用wx.navigateBack页面下拉刷新失效下拉没有反应未在页面json开启enablePullDownRefresh设置enablePullDownRefresh: true4.3 我踩过的几个印象深刻的坑第一个坑是支付回调验签。当时我拿到微信支付平台证书的.pem文件按网上教程用框架内置的验签方法一直失败后来发现是证书序列号没对上因为商户平台支持多证书配置时用了旧证书序列号。这个问题从报错信息上很难看出来排查了快一下午。我的经验是把证书序列号、API v3密钥、商户私钥三项的查看路径和配置路径写下来逐个比对不要只盯着代码。第二个坑是“uniapp微信小程序保存图片”的隐私授权。小程序官方后来增加了隐私协议弹窗用户如果不点同意就算你代码里调用了授权API也拿不到相册权限。这个问题的报错非常隐蔽——有时候不报错就是不弹授权框看起来像API被吞了。后来发现需要在app.json里配置__usePrivacyCheck__之类的参数并且在用户触发保存前主动调隐私协议API才算彻底解决。第三个坑是顶部动态标题在安卓和iOS上的表现不一致。同一行标题iOS可能会居中显示安卓低版本会出现左对齐或者截断。如果项目对标题显示要求高建议用自定义导航栏渲染标题完全统一两端表现别依赖原生导航栏。4.4 开发到上线的合规自查清单不管Day2做的是商城、工具还是游戏类小程序开发中期就应当把合规节奏想清楚。我整理一下从自己项目里总结出的清单小程序账号是否完成了微信认证个人主体很多权限无法开通。小程序类目和实际业务是否匹配尤其是涉及电商、二手、社交等特殊类目时需要对应资质。接口域名是否已备案且使用HTTPS证书不能过期。是否配置了用户隐私保护指引是否主动说明获取了哪些信息以及用途。涉及支付的项目是否已经完成商户号申请和支付权限开通。是否有涉及诱导分享、虚拟支付这类高风险的违规场景比如自动诱导转发、iOS端卖虚拟道具等。是否在广告投放落地页里留好了小程序码以及二维码跳转规则是否完整。这套清单走一遍能挡掉80%的上线和推广阶段的幺蛾子。5. 资源、工具与学习路线建议5.1 常用工具和资源清单聊到工具选型我把自己平时用着顺手的列出来了供参考开发框架原生小程序适合快速开发、对性能要求高的场景、uni-app适合需要多端复用的场景、Taro适合React技术栈团队。UI组件库微信官方WeUI、Vant Weapp、TDesign、uview-plusuni-app生态用得多、TuniaoUI。调试工具微信开发者工具、Chrome DevTools调试WebView、Fiddler/Burp Suite抓包适用于自己有权调试的小程序。云服务微信云开发、腾讯云、阿里云。版本管理Git建议从第一天就配合远程仓库别等代码丢了才后悔。Day2阶段建议优先把原生开发者工具和微信官方文档看透。大量问题在官方文档里都有答案只是很多人习惯先搜社区帖子反而容易踩到过时内容。5.2 学习路线的第二阶段建议学小程序开发最好别按“从头到尾读文档”的方式推进。文档适合当字典查不适合当小说看。更合理的方式是定一个最小业务目标比如“做一个能下单的奶茶店小程序”然后从注册账号、创建项目、设计页面、对接云数据库、上线体验版一路把整个流程打穿。过程中遇到什么查什么比系统学几周效率高得多。到了Day2结束如果上面这套链路都走完了一遍你已经比很多“理论派”新手强不少了。接下来第三天开始可以考虑把业务逻辑做复杂一点比如固定的TabBar、登录态持久化、会员积分、优惠券核销这些真正商业项目会用到的功能。6. 安全防护与常见违规红线6.1 代码层安全防反编译、防刷接口互联网产品任何时候都要把安全放在脑子里。小程序前端代码跑在用户设备上透明程度比传统网页还高所以安全设计思路要前置。防接口被刷常见的方案是登录后拿token后续请求都带token后端校验。更进一步可以给请求加签名机制把请求参数和时间戳拼接好用约定好的密钥做HMAC签名后端验签通过才返回数据。这套机制能挡住大量低水平的恶意请求实现起来不复杂建议从Day2就放进封装层里。防前端被逆向正常手段不是靠代码混淆就能一劳永逸的。微信小程序有代码保护选项上传代码时可以开启“上传时进行代码保护”能增加反编译难度。但真心不建议把安全完全押在前端混淆上核心业务逻辑、加密密钥、支付私钥这些一定都要放后端前端只能拿到“该拿的东西”。热词里“ios小程序防截图”这个需求在小程序端可以用wx.setVisualEffectOnCapture禁止截屏/录屏时的内容显示。需要注意这类API只降低内容泄露风险防不住相机拍摄而且频繁调用会影响用户体验适合金融、隐私类页面。实现方式直接在页面的onShow生命周期里调用API即可。6.2 账号和内容违规红线微信小程序平台对违规行为的处罚力度越来越大“小程序违规支付功能暂时无法使用”这类问题一旦出现极影响业务。我把自己见过的违规类型整理一下避免大家踩坑虚拟支付iOS端小程序不允许卖虚拟商品包括会员、道具、课程等很多哪怕上了安卓端苹果端也会出问题。解决方案是iOS端走客服引导、H5充值或者App内购买。诱导分享强制分享才能解锁功能、分享后才能看答案都属于诱导分享平台容易直接封禁分享能力。类目造假明明做的是社交社区却选择工具类目上线一旦被平台复查发现轻则下架重则封号。隐私违规收集用户手机号、位置、相册但不告知用途或没有隐私保护指引会遭投诉处罚。内容安全用户生成内容UGC没有调用内容安全检测接口导致平台内出现违法内容开发者有连带责任。围绕这些红线Day2至少要做两件事一是注册时把类目审核材料准备齐二是在代码里预留内容安全检测的调用逻辑尤其是评论区、动态这类需要发文本和图片的模块。6.3 数据安全与备份数据备份这个点容易被个人开发者忽略。云开发自带自动备份还行但自建服务器的数据库就得自己操心。我以前有个项目跑在云服务器上数据库没配置自动备份一次误操作把整个表清空了损失惨重。后面我不管项目大小都至少在服务器上配置每天自动备份保留最近7天的备份文件。然后小程序端的缓存也要记得处理。wx.setStorageSync往本地写的数据是有容量限制的单键1MB总共10MB不要把大量列表数据塞进去。上线前要在onShow里检查登录态和缓存过期时间避免用户改了密码或账号被禁用后还能看到旧数据。我个人的习惯是每个页面在onUnload时清理掉临时数据重要操作像提交订单、支付成功后都做一次服务端状态校验不盲目信任前端的操作结果。7. 后续扩展方向完成了Day2的链路其实你已经具备做一个小型商业小程序的基本能力了。后续如果想把项目做深有几个方向很值得拓展。第一个方向是电商能力强化。把商品管理、库存、订单状态机、物流查询、退款售后这些模块逐一加进去。这个方向适合做“小程序商城”的读者了解清楚订单状态的流转对任何业务都有帮助。第二个方向是营销组件。优惠券、秒杀、拼团、分销裂变这些玩法的代码量不大但很考验对微信分享和登录态的理解。做这些功能时会大量用到wx.shareAppMessage、onShareTimeline等API还能顺带把动态标题、带参数链接这些知识巩固一遍。第三个方向是性能优化。小程序的包体积限制是2MB主包超过之后要用分包加载这是一个从“能用”到“好用”的分水岭。配合分包还可以做预加载、骨架屏、图片懒加载、接口缓存这一套优化下来体验会明显提升。第四个方向是想清楚商业闭环。做小程序不只是写代码域名备案、短信验证码、客服售后、物流对接都是商业项目的一部分。把这些外围环节打通才算是真正能交付给客户的产品。每个方向列出来都是大工程但好在它们都是线性积累的。Day2已经铺好了主干接下来就是不断往主干上挂枝叶了。最后分享一个我的个人心得学小程序开发最忌讳只刷教程不写项目。把Day2的链路亲手走完一遍遇到报错就自己查、自己修比看二十篇“从零开始学小程序”都有用。编程本来就是一门动手的手艺代码跑通了手感和信心就都有了。等这周结束再把二分页、支付、分享、客服这些环节过一遍你会发现自己已经能独立接个小程序需求了。