企业官网建设流程全解析

微信小程序开发这件事，真正难的从来不是某个 API 怎么调，而是「这个需求到底该不该用小程序做」以及「做出来为什么这么卡」。我带过几个从零起步的团队，也接手过别人写了一半的项目，发现新手卡住的地方高度重合：不理解双线程模型、不知道 setData 到底贵在哪、包体积超了才想起来分包、提审被驳回三次才去看规则。这篇东西就是想把这些年踩过的坑一次性摊开讲清楚，从技术路线选型、工程结构、核心能力落地，到性能抠细节、提审避雷，全部按实际动手顺序来写。不管你是刚装好开发者工具的新人，还是已经能写页面但总觉得项目「不够专业」的熟手，应该都能从里面拎出几条明天就能用上的东西。

1. 技术路线选型：先想清楚再动手

1.1 什么样的需求适合做成小程序

判断一个需求适不适合，我一般看三个维度：使用频次、交互复杂度、传播路径。小程序的核心优势是「即用即走 + 天然可分享」，用户不用装、不用注册，扫个码或者点个卡片就进来了。所以那些低频但强场景的需求特别合适，比如线下门店点单、活动报名、设备报修、展会导览、票据核销。这类需求如果做成 App，用户为了用一次要下载几十兆，转化率会掉得很难看。

反过来，有几类需求我建议直接劝退。第一类是重交互长流程的，比如视频剪辑、复杂表单填报、多步骤编辑器，小程序的页面栈最多十层，复杂状态管理会让你写到怀疑人生。第二类是强离线依赖的，本地存储有单 key 和总量的限制，做不了大文件缓存。第三类是需要后台常驻的，小程序没有真正的后台运行能力，任何依赖定时任务的设计都要重新想。

还有一个经常被忽略的点：包体积是有硬上限的。主包和单个分包都有体积约束，整体体量也有天花板，这个数字平台在不同时期调整过，做方案时别背死数字，去官方文档确认当前值。这意味着你不可能把一个几十兆的资源包直接塞进去，图片、字体、音视频必须走 CDN。我在项目初期就会把这条摆到桌面上，避免做到一半发现素材放不下要重构。

1.2 原生开发、跨端方案、云开发怎么选

这是选型阶段最容易吵架的地方。我的经验是：看团队现有技术栈和长期维护成本，而不是看哪个听起来先进。三种路线各有明确适用边界，下面这张表是我自己在做技术评审时用的对照。

我自己项目的选择逻辑是这样的：如果这个产品未来一年内明确只在小程序里跑，选原生，别犹豫。如果老板开口就是「后面还要上 App 和 H5」，那就老老实实用跨端框架，但要提前接受包体偏大、某些原生组件要单独适配的事实。云开发适合 MVP 阶段验证想法，等活动跑通了、数据量上来了，再评估要不要把核心业务迁到自建服务。

注意：跨端框架不是银弹。我见过团队为了「一套代码多端跑」选了跨端方案，结果三个端各写了一套兼容补丁，维护成本反而更高。选之前先问自己一句：另外那几个端，真的有人用吗。

2. 工程骨架：目录、配置与调试环境

2.1 一套页面四个文件，这个设计解决什么问题

刚接触的人最容易困惑的是：为什么一个页面要拆成.wxml、.wxss、.js、.json四个文件。这背后是视图层与逻辑层分离的架构决定，不是随便定的。渲染层负责把结构画出来，逻辑层跑在独立的 JavaScript 引擎里，两边通过消息通信。逻辑层里没有 DOM、没有 BOM、没有 window 和 document，所以你拿 jQuery 那一套去操作节点是行不通的，想改视图只有一条路：把数据交给setData，让渲染层自己重绘。

理解这一点，很多「玄学问题」就有解释了。比如为什么不能像网页那样直接给某个元素加类名，为什么要用数据驱动的方式控制显隐，为什么频繁通信会卡。app.json负责全局配置——页面路径注册、窗口表现、底部导航、分包声明；页面级的.json只覆盖当前页面的窗口配置，比如标题、下拉刷新开关。.wxml是模板，支持数据绑定、条件渲染、列表渲染，还有wxs可以写少量在渲染层执行的逻辑，用来避免「为了格式化一个时间戳就通信一次」的浪费。

尺寸单位用rpx，规则很简单：屏幕宽度恒等于 750rpx。所以设计稿如果是 750 宽的，量多少写多少；如果是 375 宽的，数值乘 2。这个自适应机制让多机型适配省了很多事，但要注意一点——rpx在超大屏（比如平板）上会算出很大的物理尺寸，图文混排的页面建议对容器加max-width约束，否则字会大得离谱。

2.2 开发者工具里那些真正好用的面板

大多数人只用了「编译」和「真机预览」，其实调试面板里有几个东西能省掉大量时间。Wxml 面板可以实时看到节点树和当前节点的样式计算结果，排查「样式没生效」比在代码里瞎改快十倍。Storage 面板能直接看本地缓存里存了什么，登录态丢失这类问题基本靠它定位。Network 面板会列出所有网络请求的耗时、状态码和返回体，接口偶发失败时抓一次就知道是超时还是服务端报错。

真机联调这块有个细节值得说：模拟器和真机差别比想象中大。iOS 和 Android 在键盘弹起、滚动惯性、字体渲染、position: fixed的表现上都有差异，尤其是键盘遮挡输入框这个经典问题，模拟器上永远复现不出来。我的习惯是每写完一个交互稍复杂的页面，立刻真机过一遍，别攒到最后一起测。真机调试打开后可以在电脑上看到真机的运行日志，比在手机上盲猜强得多。

提示：在工具里勾选「不校验合法域名」只对开发阶段有效，上线前必须把请求域名、上传域名、下载域名在后台配置齐全，否则真机上请求会全部失败——这个坑几乎每个项目都会踩一次。

3. 核心能力落地：数据、请求与登录态

3.1 生命周期不是背下来的，是理解执行顺序

页面生命周期里最常被误用的是onLoad和onShow。onLoad只在页面首次加载时触发一次，接收页面参数；onShow每次页面出现在前台都会触发，包括从其他页面返回。所以列表数据的刷新放在onShow，一次性的初始化放在onLoad。我见过有人把列表请求写在onLoad里，结果从详情页返回后数据还是旧的，用户以为没保存成功。

还有一个高频问题：onLoad里拿不到节点尺寸。因为这时候视图还没渲染完，要等onReady之后才能做测量类操作，比如计算滚动区域高度、获取元素的位置信息。如果你在onLoad里就调测量接口，拿到的是 0 或者报错。

卸载阶段要记得清理。定时器、事件监听、长连接，全部在onUnload里释放。我接手过一个项目，页面里开了个轮询定时器忘记清，来回切了二十几次页面之后手机明显发烫，日志里全是重复请求。这类问题排查起来很费时间，写的时候就养成习惯最省事。

3.2 setData 的正确姿势与它的真实成本

setData是整个开发里最需要「心疼」的接口。它的完整链路是：逻辑层把数据序列化，通过通信通道传到渲染层，渲染层做差异对比再更新节点。所以它的成本跟数据量大小和调用次数都相关。官方建议单次传递的数据别超过 1MB，实际项目里我建议控制在几十 KB 级别，超过就该想想是不是设计有问题。

几个实操要点。第一，只传变化的部分，不要把整个大对象重新塞一遍。列表里改一项，用路径写法精准更新：

// 不推荐：整个列表重传 this.setData({ list: this.data.list }); // 推荐：只更新指定下标字段 this.setData({ 'list[3].status': 'done', 'list[3].updateTime': Date.now() });

第二，跟视图无关的数据不要放 data 里。比如定时器句柄、请求的中间态、缓存的计算结果，全放data只会让每次setData的重量无谓增加。用普通实例属性挂在this上就行，页面实例本身就是个普通对象。

第三，高频事件要节流。滚动、输入、拖拽这些事件一秒能触发几十次，每次都setData必然卡。输入框做实时搜索，正确做法是防抖 300 毫秒再发请求，中间态用wxs或者局部变量兜住，别一路setData到底。

3.3 网络请求封装：别在页面里直接写 wx.request

原生wx.request是回调风格，没有 Promise，不封装的话页面里会堆满嵌套回调。更要紧的是并发请求数量是有限制的，同时发太多会被排队甚至失败，所以工程里必须有一层统一封装来处理超时、重试、错误提示、登录态失效。

我常用的封装结构是这样：一个request方法负责拼域名、加公共头、统一处理业务码，超时设 8 到 10 秒；遇到鉴权失效的返回码，先静默刷新登录态再重放一次请求，而不是直接把用户踢出去。

const BASE_URL = 'https://api.example.com'; function request(options) { const { url, method = 'GET', data = {}, retry = true } = options; return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + url, method, data, timeout: 10000, header: { 'content-type': 'application/json', 'Authorization': wx.getStorageSync('token') || '' }, success(res) { if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data); } else if (res.data.code === 401 && retry) { refreshToken().then(() => request({ ...options, retry: false })) .then(resolve).catch(reject); } else { wx.showToast({ title: res.data.message || '请求失败', icon: 'none' }); reject(res.data); } }, fail(err) { wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' }); reject(err); } }); }); }

这段代码看着朴素，但解决了实际项目里 80% 的网络层问题。要注意的是刷新登录态本身也要防止并发雪崩——多个请求同时 401 时，不能让它们各自去刷新一次，得用一个共享的 Promise 把它锁住，所有等待者复用同一次刷新结果。

3.4 登录态：前端只做搬运，不做裁决

登录流程的边界必须划清楚。前端调用登录接口拿到临时凭证，这个凭证只能交给自己的服务端，由服务端去换取用户唯一标识和会话密钥，密钥绝不能下发给前端。前端拿到的是自己服务端签发的 token，存本地，随请求带上。

几个必须注意的点。token 别只存不管，要设计过期时间，配合上面的静默刷新。用户信息这块，平台经过多次调整后，昵称和头像已经改成由用户主动填写的组件能力，也就是用按钮选择头像、用输入框填写昵称，不再支持静默获取。设计注册流程时要把这个交互提前，别等到提交订单那一刻才弹授权，用户的流失率会很高。

注意：本地存储有容量限制，单个 key 和总量都有约束，不要往里塞大对象或者图片的 base64。需要持久化的业务数据，正确做法是存服务端，本地只做缓存和兜底。

4. 性能与包体积：上线前必须抠的两件事

4.1 分包、按需注入与首屏时间

首屏速度直接决定用户会不会留下来。影响因素里，包体积是最大头——下载、解压、解析都要时间。所以主包里只放首页和公共基础代码，其余页面全部拆到分包。配置上在全局配置里声明分包路径和对应页面，主包引用分包内容会报错，这个约束反过来逼迫你把依赖关系理清楚。

{ "pages": ["pages/index/index", "pages/login/login"], "subpackages": [ { "root": "packageA", "pages": ["pages/detail/detail", "pages/list/list"] }, { "root": "packageB", "pages": ["pages/order/order"] } ], "preloadRule": { "pages/index/index": { "network": "all", "packages": ["packageA"] } } }

分包预下载是个很实用的能力：用户在首页停留时，后台悄悄把接下来最可能访问的分包拉下来，点进去就是秒开。但别贪心，把所有分包都预下载会抢占带宽，反而拖慢当前页面的请求。

还有一个容易被忽略的开关：按需注入。开启之后，只有当前页面真正用到的自定义组件才会被注入，能明显压低启动时的初始化开销。开启后要留意一个副作用——某些通过动态方式引用的组件可能失效，需要显式声明，所以开启后必须把主要页面全量回归一遍。

4.2 长列表与渲染开销的实战处理

超过一百条数据的列表，直接全量渲染一定会卡。原因在于每个节点都要走一遍渲染流程，节点数一多，通信和布局都会成为瓶颈。处理方式有三种，按复杂度递增。

最轻的做法是分页加载 + 触底追加，一次渲染二三十条，用户滚到底再加载下一批。这个方案实现成本最低，适合大部分场景。第二种是骨架屏 + 分批渲染，先把占位骨架画出来，数据到位后分批setData填充，避免一次性大数组塞进去造成长时间白屏。第三种是虚拟列表，只渲染可视区域内的节点，滚动时复用节点，适合几千条以上的数据。前两种原生就能做，第三种建议用成熟的列表组件，自己手写容易在滚动位置和节点复用上翻车。

图片是另一个性能黑洞。列表里的图片必须指定明确尺寸，否则布局会抖动；必须用平台提供的懒加载能力或者自己监听可视区域；必须压缩，能用 WebP 就别用 PNG。我见过一个列表页因为图片没压，首屏加载了三秒多，压完之后直接降到一秒内，这种优化投入产出比高得离谱。

5. 提审、发布与驳回排查实录

5.1 提审前的自查清单

审核驳回是新手最挫败的环节，其实大部分驳回原因就那么几类。我在每次提审前都会过一遍下面这张表。

这张表里的每一条我都真实遇到过。尤其是「功能不完整」这条，小程序里留一个写着「即将上线」的卡片，审核就过不去，必须把这个入口整个隐藏掉再提审。

5.2 被驳回后的处理思路

收到驳回别急着反复提交，先看清楚驳回理由是「功能类」还是「资质类」。功能类的改代码就能解决；资质类需要补材料，反复提交只会延长周期。有个经验：驳回理由描述得越笼统，越要检查最基础的环节。如果只说「功能不完整」，八成是某个入口点进去白屏；如果说「涉及某类服务」，就去看类目和资质。

还有一个实操技巧：提审版本的描述里把「这个版本改了什么、怎么测试」写清楚，最好附上测试路径。审核员每天看成百上千个包，你写得清楚，他理解得快，误判的概率就低。这不是玄学，是效率。

6. 常见问题速查与踩坑记录

6.1 高频问题对照表

下面这些是我这些年被问最多、自己也踩最多次的问题，整理成表方便对照查。

6.2 几条不太会写在文档里的经验

第一条，别过早引入状态管理库。小项目用页面 data 加一个全局对象就够了，引入重型状态管理反而增加理解成本。等到确实出现「多个页面共享复杂状态」的痛点，再上也不迟。我见过一个只有五个页面的项目上了完整状态管理方案，新人接手看了一下午才搞懂数据从哪来。

第二条，自定义组件要早拆。按钮、空状态、列表项、弹窗这些重复元素，第一天就抽成组件。前期多花半小时，后期改需求时省下的是几小时。组件通信优先用属性和事件，跨层级再考虑更重的方案，别一上来就搞全局事件总线，那玩意儿调试起来全是黑盒。

第三条，新渲染引擎可以试，但要留退路。平台近几年在推新的渲染引擎，在高频交互场景下确实有提升，但组件兼容性和老代码适配需要评估。我的做法是新项目可以开，老项目先在一个次要页面灰度，观察一周崩溃率和用户反馈再决定要不要全量。

第四条，性能问题先量再改。别凭感觉猜哪里慢，用工具里的性能面板跑一遍，看看到底是启动慢、渲染慢还是请求慢。我遇到过一个团队花了三天优化列表渲染，最后发现瓶颈是接口返回了两兆的冗余字段。定位比优化重要得多。

最后分享一个我自己一直在用的小习惯：每个项目建一个notes.md，把踩过的坑、当时的报错、最后的解法记下来，按日期排。三个月后回头看，这份笔记比任何教程都贴合你自己的项目。我上一个项目交接给别人时，那份笔记直接省掉了对方至少一周的摸索时间。写代码的手艺，很大一部分就藏在这种一点一点攒下来的记录里。