企业官网建设流程全解析

简介：支付宝小程序示例项目，面向刚接触小程序开发的初学者，也适合需要快速接入地图与扫码能力的开发者。压缩包内共 400 个文件，约 394KB，核心代码以 js（逻辑）、axml（页面结构）、acss（样式）、json（配置）为主，并包含 sample、png 等辅助资源；目录中可见 pages、utils、model、components 等模块划分，便于按功能定位代码。该项目完整演示了地图定位与展示、二维码/条形码扫码识别、用户授权后获取头像昵称手机号等个人资料，以及常用内置组件的组合调用；同时涵盖从项目创建、预览调试、性能优化到提交审核上线的典型开发链路。已有 1833 人浏览学习，开发者可参照 demo 中的文件组织方式与 API 用法，快速搭建自己的支付宝小程序基础框架，并在实际场景中复用地图、扫码与用户信息处理等模块。

1. 支付宝小程序demo，从零到上线需要准备什么

做支付宝小程序开发，很多人第一反应是找一套现成的demo代码，跑通之后往里面塞自己的业务逻辑。这个思路本身没错，但我见过太多人卡在第一步：demo下载下来跑不起来，环境配不明白，甚至连支付宝小程序和微信小程序的差异都搞不清楚。这篇文章我用自己的实操经验，带你把一个支付宝小程序demo从搭建到上线这件事彻底跑通。

先说结论：支付宝小程序的开发体验和微信小程序非常接近，都是基于类似的前端技术栈，但你如果直接把微信小程序的代码拿过来改个后缀就扔进支付宝开发者工具里，大概率会报一堆错。api前缀不同、组件属性有差异、样式兼容性也有坑，这些细节我会在后面展开讲。

这篇内容适合三类人：刚接触小程序开发、想快速上手支付宝生态的新手；从微信小程序转过来的老手，需要快速对齐差异；以及想做一个完整demo去验证业务可行性或拿去面试的作品集选手。无论你属于哪一类，看完这篇你都能独立跑起来一个能看、能点、能调接口的支付宝小程序demo。

在正式开始之前，先聊聊我个人的一个习惯：做demo不追求大而全，追求的是把核心链路走通。一个商品列表页、一个详情页、一个带表单提交的页面、加上必要的交互反馈，这四样东西足以覆盖绝大多数小程序的基础能力。后面的内容就围绕这个思路来展开。

2. 动手之前，先把支付宝小程序的"地基"搞清楚

2.1 开发工具与账号准备：没有appid也能先跑起来

支付宝小程序开发的第一步是下载开发者工具，直接在支付宝开放平台官网找到"小程序"栏目下的开发者工具下载入口，支持Windows和macOS两个版本。安装过程没什么特殊之处，但第一次打开工具的时候有几点要注意：

- 登录方式支持支付宝扫码和账号密码两种，建议直接用支付宝扫码，省去密码登录的麻烦。

- 新建项目时需要用企业支付宝账号或者个人支付宝账号登录开发者平台，创建一个小程序应用，拿到appid。不过如果你只是本地跑demo，不接后端接口，工具里有个"不使用云服务"和"测试号"的选项，可以先不填appid，用测试模式直接创建项目。这一点对新手特别友好，我在本地开发时就经常这么干。

项目创建完成后，你会看到工具生成了标准的目录结构：app.js、app.json、app.acss这三个文件位于根目录，pages目录下面放页面文件，每个页面由四个文件组成——.js逻辑文件、.axml模板文件、.acss样式文件、.json配置文件。注意这里和微信小程序的区别：微信小程序的模板文件是.wxml，样式文件是.wxss，支付宝小程序分别对应.axml和.acss，配置文件的格式也有细微差别。

2.2 目录结构与配置文件的正确打开方式

app.json是整个小程序的全局配置中心，pages数组里注册了所有页面路径，window对象配置了全局窗口表现。我建议你把demo项目的页面控制在5个以内，这既是控制复杂度的策略，也是让新手不被大量文件淹没的有效手段。

一个典型的app.json长这样：

{ "pages": [ "pages/index/index", "pages/list/list", "pages/detail/detail", "pages/mine/mine" ], "window": { "defaultTitle": "我的Demo小程序", "titleBarColor": "#1677ff", "pullRefresh": false } }

注意"defaultTitle"这个字段，支付宝小程序的导航栏标题用的是它，不是微信小程序的"navigationBarTitleText"。这种差异点我会在后面的章节持续强调，因为它们是换平台开发时最容易踩的坑。

app.js里主要做全局逻辑初始化，比如获取用户信息、设置全局数据。这里我建议新手不要一上来就搞复杂的登录态逻辑，先在app.js里留一个globalData的空对象，渲染页面时把需要共享的数据塞进去就行。

3. 核心页面开发：从列表到详情，把demo的主干搭起来

3.1 首页设计：用scroll-view实现滚动列表

首页是一个小程序的门面，我建议demo的首页做成双栏Tab结构：顶部tab切换分类，下方滚动列表展示商品卡片。这个设计不算复杂，但能覆盖组件嵌套、事件绑定、数据渲染这三个核心知识点。

首页的页面结构建议用scroll-view组件来做滚动区域，而不是Page自带的滚动。为什么？因为scroll-view可以绑定了滚动事件、实现下拉刷新和触底加载，这些是列表页的刚需。我的实现思路是这样：

在index.axml中：

<scroll-view class="list-scroll" scroll-y lower-threshold="200" onScrollToLower="loadMore"> <view class="goods-card" a:for="{{goodsList}}" a:key="id"> <image src="{{item.image}}" class="goods-img" mode="aspectFill" /> <view class="goods-info"> <text class="goods-title">{{item.title}}</text> <text class="goods-price">¥{{item.price}}</text> <button size="mini" onTap="addCart">Page({ data: { goodsList: [], page: 1, hasMore: true }, onLoad() { this.loadGoods() }, loadGoods() { // 模拟接口请求 const list = [ { id: 1, title: '商品一', price: '99.00', image: '/assets/goods1.png' }, { id: 2, title: '商品二', price: '129.00', image: '/assets/goods2.png' } ] this.setData({ goodsList: this.data.goodsList.concat(list), page: this.data.page + 1 }) }, loadMore() { if (this.data.hasMore) { this.loadGoods() } }, addCart(e) { const id = e.currentTarget.dataset.id my.showToast({ content: `已加入购物车：商品${id}` }) } })

这里有一个需要注意的点：setData不要一次性传大对象，影响性能；data中只放置页面渲染需要的数据，不需要的不要往里面放。

3.2 表单交互：input、picker和动态数据绑定的组合拳

一个demo如果只有列表和详情，交互感太弱，评审官或者面试官看了会觉得你没有完整地处理用户输入。所以我建议加一个"反馈页面"，用input、textarea、picker、switch这几个组件组合出一个信息收集表单。

这个页面的核心交互点在于表单数据的动态获取和校验。支付宝小程序的input组件获取值的方式和微信不同，微信用bindinput配合e.detail.value，支付宝还是onInput配合e.detail.value，本质上一样，但属性名不同，用onChange也能拿到。

实操示例，表单页面的关键代码：

<view class="form-item"> <text class="label">商品名称</text> <input value="{{form.name}}" onInput="handleNameInput" placeholder="请输入商品名称" /> </view> <view class="form-item"> <text class="label">商品分类</text> <picker range="{{categories}}" onChange="handleCategoryChange"> <view class="picker-value">{{categories[currentIndex] || '请选择分类'}}</view> </picker> </view>

对应的js逻辑：

Page({ data: { categories: ['数码', '家居', '服饰'], currentIndex: 0, form: { name: '', category: '' } }, handleNameInput(e) { this.setData({ 'form.name': e.detail.value }) }, handleCategoryChange(e) { const index = Number(e.detail.value) this.setData({ currentIndex: index, 'form.category': this.data.categories[index] }) }, submitForm() { if (!this.data.form.name) { my.showToast({ content: '请填写商品名称', type: 'none' }) return } // 模拟提交 my.showLoading({ content: '提交中' }) setTimeout(() => { my.hideLoading() my.alert({ title: '提交成功', content: '你的反馈已收到' }) }, 1000) } })

这里我特意用了my.showToast、my.showLoading、my.alert这些API，它们是支付宝小程序的全局反馈组件，和微信的wx.showToast对应，但参数略有差异。比如my.showToast的content字段对应微信的title，type字段的可选值有success、fail、none，而微信只有success、none、loading。

3.3 四级联动选择器：demo里的一个高难度亮点

如果你想让demo在众多作品里脱颖而出，我强烈推荐做一个"省市区街道四级联动"的选择器。这个需求在实际商业项目中非常常见，但很多做了几年的前端都不一定写得利索。热词里刚好有"支付宝小程序四级联动"，说明大家对这个需求关注度很高，你把它做进demo里，是个很好的加分项。

实现思路是：用四个picker组件联动，或者用pick-view做自定义弹层。我的经验是，如果只是demo展示，用四个picker串行联动比较简单；如果你想展示实力，可以用pick-view做一次自绘弹层，每个picker-view-column对应一级数据，切换时根据上一级的值动态更新下一级数据。

示例结构是这样的：

<picker-view class="picker-area" onChange="handleAreaChange"> <picker-view-column> <view a:for="{{provinceList}}" a:key="*this">{{item.name}}</view> </picker-view-column> <picker-view-column> <view a:for="{{cityList}}" a:key="*this">{{item.name}}</view> </picker-view-column> <picker-view-column> <view a:for="{{districtList}}" a:key="*this">{{item.name}}</view> </picker-view-column> <picker-view-column> <view a:for="{{streetList}}" a:key="*this">{{item.name}}</view> </picker-view-column> </picker-view>

核心的数据联动逻辑：

handleAreaChange(e) { const values = e.detail.value // values是一个数组，分别对应四级选中的index const provinceIndex = values[0] const cityIndex = values[1] const districtIndex = values[2] const streetIndex = values[3] // 根据省index更新城市列表 if (provinceIndex !== this.data.currentProvinceIndex) { this.setData({ cityList: this.getCityList(provinceIndex) }) } // 同理更新区、街道列表 }

这里面需要注意两个坑：第一个是picker-view的onChange事件在滚动停止时触发，如果你需要实时响应，要配合onPickStart和onPickEnd使用；第二个是数据更新时要做好防抖，否则快速滚动时setData的频率太高，容易造成卡顿。

4. 联调与运行：把demo从开发工具搬到真机上的完整路径

4.1 本地调试三板斧：模拟数据、真机预览、远程调试

开发工具左侧的"调试器"面板可以查看console日志、network请求和AppData数据，这三个面板是你本地调试的主要阵地。我习惯在Page的onLoad阶段先打一条日志，确认页面生命周期正常，然后用模拟数据跑通渲染，最后再替换成真实接口。

真机预览是支付宝小程序开发中绕不开的一步，点击工具栏上的"真机预览"按钮会生成一个二维码，用支付宝扫码即可在手机上打开小程序。注意：预览模式使用的是开发环境，接口请求默认走的是你本机配置的域名白名单，如果后端接口还没上线，可以在开发者工具中勾选"忽略httpRequest域名合法性检查"，但这个只适用于开发调试，上线前必须换成合法域名。

远程调试适合排查真机上才出现的问题，点击"远程调试"后会拉起一个调试页面，可以查看真机上的console和Network。这一步对于元素样式兼容性排查非常有用，尤其是iOS和Android上的表现差异，在模拟器里看不出来，必须真机验证。

4.2 uniapp项目运行支付宝小程序失败的排查思路

热词里有一条是"uniapp项目运行支付宝小程序失败"，这个我在实际开发中遇到过很多次。uniapp写一套代码可以通过编译分别在微信、支付宝、百度等平台运行，但踩坑率并不低。最常见的失败原因有三类：

第一类是条件编译代码问题。uniapp在多端编译时，如果代码里混入了微信小程序的api，编译到支付宝端就会报错。排查方法是在代码里搜索wx.开头的全局api，这些都要改成uni.或者用条件编译注释包裹。

第二类是项目配置问题。manifest.json里的mp-alipay配置项缺失或错误，会导致编译产物不对。检查一下小程序appid是否配置、支付宝平台的配置项是否开启。

第三类是依赖包问题。有些npm包在支付宝小程序环境下不支持，比如依赖window对象的库，会导致运行时报错。这类问题需要检查依赖的技术栈兼容性，必要时用小程序的api替代实现。

我的建议是：uniapp能帮你省多端代码，但别把跨端想得太美好。如果是纯支付宝小程序，我反而建议直接原生写，少一层编译少一堆问题；如果确实是多端需求，再用uniapp，但一定要提前跑通支付宝端的编译和运行流程。

4.3 demo接入真实后端：从mock到真实api的切换

一个demo如果只停留在本地模拟数据，说服力不够。我的建议是：如果你有后端能力，用Node.js或者Python写一个简单的接口服务挂到测试环境；如果没有，可以用云开发或者mock平台。

支付宝小程序请求接口用的是my.request，注意和微信的wx.request在参数上有个细节差异：微信用header字段，支付宝也是header；但支付宝小程序默认的content-type是application/json，微信默认是application/x-www-form-urlencoded，两个平台的默认值不一样，跨端联调时容易出问题。

my.request({ url: 'https://your-api.example.com/goods', method: 'GET', data: { page: 1, size: 10 }, header: { 'Content-Type': 'application/json' }, success: (res) => { console.log('请求成功', res.data) this.setData({ goodsList: res.data.list }) }, fail: (err) => { console.error('请求失败', err) my.showToast({ content: '加载失败，请检查网络', type: 'none' }) } })

特别注意：开发调试时如果接口是http协议（非https），必须在开发者工具中勾选"不校验合法域名"选项，否则请求会被拦截。真机预览时，这个选项不生效，必须用https接口，而且域名需要在小程序后台配置到白名单列表。

5. 常见问题速查：我把demo开发中踩过的坑全整理出来了

5.1 高频坑位表格：一看就懂的对照表

5.2 单独说说"input只读"这个需求

热词里有"支付宝小程序 input 只读"，这个需求看起来简单，但实现方式有好几种，选错了会影响体验。

第一种是用readonly属性。支付宝小程序的input组件支持readonly属性，设置后输入框不可编辑但可以聚焦，样式上和正常输入框一样。这个方案适合表单预填信息但禁止修改的场景。

第二种是disabled属性。disabled会让输入框完全不可交互，包括聚焦、点击，样式上通常表现为灰色背景。这个方案适合展示场景。

第三种是用view覆盖。如果只是想展示一段不可编辑的文本，直接用view+text渲染即可，没必要用input。有些开发者习惯性地用input只读来做展示，这是多余的。

我的建议是：需要聚焦但不能改内容时用readonly，完全禁止交互时用disabled，纯展示时直接用view。这三个选择的边界要清晰，别混用。

5.3 一个特别容易被忽视的问题：页面栈与页面跳转

demo页面多了以后，页面跳转逻辑也要注意。支付宝小程序的页面栈上限是10层，如果你在列表页和详情页之间反复跳转，超过10层后跳转会失败。我建议在多层跳转场景中，用my.redirectTo替代my.navigateTo，前者会关闭当前页面，不会无限堆积页面栈。

另外，从一个tab页跳转到另一个tab页时，应该用my.switchTab，而不是my.navigateTo。这两个方法混用会导致tab栏切换异常，页面不渲染。这些都是真实的坑，我在第一次做demo的时候实实在在踩过。

6. 优化与提审：demo做完了，怎么让它更进一步

6.1 版本提审前的自检清单

demo开发完成后，如果要提交审核上架体验版，一定要做一轮自检。我整理了一个简单的清单：

- 所有接口切换到https，并且域名已配置白名单。

- 页面标题、按钮文案没有错别字，也没有敏感或违禁词。

- 授权弹窗要在用户主动触发时调用，不能一进入页面就弹。

- 没有把测试用的console.log大量留在生产环境代码里。

- 真机走一遍完整业务流程，确认没有crash和明显卡顿。

- 检查包体大小，主包不要超过2M，建议把图片放到CDN。

这些细节在审核阶段都有可能成为被驳回的理由，越早处理越省事。

6.2 后续扩展方向：把demo升级成完整项目

最后说说这个demo做完之后可以怎么扩展。如果你想拿这个demo去面试或者作为个人项目展示，我建议往这几个方向叠加能力：

第一，接入支付宝的授权登录，实现用户身份识别和个性化推荐。这个属于支付宝生态的核心能力，面试官会很感兴趣。第二，在上面的列表页基础上做搜索和筛选，用关键词过滤和分类联动，这能展示你对复杂列表场景的处理能力。第三，把四级联动升级成通用的地区选择组件，封装成自定义组件，展示你的组件化设计能力。第四，接一个真实的后端服务，用云函数或者Node服务实现商品数据的增删改查，让demo具备完整的业务闭环。

从我个人经验来看，一个能跑通的demo其实只完成了30%的工作，剩下70%是打磨细节和扩展能力。但你也不用焦虑，先把地基打好，一个能稳定运行的原生小程序demo，已经比大部分只写静态页面的人强很多了。

我在实际开发中一个很深的感受是：demo虽小，五脏俱全。把一个小项目里的每个环节都认真走通，比草草地做完十个大而全的项目收获更大。希望这篇内容对你有用，接下来就动手去敲代码吧。

本文还有配套的精品资源，点击获取