企业官网建设流程全解析

最近因为一个实际项目需要，我开始从 Vue 转向微信小程序原生开发。说实话，刚开始我是有点抗拒的——Vue 写习惯了，响应式数据、计算属性、组件化、脚手架这些用起来太顺手了，突然让我回到"原生"两个字，总觉得是在复古。但真正把小程序原生跑起来、写上几个页面之后，我发现这两者之间的关系其实比想象中微妙：既不是完全陌生，也不是简单换个语法。

这篇笔记是系列里的第六篇，记录了我作为 Vue 背景开发者学习小程序原生的真实体会。重点不是教小程序 API 怎么用，而是把"用 Vue 的方式写小程序"和"用小程序原生方式写小程序"之间的思维差异掰开揉碎讲清楚。如果你也正从 Vue 转过来，或者犹豫到底要不要学原生，这篇文章应该能帮你少踩一些我踩过的坑。

1. 两个"前端生态"的定位差异：先搞清楚你在写什么

1.1 原生小程序到底"原生"在哪

很多从 Vue 转过来的朋友，第一次打开微信开发者工具，看到 WXML、WXSS、JS、JSON 四个文件的时候，大概率会想："这不就是个换皮版的 HTML + CSS + JS 吗？"这个第一印象不算错，但它很容易掩盖一个重要事实：小程序并不是一套网页技术，它是一套由平台定义的、运行在特定容器里的应用开发范式。

Vue 是什么？它是一个 JavaScript 框架，你可以在浏览器里用，也可以在 Electron 之类的环境里用。它的核心价值是"状态驱动视图"这套开发体验，至于最终怎么把界面画出来，Vue 并不关心。而小程序原生开发不一样，它的 WXML 和 WXSS 是平台自己的标记语言和样式语言，压根不直接等价于 HTML 和 CSS。也就是说，你写的小程序页面最终不是由浏览器渲染的，而是由小程序容器解释执行、通过原生组件呈现出来的。

这就带来一个很实际的影响：你在 Vue 里依赖的很多浏览器特性、DOM API、甚至某些 CSS 写法，在小程序里根本不存在。比如你不能操作 DOM，没有 window 和 document，也不能用 innerHTML 去动态塞一段 HTML。刚开始我习惯性地在想"这个元素我能不能 document.getElementById 一下"，结果发现这套路在小程序里是完全走不通的。所以与其说小程序原生是"另一种前端写法"，不如说它是一个独立的应用开发体系，只不过长着一张前端面孔。

1.2 为什么我建议先学原生而不是直接上跨端框架

现在社区里有很多跨端框架，可以让你用 Vue 或 React 的语法去写小程序。刚接触小程序的时候，我也动过这个心思：既然 Vue 熟练，直接套一层框架，不就能无痛切换了吗？但实际走下来，我的建议是：如果你是第一次接触小程序，至少先老老实实写一个原生项目，再决定要不要上框架。

原因有两层。第一层，跨端框架本质上还是编译到小程序原生语法，它会帮你管理模板转换、状态同步、组件映射这些东西。但一旦遇到框架覆盖不到的边缘情况，或者需要排查性能问题时，你最终还是得回到原生这一层去看它生成的代码、看小程序自己的文档。如果完全没有原生基础，排查起来会很吃力。第二层，原生小程序其实并不难，它的核心概念就那么几个，比如 Page、Component、setData、生命周期。花一两周把原生搞明白，后面再看任何跨端框架，都会觉得豁然开朗，因为你已经知道框架替你解决了什么问题、保留了什么限制。

2. 目录与文件：从"单文件组件"到"四件套"的结构思维

2.1 .vue 文件 vs 小程序页面的四件套

Vue 单文件组件把模板、脚本、样式都塞进一个 .vue 文件里，结构清晰，一个组件的所有代码都在一个地方，维护起来很舒服。小程序则把一个页面拆成四个文件，同一个名字，不同后缀，放在同一个目录下：

第一次看到这种拆分，我内心是有点嫌弃的，觉得"一个文件能搞定的事搞四个文件"。但用得多了之后，我反而觉得这种拆分有一种笨拙的合理：小程序平台的工具链不支持像 Webpack 那样自由地组合资源模块，四个文件按同名约定自动关联，是平台实现"模板与逻辑分离"的一种最直接的方式。而且页面级 JSON 文件这个设计挺有意思，它让你可以在页面粒度配置导航栏标题、背景色、窗口表现，而不必跑到全局配置里去改。这在写多个 Tab 页面或者不同风格子页面时特别方便。

2.2 app.json 和页面配置：小程序的"路由表"藏在这里

在 Vue 里，路由是靠 vue-router 配置的，页面和 URL 的对应关系由路由表维护。小程序没有独立的路由库，路由配置被做进了 app.json 的 pages 字段。这个字段有个非常"霸道"的规矩：所有页面必须先在这里注册，否则编译报错、跳转也找不到目标页面。

一开始我挺不习惯这个设计，因为 Vue 项目里的路由文件是单独管理的，页面文件放在 views 目录下，两者是解耦的。小程序则强制你把页面注册列表和页面文件组织强绑定在一起，pages 数组里第一个元素就是你小程序的首页。这种设计确实更"死板"，但也带来一个好处：只要打开 app.json，整份小程序的页面地图一目了然，团队协作时不会出现"这个页面存在但没人知道它能跳转到哪里"的情况。

除了 pages，app.json 里还藏着 window 配置（全局导航栏样式）、tabBar 配置（底部标签栏）、networkTimeout（网络超时）等。用 Vue 写习惯了以后，这些散落在全局配置里的东西一开始会让我觉得"怎么框架替我做好的事，现在都要自己点开关"。但反过来想想，Vue 项目做导航栏样式还得自己撸组件，小程序一句配置就能改，这其实是原生开发里"平台帮你准备好基础能力"的典型体现。

3. 模板语法对比：这层皮看似像，里面的规矩完全不同

3.1 插值和属性绑定：{{ }} 的能力边界

Vue 的模板插值用双大括号 {{ }}，小程序的数据绑定也用 {{ }}。单看这个，几乎所有人都觉得"这不就是同一套吗"。但实际上 {{ }} 在两边的能力边界差别很大。

在 Vue 里，{{ }} 里可以写比较复杂的表达式，比如 {{ user.name.split(' ')[0] }}、{{ list.filter(x => x.visible).length }}，甚至可以调用组件方法（尽管不太推荐）。因为 Vue 模板会被编译成 render 函数，这些表达式本质上就是 JavaScript 表达式。小程序不一样，WXML 里的 {{ }} 只支持简单的运算：加减乘除、取模、字符串拼接、三元表达式、简单的数组字面量，但你不能在里面调用方法，也不能写复杂逻辑。

这个限制让我踩过好几个跟头。典型场景是格式化日期：Vue 里我习惯直接写 {{ formatDate(item.time) }}，但在小程序里这么写，结果就是空白，因为 WXML 不认方法调用。解决办法要么是在 JS 里先遍历数据处理好再 setData，要么用 WXS（WeiXin Script）写一小段能在模板里调用的函数。WXS 是可以用的，但初学阶段我建议先在 JS 里处理好数据，少在模板里堆逻辑——这样代码更清晰，也更容易调试。

3.2 条件渲染：wx:if 和 v-if 的对应与差异

条件渲染这块，Vue 是 v-if / v-else-if / v-else，小程序是 wx:if / wx:elif / wx:else。对应关系非常直白，几乎可以一对一翻译。

但有几个细节需要注意。Vue 的 v-if 和 v-show 是两个不同的东西：v-if 是真正的条件渲染，为 false 时元素不会出现在 DOM 里；v-show 则是用 display: none 隐藏元素，元素始终存在。小程序对应的是 wx:if 和 hidden 属性：wx:if 是真正的条件渲染，hidden 则是加类似 display: none 的效果。

这里有一个容易翻车的点：hidden 在某些情况下是不生效的。具体来说，如果元素自身样式里显式写了 display: flex 或 display: block，那 hidden 属性加不加都没用，因为 HTML 的 hidden 属性本质上只是建议用户代理隐藏元素，具体样式优先级盖过它就会失效。我第一次用 hidden 控制一个自定义组件显示隐藏，半天没反应，后来才发现组件根节点样式里写了 display: flex，把 hidden 给顶掉了。这个坑在 Vue 的 v-show 里不太容易遇到，因为 v-show 是通过内联样式设置 display 的，优先级够高。所以在小程序里，如果发现 hidden 不生效，去检查目标元素的样式，十有八九是 display 冲突。

3.3 列表渲染：wx:for 的坑集中营

列表渲染是另一个看起来像、用起来全是细节的环节。Vue 写 v-for="(item, index) in list" 很自然，小程序写 wx:for="{{list}}"，默认的循环项变量名也叫 item，默认的索引变量名也叫 index。

但小程序这里有一个让 Vue 开发者极其容易触电的设定：如果你在模板里引用了外部 data 里的字段名 index 或者 item，就会和循环变量冲突。尤其是当你嵌套两层 wx:for 的时候，内层循环会把外层的 item 和 index 覆盖掉。Vue 里你可以在 v-for 的括号里重新命名，比如外层用 (outer, outerIndex)，内层用 (inner, innerIndex)；小程序则要通过 wx:for-item 和 wx:for-index 显式指定别名：

<view wx:for="{{userList}}" wx:for-item="user" wx:for-index="uIndex"> <view wx:for="{{user.tags}}" wx:for-item="tag" wx:for-index="tIndex"> {{ user.name }} - {{ tag }} - {{ uIndex }} - {{ tIndex }} </view> </view>

还有一个很关键的 wx:key。在 Vue 里，v-for 配合 :key 用于 diff 优化，不写 key 顶多收到一个警告。但小程序里的 wx:key 不只是性能优化，它还影响列表项的状态维护。如果你在循环里用了某些需要记录位置的组件（比如 input），没有 wx:key，做列表排序、删除、插入时可能出现状态错乱。wx:key 的写法有个细节：如果用来做 key 的字段是 item 里的某个属性，直接写 wx:key="id" 就行，不需要加 {{ }}；如果循环项本身就是基本类型，要写 wx:key="*this"。

3.4 模板里不能随便调用方法

综合上面几点，我总结出一个对 Vue 开发者来说最重要的思维转变：小程序的模板更像一个"展示层"，而 Vue 的模板更像一个"轻逻辑层"。Vue 的模板里可以放三元、方法调用、过滤器（Vue 2 时代），甚至一些简单的计算逻辑；小程序模板则被刻意限制成只能展示和做最基础的运算。

这种限制一开始让我觉得是"倒退"，但项目写深了之后，我发现它其实能逼着你把数据处理好再交给模板，反而让页面逻辑更清晰——所有需要计算的值，在 JS 里算好了用 setData 喂给模板，模板里只需要负责"显示"这一件事。这跟 "Template 里不放逻辑" 的最佳实践是一致的，只不过 Vue 给了你自由，小程序强制你这么做。

4. 数据驱动：Vue 的自动响应 vs 小程序的 setData

4.1 为什么小程序不能直接 this.data.xxx = xxx

这是我从 Vue 转过来之后撞得最疼的一堵墙。在 Vue 里：

this.message = 'hello'

页面就自动更新了。在小程序里，页面数据挂在 this.data 上，你以为：

this.data.message = 'hello'

也能更新？实际上页面一点反应都没有。

原因在于 Vue 的数据响应式是靠 Proxy 或 Object.defineProperty 劫持属性读写，赋值操作能被监听，然后触发重新渲染。而小程序的 data 只是一个普通对象，你在 JS 里给它赋值，只是改了内存里的数据，渲染层根本不知道。要让视图更新，必须调用 this.setData()：

this.setData({ message: 'hello' })

setData 做的事情是：把数据从逻辑层送到渲染层，让渲染层重新执行 WXML 的绑定计算。这个通信过程是跨线程的、异步的，也是小程序性能和渲染模型的根基。

这个差异不是"API 叫法不同"这么简单，它代表的是两种完全不同的数据流模型。Vue 是"响应式系统自动追踪变化"，小程序是"显式地声明你要更新什么"。初学阶段我觉得 setData 麻烦，但现在反而觉得它很诚实：你每次改动数据，都明确知道这是一次"可能要花钱"的操作，倒逼自己去思考这一下是不是值得发。

4.2 setData 是异步的：连续修改的隐藏陷阱

setData 的第二个让人头大的特性是异步性。举个我实际踩过的例子，做一个计数按钮，我一开始写的是：

handleAdd() { this.setData({ count: this.data.count + 1 }) this.setData({ count: this.data.count + 1 }) }

我天真地以为两次 setData 会把 count 加 2，结果页面显示只加了 1。因为第二次 setData 执行时，this.data.count 还是旧值，两次 setData 用的都是同一个旧值去加 1，最后 count 只增加了 1。

正确的姿势是：

handleAdd() { let count = this.data.count + 1 this.setData({ count }) }

或者在 setData 的完整回调里拿最新的数据再赋值：

this.setData({ count: this.data.count + 1 }, () => { this.setData({ count: this.data.count + 1 }) })

但注意，上面的写法也不推荐，因为两次 setData 是两次跨线程通信，性能差。最好是在 JS 里先完成所有计算，只 setData 一次。这个思维方式与 Vue 差异很大，Vue 里你根本不需要关心"这次赋值什么时候生效"，因为响应式系统会帮你处理所有依赖。

4.3 计算属性没有，但有 observers

Vue 的 computed 是我特别依赖的一个能力：某个值依赖其他响应式数据自动推导，还带缓存。小程序原生没有计算属性这个概念，初次上手时我经常觉得"少了一条腿"。

替代方案有两种。第一种最简单，在数据变更的地方手动算好，setData 出去。第二种是用 Page 构造器里的 observers 字段，它类似于 Vue 的 watch，可以监听指定数据字段的变化并执行回调：

Page({ data: { price: 100, count: 1, total: 100 }, observers: { 'price, count': function(price, count) { this.setData({ total: price * count }) } } })

observers 支持监听单个字段、多个字段、以及字段路径（比如 'user.name'）。但它和 computed 有一个本质区别：computed 是"派生值"，你不需要手动去更新它；observers 仍然需要你手动 setData 才能把结果写回 data。所以它本质上是个自动化的事件回调，不是响应式派生。初学阶段建议：能手动算的就手动算，别依赖 observers 写得过于花哨，不然数据流会变得很绕。

4.4 字段路径更新：setData 的精细打法

setData 有一个很实用的特性：支持字段路径更新。也就是说，你不必把整个对象搬出来改完再塞回去，直接告诉它要更新哪个子字段就行：

this.setData({ 'user.name': '张三', 'list[0].title': '第一项' })

这个写法在调整深层嵌套数据时特别有用，它可以减少传递的数据量，也能避免因为不小心覆盖了同层其他字段而造成的 bug。在 Vue 里，这种操作往往需要展开运算符或者 Vue.set，小程序原生的字段路径语法用起来意外地趁手。

不过这里有另一个建议：小程序页面数据尽量不要嵌套太深。因为 setData 更新深层字段虽然方便，但 getter 阶段 if 层数太多，代码阅读体验会很差。我自己踩过这个坑，一开始喜欢把所有状态都塞在一个大对象里，后面改一个字段都要小心翼翼算路径，后来干脆把数据拍平、按功能拆分，清爽多了。

5. 事件与交互：bindtap 和 @click，不只是名字不同

5.1 事件绑定的基础写法

Vue 的事件绑定是 @click="handleClick"，小程序是 bindtap="handleTap"。一眼看过去，就是"事件名加前缀"的区别。但真正写起来，你会发现小程序的事件绑定有太多约定俗成的细节。

首先，小程序里 bindtap 后面的值是一个字符串，这是方法名，不是调用表达式。你写成 bindtap="handleTap()" 是不行的，它在运行时会报"xxx is not a function"。Vue 里你可以写 @click="handleClick()" 也可以写 @click="handleClick"，两种都合法。小程序只认方法名，传参必须走><button>handleTap(e) { const id = e.currentTarget.dataset.id }

dataset 里的值，如果 WXML 里绑定的是 {{ }} 数字，拿到手的可能是字符串 "12" 而不是数字 12，这个坑很隐蔽。避免方法是在绑定的时候用 Number() 包装一下，或者在使用时再做一次类型转换。

5.2 传参方式：从"直接传"到"data-* 数据集"

Vue 里传参太自然了，@click="deleteById(item.id)" 直接写参数进去就行。小程序里没法这么干，因为 WXML 编译后的事件绑定只是一个字符串映射。上面说了要用><button>this.triggerEvent('eventname', payload)

父组件在 WXML 里监听：

<custom-component bind:eventname="onChildEvent" />

注意事件名称不要用驼峰。triggerEvent('myEvent') 在父组件绑定的时候要写 bind:myevent 才能对上，因为小程序事件名在传递过程中也有大小写被转小写的问题。这个坑我踩过一次之后，就给自己定了规矩：自定义事件全部用 kebab-case 或者全小写。

triggerEvent 还有两个可选参数，配置事件的冒泡和穿透。默认情况下自定义事件只在组件内部冒泡，不会跑出组件边界。如果你希望它跨组件传播，可以传第三个参数：

this.triggerEvent('eventname', payload, { bubbles: true, composed: true })

Vue 里没这个概念，因为 DOM 事件天然具有穿透组件的能力。小程序里自定义事件更像是一个被隔离的通道，你需要显式授权它才能往外走，这也是平台设计上有意为之的隔离策略。

6. 生命周期：onLoad、onShow 都不等于 mounted

6.1 页面生命周期逐项对号入座

Vue 组件有一长串生命周期：created、mounted、updated、destroyed 等等。小程序页面也有自己的一套：onLoad、onShow、onReady、onHide、onUnload。

把它们跟 Vue 对照起来，我的理解是：

最容易出错的地方是分不清 onLoad 和 onShow 的使用场景。Vue 里 mounted 只在挂载时触发一次；小程序里 onShow 每次显示都会触发。如果你在 onShow 里做了数据初始化，每次从后台切回来、从子页面返回，都会重新执行一遍，这可能是你想要的（每次进页面刷新数据），也可能是一个性能隐患（频繁重新请求接口）。

我的经验是：一次性初始化的逻辑放 onLoad，每次进入页面都需要刷新的逻辑放 onShow。比如某个列表页，onLoad 里只初始化页面配置，onShow 里再请求最新的列表数据。这样既能保证数据新鲜，又不会在页面栈意外留存时重复初始化。另外，页面初次加载时，onLoad 和 onShow 都会触发一次，所以你放在 onShow 里的请求会在首帧后被调用，如果接口慢了会有一段空白，需要配合 loading 状态处理。

6.2 组件生命周期与 created 的区别

小程序自定义组件有自己的生命周期，用 Component 构造器定义，核心是 created、attached、ready、detached。其中 created 在小程序组件实例被创建时触发，但它发生在什么阶段呢？是在组件对应的 WXML 节点被创建时，而不是在页面里渲染出来时。

对比 Vue：Vue 组件的 created 触发时，组件实例的 data、methods 已经准备好了，但 DOM 还没挂载。小程序组件的 attached 触发时，组件实例已经绑定到页面节点树上了，这个时候可以拿到子组件实例，也可以安全地做初始化。ready 则类似于 mounted，表示组件布局渲染完成。

初学阶段最容易犯的错是把放在页面 onLoad 里的逻辑，原封不动搬到组件 created 里用。比如在 created 里读取页面跳转参数，但参数其实要等组件载入路径时才知道。组件里要拿参数，应该从 properties 里拿，而不是在 created 里瞎试。如果组件需要根据某个外部状态初始化内部数据，用 observers 监听 properties 的变化再处理，比在 created 里一次性初始化可靠得多。

6.3 页面栈：小程序的"前进后退"和 Vue Router 不一样

Vue Router 管理的是浏览器的历史记录，你可以随便 push 一个新路由，也可以 replace 当前路由。小程序则维护一个页面栈，常见操作是 wx.navigateTo 往栈里压一个页面，wx.navigateBack 弹出一个页面。还有一个独特的 wx.redirectTo，它会把当前页面从栈里移除，替换成新页面，相当于 Vue 里的 replace。

理解这个栈模型后，很多页面生命周期行为才说得通。比如 A 页面 navigateTo 到 B 页面，A 页面并不会被销毁，而是触发 onHide；B 页面 navigateBack 回 A 页面，A 页面会触发 onShow 而不是重新 onLoad。这就意味着你从 B 页面返回后，A 页面的数据不会自动刷新，除非你在 onShow 里做了处理。Vue 里从 B 路由返回 A 路由，A 组件通常不会重新 mounted，所以数据也不会刷新，这一点两者倒是相似；但 Vue 里你可以通过路由元信息、watch 路由变化等方式感知路由跳转，小程序里没有这么优雅的机制，基本靠 onShow 手动处理。

7. 组件化：properties、usingComponents 和样式隔离

7.1 注册方式：import 变成了 json 引用

Vue 里注册一个子组件，三步走：import 组件文件，在 components 里注册，然后在模板里用。小程序也三步，但注册动作被放在了 JSON 配置文件里：

{ "usingComponents": { "custom-button": "/components/custom-button/index" } }

路径可以用绝对路径（以 / 开头），也可以用相对路径。usingComponents 配置一次，当前页面或组件里就能直接使用。这种"注册信息写在 JSON"的做法，刚开始我觉得很别扭，但后来发现它有个好处：组件依赖关系在编译时可以静态分析，不会出现 Vue 项目里那种"某个组件没有被任何地方 import 但还在项目里躺着"的情况。

小程序没有全局自动注册组件的机制（app.json 里的 usingComponents 也不能全局生效），每个页面需要用到哪些组件，都明明白白写在页面 JSON 里。这种做法重复劳动是有的，但依赖关系也变得非常可预测。

7.2 props 与 properties：类型定义是硬要求

Vue 的 props 可以只写一个数组，也可以写带类型校验和默认值的对象。小程序里 properties 也有类似能力，但形式上更接近"配置项"，而且类型声明几乎算是硬性要求：

Component({ properties: { title: { type: String, value: '默认标题' }, count: { type: Number, value: 0 }, list: { type: Array, value: [] } } })

有个细节我要特别强调：properties 里的 value，如果是数组或者对象，不能直接写 value: [] 或 value: {}，因为引用类型在组件多个实例间可能共享，导致一个实例改了数据另一个实例也变。正确写法是 value: () => [] 或 value: () => ({})。这个坑和 Vue 里 props 默认值用工厂函数返回是同一个道理，但在小程序里因为示例代码多，更容易让人掉以轻心。

还有一个让 Vue 开发者困惑的点：小程序组件内部可以通过 this.data 访问 properties 的值。你可以在 data 里定义内部状态，也可以在 properties 里接收外部传参，但两者统一挂在 this.data 上。如果你组件内部状态和外部传入的 property 起了同一个名字，会发生覆盖，而且不会有明显的报错。所以命名时最好约定一套前缀，比如外部输入统一用 x- 开头，内部状态用 _ 开头，避免撞名。

7.3 样式隔离：scoped 思维会在这里栽跟头

Vue 的 scoped 样式可以让组件的 CSS 只作用于当前组件，小程序的自定义组件默认也有类似的样式隔离效果：页面样式不能影响组件内部，组件样式也不能影响页面。但隔离的规则和 Vue 不完全一样，而且在某些全局样式的处理上很容易栽跟头。

举个例子，你给页面里的一个 class 写了字体颜色，这个 class 在自定义组件内部的节点上也存在，但页面样式不会生效。反过来，你在 app.wxss 里定义了全局样式，这些全局样式默认也影响不到自定义组件内部（除了 text、button 这类原生组件的默认样式）。

如果你希望某个自定义组件能继承全局样式或页面传递的样式类，有几种办法：设置组件的 styleIsolation 为 apply-shared 或 shared（apply-shared 表示页面样式可以影响组件内部，shared 表示双向影响）；或者使用 externalClasses ，它类似 Vue 的"CSS 变量穿透"，允许外部传入自定义类名来影响组件内部的某些节点。

我实际开发中遇到的最典型场景是：公司内部封装了一套通用按钮组件，全局 app.wxss 里定义了按钮的基础样式类 btn-base，结果组件内部用 class 引用这个类，死活不生效。排查了半天，发现就是样式隔离在作祟。解决办法是把组件样式文件里需要跟随全局的部分，复制一份到组件自己的 wxss 里，或者干脆用 externalClasses 把 btn-base 当做一个外部类传进来。总之，要记住：隔离是默认的，你想破例必须自己明示。

8. 从 Vue 转小程序，最容易翻车的几个实操细节

如果说前面几章是"体系层面"的对比，那这一章写的就是我实际敲代码时频繁踩到的、特别琐碎但特别伤效率的细节。每一个背后都有一段"对着页面怀疑人生"的经历。

8.1 直接赋值导致"数据改了，页面不动"

这是最常见的翻车点，我在前面也反复提到过。最坑的是它不报错：你在控制台打印 this.data，明明值变了，页面就是不刷新。原因一句话就能解释清楚——setData 才是逻辑层到渲染层的数据通道。可恨的是，初学阶段你会反复地栽在这个坑里，因为写着写着就下意识地按 Vue 的写法直接 this.data.xxx = xxx 了。

我后来给自己定了个检查方法：每次写完数据更新逻辑，先搜一下代码里有没有 this.data.xxx = 这种赋值语句。有就全部改掉，只留 setData 和相关计算。这个习惯帮我省了不少调试时间。

8.2 方法名和 data 里的字段撞名

在 Vue 里，methods 里的方法名和 data 里的字段名是可以同名的（虽然也不建议），但在小程序里，事件绑定是方法名字符串，Page 构造器会把 data 里的字段和 methods 里的方法都挂载到 this 上。如果你在 WXML 里 bindtap="handleTap"，但 data 里又有个 handleTap 字段，这个字段会覆盖同名方法，导致点击时找不到函数报错。

这个报错还特别不明显，它只会在你点击的时候出现，而且提示信息经常是"handleTap is not a function"或者直接没有响应。排查的时候一不小心就会往别的方向查半天。所以我的惯例是，方法名统一用动词开头（handle、fetch、toggle），数据字段统一用名词，从命名规则上就杜绝撞名。

8.3 wx:key 不是可选项

Vue 里 v-for 不写 :key 顶多警告，项目还是能跑的；小程序里 wx:key 不写，控制台也会有个警告，但真正出问题的是列表项内部状态会错乱。比如你的列表项里有一个输入框或开关，当你操作列表排序、删除某一项、或者在头部插入新项时，没有 wx:key 的列表项可能被"复用"，导致输入框里还留着旧值。

这个现象背后的原理是渲染层的"节点复用"，和 Vue 的 diff key 机制类似。解决方式非常简单：给 wx:for 永远加上 wx:key。如果循环项没有唯一 id，而且本身就是字符串或数字，就写 wx:key="*this"。别再偷懒了，这个习惯从第一个 wx:for 就开始养成。

8.4 连续 setData 时拿到的永远是旧值

前面已经举过计数器的例子，这里再补充一个场景：如果你要在一个方法里用上一个 setData 的结果做下一步判断，这个判断永远发生在旧数据上。比如：

handleSubmit() { this.setData({ submitting: true }) if (this.data.submitting) { // 这里的 this.data.submitting 还是旧值 false！ } }

这是一类典型的"以为 setData 是同步的"思维误区。要想拿到更新后的值，放在 setData 的回调里处理：

this.setData({ submitting: true }, () => { // 这里才能拿到 true })

但回调的方式也容易嵌套过深，我的经验是：如果逻辑不依赖渲染结果，就直接在本地变量上算好；如果必须依赖"这次值已经更新到渲染层了"，用回调。无论如何，尽量把 setData 拆成"计算 + 提交"两步，而不是在 setData 前后穿插业务逻辑。

8.5 事件绑定写错时，控制台给你的提示很委婉

Vue 里你把一个不存在的方法写到 @click 里，运行时会报一个比较明确的警告。小程序里 bindtap="noSuchMethod" 时，开发者工具控制台有时只会在你点击的时候弹一行"Component error: noSuchMethod is not a function"，而且行号指向模板或数据文件，有时甚至不报错，只有交互没反应。

这种"静默失败"是 Vue 转小程序的人最头疼的，因为你习惯了框架会帮你把错误明明白白抛出来。小程序原生对这类错误的容错性确实比较差。我的建议是：事件绑定写完后立刻点击测一遍，不要攒到统一测试。另外，可以打开开发者工具的"关于调试"里的"打开调试"开关，它会暴露更多运行时错误详情，比默认的控制台信息要丰富不少。

两个生态的差异，说到底不是"谁比谁先进"，而是"设计哲学不同"。Vue 像一个贴心的管家，能帮你把很多事体面地处理掉；小程序原生像一套边界清晰的手动工具，每一样操作都需要你明确授权、明确声明。初学阶段你会觉得处处受制，但深入了解后反而会觉得这套约束让数据流和组件边界更清晰。拿我自己来说，写了一个多月小程序原生之后，再回去写 Vue，居然对"为什么这里会自动更新""为什么这里数据流不用手动管理"有了更深的理解。

最后分享一个小技巧：如果你决定从 Vue 转过来，不要急着把 Vue 的组件库、状态管理、工具函数往小程序里搬，先按小程序的"原生习惯"写一个完整功能，哪怕它看起来笨拙。这样过一遍之后，你才能真正分清哪些是平台能力，哪些是框架思路，下次再去做技术选型的时候，心里才有一本明白账。