做了这么多年小程序相关的工作，几乎每周都能遇到新人问同一个问题：“我自己也想搞一个小程序，到底怎么从零开始？”问的人里有学生、有做电商的运营、有传统软件工程师，也有纯粹想接单赚钱的个人开发者。你会发现一个问题：大多数教程把“创建一个小程序”讲得太分散，要么只讲注册流程，要么只讲uniapp语法，却没人告诉你从idea到上线的完整路径里，哪里会有坑、哪里会被卡住、哪些功能个人主体根本做不了。所以我想把这些年积累的开发经验、踩坑记录整理成一篇能“抄作业”的文章，覆盖技术选型、工程结构、常见功能、调试上线以及风格多变的热门玩法，争取让一个没做过小程序的人也能照着走完一遍，少走弯路。
先说明一下写作思路。我会以微信小程序为主线，这是国内用户量最大、生态最完整、参考文档最多的小程序平台；同时兼顾uniapp和Taro等跨端框架的对比。关键词里出现的高频问题，比如自定义导航栏、单选框样式、音频缓存路径、支付能力异常、小程序跳转H5、游戏与AI小程序等，都会在对应章节里展开。你不需要从头到尾背下来，完全可以把它当字典、当checklist用，哪个环节出问题就翻哪一段。
1. 动手之前，先解决3个方向性问题
1.1 原生开发还是跨端框架？按需求来，别跟风
这几年在小程序开发群里，选框架几乎是每天都能吵起来的话题。我的观点很直接：如果只做微信小程序一个平台，没有其他跨端需求，直接用微信原生开发，别犹豫。原生框架的优势在于——工具链最稳定、API文档最全、社区问题库最大。你在微信开发者工具里遇到任何报错，几乎都能搜到前人的答案，这对刚起步的新人来说是巨大的隐性成本节约。
如果你未来想把同一套代码同时上支付宝小程序、抖音小程序、百度小程序，或者你本身已经熟悉Vue，希望通过写一套代码完成多端发布，那可以上uniapp；熟悉React的话，选Taro更顺手。但要注意，跨端不等于免费午餐，你在居中布局、TabBar样式、自定义组件规范上是要被“最大公约数”约束的，部分极端交互反而要写条件编译代码。关键词里提到“HBuilderX运行微信小程序提示不是开发者”这类问题，本质就是跨端工具链和微信工具之间的鉴权配合问题，后面我在第2.4节会专门讲。
我个人建议的路线是：纯新手第一次做，务必先做一个原生小demo，跑通“注册-创建-代码-预览-上传-上线”完整流程，对小程序本身有体感之后，再上跨端框架。连原生都没摸过就直接排框架，出现问题你会分不清是框架的问题、微信工具的问题还是自己代码的问题，排障会很痛苦。
1.2 注册主体：个人主体和企业主体的权限差距
注册小程序的方式不复杂，直接在微信公众平台官网按指引操作即可。“小程序”这个关键词背后对应的账号体系包含三个类型：个人主体、企业主体、以及政府媒体等特殊主体。个人注册只需要身份证和手机号，流程最快；企业主体则需要营业执照和对公账户验证，流程略长。
这里特别提醒一个常见误区：很多“小程序商城”“餐饮外卖小程序源码”需求的同学，上来就注册了个人主体，开发到一半才发现个人主体不开放微信支付、不开放部分类目（比如电商、餐饮的在线交易），只能注销账号重新注册企业主体。在决定注册之前，先把你想做的功能对照官方限制清单看一遍，支付类、虚拟支付类、直播类、医疗类功能都有主体和资质要求。如果你只是做工具类、展示类、笔记类小程序，个人主体足够；如果你想做任何涉及在线收款的业务，直接走企业主体。
1.3 工具链选型：微信开发者工具与HBuilderX的分工
这个必须说清楚。官方推出的微信开发者工具，是调试小程序的主战场，它集成了一个开发者工具必须包含的能力：代码编辑、模拟器运行、文件管理、使用NPM构建和代码上传。即使你使用uniapp开发代码，最终也需要通过微信开发者工具来编译预览、调试和上传代码，这点不会变。
HBuilderX是DCloud公司的IDE，主要服务于uniapp项目，用户在HBuilderX里写的vue代码最终会编译成小程序包，再把编译产物导入微信开发者工具。关键词里的“HBuilderX开发微信小程序”“hbuilder运行微信小程序提示不是开发者”“在hbuilder x中改变小程序id”基本都出现在这条工具链上。我的经验是，把HBuilderX当作“源代码编辑器”看待，把微信开发者工具当作“最终编译和预览环境”，两边同时打开，但职责清晰。
2. 从零搭建一个最小可运行的原生小程序
2.1 原生项目的目录结构长什么样
打开微信开发者工具，用“小程序-空目录”模板创建一个新项目，填好AppID（账号后台可在“开发管理-开发设置”里看到），稍等几秒就能看到默认的目录结构。最小项目由这几部分组成：
- app.js：小程序的入口脚本，内部注册App实例，定义全局生命周期（onLaunch等）。
- app.json：全局配置文件，注册页面路由、配置窗口外观、TabBar、网络超时时间等。
- app.wxss：全局样式表，作用在所有页面上。
- project.config.json：保存项目配置（appid、编译设置、上传配置等）。
- pages/：存放所有页面，每个页面通常是一个四件套（.wxml、.wxss、.js、.json）。
- utils/：公共工具函数。
- components/：自定义组件。
很多刚入手的人会问“我的小程序头部是不是都长一个样？”答案是，你在app.json里配置window字段，就可以统一设置所有页面的顶部导航栏背景色、文字颜色和标题。例如“小程序动态设置标题”就是在这个基础上做的局部覆盖。
2.2 app.json全局配置：路由、窗口与导航栏
全局配置是最先要理解的文件。所有页面必须在pages数组里注册，不能漏；参数上我常用的是：
{ "pages": [ "pages/index/index", "pages/detail/detail" ], "window": { "navigationBarBackgroundColor": "#ffffff", "navigationBarTextStyle": "black", "navigationBarTitleText": "首页", "backgroundColor": "#f5f5f5" }, "tabBar": { "color": "#999999", "selectedColor": "#1aad19", "list": [ { "pagePath": "pages/index/index", "text": "首页" } ], "borderStyle": "black" }, "sitemapLocation": "sitemap.json" }tabBar最少配置两个页面，最多五个。如果你后期要动态修改标题，页面自身的.json里也可以配置navigationBarTitleText，这比全局配置优先级更高。这个配置细节很容易被忽视：全局配置文件修改后，如果当前页面已经在模拟器打开，不会立即生效，需要重新编译一次。
2.3 页面四件套：WXML、WXSS、JS、JSON各管一摊
页面的四件套其实不是并列关系，各管一层。
- .wxml是页面结构，里面写组件标签和绑定表达式；
- .wxss是样式表；
- .js写页面逻辑、生命周期、事件处理和数据请求；
- .json配置当前页的临时配置，比如自定义导航栏、标题、下拉刷新开关。
我一直跟新人强调一个默认约定：Page必须在.js文件里调用，而且页面数据的初始值放在data字段里，所有需要响应视图变化的数据都需提前声明在data里。虽然小程序框架支持给data动态加新字段，但那是极其不推荐的写法，容易造成视图和数据不一致。下面举一个最纯粹的“点赞”操作示例，这段代码会让首次接触小程序的人秒懂数据绑定的链路：
Page({ data: { likeCount: 0 }, onTapLike() { this.setData({ likeCount: this.data.likeCount + 1 }); } });当你修改data后必须用setData方法而不是直接赋值，setData会同时更新视图层，所以高频更新数据时（比如进度条），注意控制频率和数据量，避免渲染卡顿。
2.4 修改AppID不生效？多半是这里没对齐
关键词里“在hbuilder x中改变小程序id，为什么运行到微信小程序模拟器中，小程序id还是原来的”是特别典型的跨端开发问题。我拆一下背后的机制：uniapp项目编译成小程序后，并不是仅仅依赖某一个配置文件里的appid；微信开发者工具打开项目时读取的是项目内project.config.json里的appid，如果不一致，它会尝试用自己缓存里的旧appid打开项目。
解决办法分三步：
- 先到uniapp项目的manifest.json里的“微信小程序配置”项填入新的appid；
- 重新编译，确认生产环境里的小程序目录下project.config.json也被更新成新的appid；
- 微信开发者工具里，点击“详情-基本信息”看appid，如果不对，直接在工具里用“导入项目——重新选择目录导入”的方式强制刷新；必要时清掉工具缓存后再打开。
“运行到微信小程序时提示不是开发者”通常也出在AppID和登录账号不对应这个根因上。小程序后台有一个规定：AppID归属哪个账号，就必须用该账号登录微信开发者工具才能编译上传。换句话说，如果你用A账号注册了AppID，却在B账号登录的情况下打开项目，B对这个项目没有任何权限。你要么在工具里切换成A账号，要么在项目后台把B微信绑定为开发者。
3. 页面与交互的常见开发点
3.1 自定义导航栏标题与上边距处理
“小程序头部标题叫什么”和“小程序自定义标题，上边距怎么弄”都是新手的常规疑问。顶部那个承载标题和胶囊按钮的区域，在官方文档里叫导航栏navigation bar；胶囊按钮指右上角“三个点”加“圆圈”组合的固定控件，这个小东西在iOS和Android上位置不完全一致，于是自定义导航栏时计算顶部安全区域就必不可少。
如果你希望统一视觉，在页面的.json里开启：
{ "navigationStyle": "custom" }这就表示本页面不使用默认导航栏，标题需要自己在wxml里画，此时就会遇到胶囊按钮垂直方向居中对齐的问题。推荐的做法是用微信官方提供的胶囊按钮布局信息做计算，而不是自己瞎猜：
const menuButton = wx.getMenuButtonBoundingClientRect();得到的结果包含胶囊按钮的top、right、width、height，然后自己导航栏的高度可以这样估算：胶囊按钮的top值 - 状态栏高度，就是导航栏需要留的“上下留白”中的上半间距，胶囊按钮的bottom到屏幕顶部的距离，等于导航栏内容的总高度，这基本上就是来自系统的安全区间。把导航栏高度设置成跟胶囊按钮对齐一致的原生视觉效果，会扫一眼就觉得很“正规”。
3.2 动态设置页面标题：页面的json、全局json、wx.setNavigationBarTitle
“小程序动态设置标题”更准确的文案是“如何根据业务数据实时更新页面导航栏的标题”。场景很常见：打开一个商品详情页，希望导航栏显示商品名称；打开一个用户分享页，希望显示分享者昵称。在页面js里一行代码即可：
wx.setNavigationBarTitle({ title: '自定义标题文本' });需要注意：wx.setNavigationBarTitle调用时会短暂覆盖页面json里配置的标题，但仍受全局和页面配置中导航栏背景色等字段的控制。还有一点，尽量不要在onLoad里和页面json的初始标题打架，常见的做法是在json里给一个兜底默认标题，等拿真实网络数据的回调里再覆盖。
3.3 单选框：系统看着丑，自定义又很烦？有固定套路
“微信小程序单选框”这个热搜词经久不衰，因为radio组件的原生样式一点就变形，在不同机型上间距、尺寸都不一样。真正稳妥的实现方案是用自定义点击态代替原生radio。核心思路：把视觉样式“炒”了，原生radio只作为无障碍辅助，视觉上的圆圈和选中态全用view+class控制。
比如一个性别选择题，可以在wxml里写两套可用样式，点击时通过data里的selected字段来决定谁高亮，而不是依赖radio的checked状态：
<view class="option {{selected === 'male' ? 'active' : ''}}" bindtap="selectGender">wx.getImageInfo({ src: tempFilePath, success: (res) => { // 计算等比缩放宽高，再用canvas绘制后导出 } });使用canvas这里有一个教训：canvas在转换图片前一定要确保页面里已经有canvas组件节点，否则会一直报“canvasToTempFilePath: fail”类错误。建议在wxml中放置一个绝对定位、移出可视区的canvas，专门当“压缩工作站”。
4. 音视频、蓝牙等设备能力，功能开发里面的硬骨头
4.1 音频播放与缓存路径：缓存去哪儿了？
“微信小程序音频缓存路径”是很多做音频类小程序比较头疼的问题。你调用wx.createInnerAudioContext()播放网络音频时，播放器内部会自动做缓存，但微信官方从未把这个内部缓存路径开放给开发者。换句话说，你拿不到“当前音频文件已经下载到本地哪个位置”。如果你真的希望把音频文件持久化管理，必须自己下载文件到本地。
实际操作是用wx.downloadFile拿到临时文件路径tempFilePath，再保存到本地用户目录：
wx.downloadFile({ url: 'https://example.com/audio.mp3', success: (res) => { const fs = wx.getFileSystemManager(); fs.saveFile({ tempFilePath: res.tempFilePath, success: (savedRes) => { // savedRes.savedFilePath 就是长期文件路径 } }); } });要注意两点：一是本地文件存储是存在总大小限制的（小程序本地文件上限是200MB左右，不同版本政策有微调），超了就必须自行清理；二是不能拿一个长期本地路径去做播放前检测文件是否还存在，需要借助FileSystemManager.access或stat来确认。
4.2 video组件不能播放？八成不是代码问题
有一个经常让人莫名其妙的现象：某些视频在开发者工具里能播，在真机上黑屏；或者同一段视频安卓可以播，iOS无法播。排障经验依次检查三件事：
- 视频源URL是否支持HTTPS（正式版环境强制走HTTPS，明文HTTP在开发者工具或许能播，但真机大概率不行）；
- 视频编码格式是否符合要求（微信官方对video的推荐编码是H.264 AAC的MP4，很多用户自己转码的MKV / WMV文件是无法播放的）；
- 视频是否设置了防盗链，微信小程序的请求头里没有Referer或自定义授权，如果服务器校验了Origin、Referer，会把播放请求拒绝掉。
这一块不要上来就把锅甩给代码，先拿浏览器、手机自带播放器分别试同一条视频源链接，能快速区分是源的问题还是小程序的问题。
4.3 swiper嵌套video导致全屏错位？iOS上典型的层级问题
“小程序 ios中swiper组件嵌套video组件导致全屏错位解决方案”是原生组件的经典问题。video是微信小程序的“同层渲染组件”，在iOS上同层渲染机制虽然比曾经的“原生组件盖在webview之上”先进不少，但在swiper内部做全屏切换时依旧容易出现全屏播放后video无法恢复原来位置、或者视频画面拉伸错位的问题。
常见处理手段也简单：不要把video作为swiper-item的直接子元素，给video外面包一层view，同时避免在swiper-item上执行对video做诸如position:fixed这种会导致原生组件重定位的样式。如果一定要实现“横向滑动多视频卡片，点击卡片中的视频全屏播放”的复杂交互，推荐方案是：列表里不直接放video而是放封面图，点击后用覆盖全屏的video层单独播放，这样从根本上规避了swiper和video的层级问题。损失一点“自动播放前置预览”体验，换来稳定性，在商业项目里我觉得是值得的。
4.4 蓝牙打印：别直接梭哈“连接打印机”就完事
“微信小程序 蓝牙打印”在票务、餐饮小票、仓储标签场景里出现频率特别高。开发核心链路为：
- wx.openBluetoothAdapter开启蓝牙；
- wx.startBluetoothDevicesDiscovery搜索设备；
- wx.createBLEConnection建立连接；
- wx.getBLEDeviceServices获取服务列表；
- wx.getBLEDeviceCharacteristics获取特征值；
- 通过wx.writeBLECharacteristicValue把打印数据写入特征值。
最容易踩的坑在于打印数据格式。小票打印机大多用ESC/POS指令，必须把文本先编码成GBK与打印指令拼接的ArrayBuffer，直接用UTF-8编码会让打印机打出乱码。这里没有通用的“一行代码实现”，必须根据打印机厂家SDK或指令文档来做编码转换。
蓝牙打印调试时最烦的是搜索不到设备：首先要确认小程序蓝牙权限已经在手机系统设置里被允许，然后要调用wx.getBluetoothAdapterState检查蓝牙适配器状态。如果在开发者工具里模拟就压根别指望能搜到真实设备，真机调试才能测通这一条链路。
5. 前后端交互、跳转与业务能力接入
5.1 接口域名：HTTPS、合法域名、开发环境豁免
无论你是自建后端还是使用云函数，小程序的前端网络请求都有明确约束：request请求URL必须使用HTTPS，并且域名必须在小程序后台的“开发管理-服务器域名”中添加完毕。
关键词里的“u-swiper 小程序不在支持http”应该来自uniapp和uView的一个问题回忆，本质就是该资源走HTTP而不是HTTPS，微信会拒绝加载。在开发调试阶段，可以在微信开发者工具的“详情-本地设置”中勾选“不校验合法域名、web-view、TLS版本以及HTTPS证书”，这样就能用http://127.0.0.1或局域网IP调试本地接口。不过很多人会在这里被坑：真机调试没有“开发环境豁免”这个开关，真机预览时默认依然强制证书和域名校验。所以我建议平时就把后端接口都统一配成HTTPS（本地可以用Nginx挂一张临时证书），省得每次切换环境都要去后台配域名。
5.2 订阅消息：推送方案的最佳解
几乎每个小程序做到后期都会遇到“推送消息方案”的诉求。微信现在不开放长期通用的模板推送，只能通过用户主动订阅触发一次性订阅消息；关注公众号与小程序绑定的“统一服务消息”能力也早有限制。目前主流的推送方案组合是：
- 模板订阅消息（一次性，用户点同意按钮后下发一次）；
- 小程序与公众号关联后，通过公众号模板消息推给关注用户（需要公众号权限）；
- 长期消息类场景（如订单发货通知）不存在，不过如果业务有“一次性订阅可重复授权”的需求，可以多次调用wx.requestSubscribeMessage诱导用户重复点击授权，这仍在合规边界内。
订阅消息有一个隐藏坑：用户在生命周期内如果勾选了“总是保持以上选择，不再询问”，微信就会直接按该选择执行，不再弹窗。你的按钮在用户点击后要立刻处理返回状态，不能假设每次都弹出授权框。
5.3 微信支付V3：为什么提示“小程序违规，支付功能暂时无法使用”
“小程序微信支付v3对接 由于小程序违规，支付功能暂时无法使用”这些关键词直接指向一个现实：支付能力一旦被封，基本是账号级处罚，不是你代码里“改一点配置”就能恢复的功能。
先明确概念：微信支付商户号绑定了小程序AppID后，小程序调用wx.requestPayment拉起支付。如果后台判定你的小程序或商户号有违规风险（比如被投诉、类目与实际经营内容不符、虚拟支付被查等），那么支付能力会被冻结或限制。
遇到这种情况的正确做法是：
- 到微信公众平台后台查看站内信和违规记录，定位具体处罚原因；
- 按要求整改页面内容、下架违规功能，或补充对应资质；
- 在“申诉中心”依流程提交申诉材料，等待审核。
千万不要去网上找所谓的“破解无限恢复”工具，大概率是钓鱼或骗钱的。支付是资金安全红线，最可靠的手段是确保业务合规。做虚拟支付（充值、会员、VIP解锁）的个人开发者尤其要小心，规则越来越严。
5.4 小程序跳转H5、小程序跳小程序
在小程序里跳转H5有两个方向：
- 用web-view组件直接承载H5页面（网页需要配置业务域名，小程序主体的业务域名也要在后台添加，个人主体不让直接用web-view，这点限制要确认）；
- 如果想在H5里跳小程序，需要走开放标签的URL Link或URL Scheme方式（如“明文scheme拉起此小程序 ”问题中出现到的就是这种，scheme配置一般需要成功发布且类目符合条件）。
小程序A跳小程序B是日常高频操作。官方API是wx.navigateToMiniProgram，且需要在app.json或点击的用户操作处记录跳转的appId与path。同时要注意，被跳的小程序与当前小程序必须在同一个微信开放平台账号下绑定吗？答案不是必须。不过有一种受平台强限制的情况：如果A要跳B的特定页面（如分包页面），那么B方需要在后台配置“分包加载规则”，甚至需要双方在后台做关联。实际上很多产品只做到跳转到目标小程序的首页，这样几乎所有小程序都支持，但跳进分包页面就必须提前在后台核实路径是否被允许。
我去年就遇到过一模一样的排查过程：A项目通过URL Scheme方式拉起自己的小程序，但配置的path是分包路径，一直报错“配置分包路径不行”。原因是URL Scheme生成时只能拉起主包页面，若目标是分包，需要升级为“小程序普通链接”或者用“小程序码”的方式，后者带scene参数，再从scene里解析并做分包路由跳转。
6. 调试、测试和上线发布
6.1 版本路线：开发版、体验版、审核上线
代码完成后的发布流程非常关键，不少第一次做的人以为“上传代码=上线”，结果卡了很久。微信小程序版本一共四个状态：
- 开发版：你在开发者工具里点“编译”，本机可见。
- 体验版：在开发者工具点击“上传”后，到微信公众平台后台“版本管理-开发版本”，把刚上传的版本选为体验版。体验版可以生成体验二维码，指定体验成员扫码后能看到。
- 审核版本：在版本管理页面点“提交审核”，等微信官方审核。
- 线上版本：审核通过后点“发布”，全量用户可见。
这里要掌握一个技巧：上传版本时填写的“版本号”和“项目备注”要规范。版本号通常按日期+序号管理，比如v1.0.0对应首个可用版本。无论是否使用uniapp，小程序代码上传都会走这个流程。
6.2 模拟器与真机调试、核心调试逻辑
开发者工具自带模拟器虽然方便，但它永远无法替代真机页面。微信官方针对不同的调试场景提供了几种能力模块，大多数人没完全弄明白它们之间的区别：
- 在开发者工具中直接运行，属于“模拟器调试”，适合做布局逻辑、接口数据结构调整。
- 点击“预览”会生成预览二维码，手机扫码后进入真实小程序环境，这是体验版之外最快的真机调试途径。真机预览时你可以打开“真机调试”，它会在手机端拉起调试程序，从而看到console日志、network请求。
关键词里好几个问题都和Android或iOS系统环境相关，比如iOS软键盘遮挡输入框、安卓WebView渲染差异等等。这类问题用“有条件能本地复现+模拟器对点击”的方式基本都能解决，核心点是：模拟器上页面显示正常，不代表真机正常，涉及相机、地图、蓝牙、音视频的地方一定要真机实测。另一个经验是模拟器中一些诱导分享、扫码、跳转外部App的场景是没法真实完成的，需要用真机验证。
6.3 上线前必须检查的几件事
我习惯在提交审核之前走一遍“上线自查清单”，用下面这个列表对照检查，每一条看起来琐碎，但漏一个都可能造成不必要的拒绝或事故：
- 首页是否展示用户协议与隐私政策，尤其是涉及手机号、定位、相册权限的；
- 建议提供“隐私保护指引”并关联组件用途说明；
- 支付功能如果还在开发中，清理掉测试订单和测试支付开关；
- 接口域名必须全部是HTTPS，且已在后台配置合法域名；
- 登录态过期时要做好401后端返回并让用户重新登录；
- 图片资源不能有版权争议，字体使用不能是未授权商业字体；
- 在iOS上禁用不了第三方输入法、但页面必须整体适配虚拟键盘。
审核被拒最高频的关卡反而和代码无关：类目与页面内容不符、缺少资质、诱导分享。做任何功能前建议先看《微信小程序平台运营规范》。
7. 从“能上线”到“有特色”：热门玩法与技术扩展
7.1 给小程序接入AI能力，其实没有想象中难
“小程序接ai助手”近几年成了热点方向。如果你有后端服务，可以封装一个简单的对话接口，在小程序端通过request把用户文本发给服务端，再由服务端调用大模型API，返回结果后通过流式接口或一次性返回渲染到页面。如果你没有独立后端，可以尝试云开发里使用云函数调用AI平台接口，同样能实现“不用买服务器就能跑通demo”的诉求。
不过提醒一句：在接入AI之前，先确认服务的合规和法律风险；面向未成年人的场景要用内容安全检测接口过滤输入输出，避免出现风险。
7.2 从“静态展示”到“实时设备控制”：用MQTT协议做IoT类小程序
关键词“ai小程序mqtt”说明有人已经在思考“AI+小程序+物联网”的结合了。MQTT是一个轻量级消息传输协议，很适合做远程控制灯、开关、传感器这类场景。小程序自身不直接支持MQTT，需要引入mqtt.js库到项目中，然后通过与服务器建立WebSocket连接收发消息。设备端上报时，小程序订阅对应的topic，就能实时收到状态变更并刷新使用界面。
mqtt.js在小程序环境中比较棘手的地方在于它默认依赖浏览器环境的部分API，community里很多现成npm包在小程序运行时需要添加适配。简单说：直接在小程序里嵌入mqtt.js，未必能开箱即用，遇到“WebSocket is not defined”是常态，正确姿势是找到同时兼容小程序环境的那一版并做好全局域适配，或者用官方云开发WebSocket通道做中转，协议层面不直接暴露MQTT给前端。
7.3 快速复用：源码、模板与“复用外包方案”
很多人搜“源码”“小程序商城”“壁纸小程序源码”其实是希望有个起点，而不是完全从零开始。不过我的建议一直是：不要拿着网上所谓完整源码就去上线，因为经常发现打包上传时格式异常，或者包含另一个人的开发者ID、支付商户号、后台接口、潜在的前端漏洞。源码的最大价值是“学习参考”，不是“直接可用”。
一种更好的快速起步方式是在官方提供的各种基础模板、uniapp插件市场或一些开源项目中寻找结构参考，自己重做页面样式、改接口域名和密钥。这既能节省时间，又能确保代码里没有不明来历的后门。这里也建议正式项目中不要使用任何硬编码的密钥在代码包里，正确方式是通过服务器下发或本地storage加密存储。
7.4 电商类小程序：支付、资质、商城模块
“saas餐饮外卖小程序源码”“小程序商城”是商业需求的大头。我简单列一个实用小程序商城需要的模块清单：
- 商品列表与详情页（含图文、SKU选择）；
- 购物车与收货地址管理；
- 订单创建、订单支付、订单状态回调；
- 物流信息展示；客服会话（小程序内置客服按钮）；
- 用户登录与手机号授权；会员体系与优惠券。
要注意的边界仍然是个人主体无法做交易，必须企业主体。微信支付也会校验商户号和商户类目。商城类小程序至少要配置“微信支付”及对应的“商户平台证书”，如果使用V3接口还要做好证书APIv3、证书序列号配置。这类功能我建议用成熟SaaS或云开发模板起步，而不是自己从零写支付对接，要支付前的改造工作量远大于想象。
8. 当我再来一遍，会重点对这几件事增加注意力
实际做小程序多次之后，我对“创建自己的小程序”这个看似入门的话题有了比纸上知识更深的体会。
第一，技术本身不是门槛。真正的门槛是需求边界、资质边界和平台规则。你代码写得再好，主体选错、类目不符、域名没备案、支付违规处理不当，项目都会被迫原地踏步。
第二，调试工具链要尽早理顺。开发者工具里各版本、模拟器与真机调试、正式版与体验版的关系，新手阶段很容易犯逻辑混乱，要一直保持“接口数据必须先定下来再设计页面”的思路。否则你会在“数据处理”上翻来覆去改版，而不是在视觉层工作。
第三，复用能力和体系化的知识地图是最长线的资产。我今天写的这些语言，是我在小程序技术群、项目开发和个人开发中逐步踩通的经验积累。如果你也要自己创建小程序，走完整条路径会积累很多别人从未经历过的问题。
最后再分享一个小技巧：微信开发者工具收集数据时能记得开启“自动保存”，并搭配Git做版本管理，按照“功能分支-开发-合并-打tag”的流程走。就算你只是个人开发者，也请认真对待版本管理。我见过太多开发者一个多月改同一套代码却只有一个“最终版.zip”，调试bug时连回滚都做不了。小程序发布是严格不可逆的线上行为，留好每一版代码，会为你未来的每一次维护节省大量时间。
