两端定位：交易心智与搜索心智

支付宝小程序和百度小程序，常常被放在一起讨论，因为它们是微信之外两个最有「工具属性」的生态。但两者的用户心智完全不同：打开支付宝的人，心里想的是「我要办一件事」——缴费、还款、查询、下单；打开百度的人，心里想的是「我要找一个答案」——搜索一个服务、一个功能、一个信息。

这个差别直接决定了产品设计方向。支付宝端要把交易链路做到最短：少一次跳转、少一个表单、少一步确认，转化率就会明显不同；百度端要把首屏信息与检索承接做好：用户从搜索词进来，页面必须立刻给出与词匹配的内容，否则会立刻离开。

在支付宝里卖「交易效率」，在百度里卖「信息匹配」。同一个功能，这两个生态里的最优解往往不是同一个页面。
本文核心知识点
  • 支付宝页面用 .axml / .acss 描述结构与样式，逻辑仍是 JavaScript。
  • 登录态客户端拿 authCode，后端换用户标识并签发自己的会话凭证。
  • 支付接入下单在后端创建交易，客户端用 tradePay 唤起收银台。
  • 百度 Swan页面结构与微信高度接近，擅长承接搜索与信息流入口。
支付宝与百度小程序开发示意：支付卡片、二维码方块、搜索放大镜与登录头像占位组成的蓝调扁平科技插画
一端重交易、一端重检索；把登录态与支付这两条主干打通，剩下的就是页面的精雕细琢。

支付宝小程序开发环境与项目结构

支付宝小程序同样提供了官方 IDE（小程序开发者工具），支持编码、真机预览、调试与上传。项目结构与微信高度相似，差别主要在文件后缀与配置项命名：

文件 / 目录作用与微信的差异
app.json全局配置：页面、窗口、tabBar字段名基本一致，个别窗口项命名不同
app.js全局逻辑生命周期钩子命名略有差异
pages/…/*.axml页面结构对应微信的 .wxml
pages/…/*.acss页面样式对应微信的 .wxss
pages/…/*.js页面逻辑注册用 Page，API 走 my
mini.project.json工具项目配置对应微信的 project.config.json

写页面的方式与微信几乎可以逐行对照，只是把标签换掉、把命名空间从 wx 换成 my，动态字段用双大括号绑定：

<view class="pay-bar">
  <text class="amount">应付金额</text>
  <button type="primary" onTap="onPay">立即支付</button>
</view>
<!-- 金额字段用双大括号包裹 data.amount 渲染 -->

注意两处细节：事件绑定在支付宝是 onTap（微信是 bindtap），按钮通过 type 属性指定主次样式。这类命名差异是迁移时最容易漏改的地方，建议在改造前先整理一份「命名对照表」，逐项替换而不是靠记忆。

支付宝登录态与支付接入

登录和支付是支付宝端的两条主干。先说登录：小程序不直接暴露用户身份，而是先向平台申请一个临时凭据 authCode，再把它交给自己的后端去换取用户标识。整个过程客户端不接触任何密钥，这是最安全也最标准的做法。

// 客户端：拿 authCode 交给后端
my.getAuthCode({
  scopes: "auth_base",
  success: function (res) {
    my.request({
      url: "/api/login",
      method: "POST",
      data: { code: res.authCode },
      success: function (r) {
        // 后端返回自有登录态 token，落本地存储供后续接口使用
        my.setStorageSync({ key: "token", data: r.data.token });
      }
    });
  }
});

后端拿到 authCode 后调用平台的换取接口，得到用户的唯一标识与基础信息，再签发自己的会话 token。要点有三：

  • authCode 一次性：用过即失效，不要缓存复用，否则会拿到「凭据无效」的错误。
  • 登录态自管：平台标识只是身份来源，业务权限必须由自己的 token 控制，方便多端统一。
  • 存储要谨慎：token 放在本地存储即可，敏感信息不要落到客户端。

支付链路同样遵循「后端创建交易、客户端唤起收银台」的原则。订单号与金额必须由后端生成，绝不能由前端传入，否则等于把改价权交给了浏览器：

// 客户端：后端下单成功后，用 tradeNO 唤起收银台
Page({
  onPay() {
    my.request({
      url: "/api/order/create",
      method: "POST",
      data: { skuId: this.data.skuId },
      success: function (r) {
        my.tradePay({
          tradeNO: r.data.tradeNo,
          success: function (res) { console.log("支付结果码：", res.resultCode); }
        });
      }
    });
  }
});

支付结果务必以后端收到的异步通知为准，客户端的成功回调只能作为交互提示。用户可能在支付中途切走、可能重复点击，只有服务端的回调才是可信的状态变更依据。

百度小程序的智能生态与入口

百度小程序最大的价值在入口：它直接承接百度搜索与信息流的流量。用户在搜索结果里点击一个服务，可以直接进入你的小程序完成操作，而不必经历「跳到某个 App、再找功能」的过程。对做工具、查询、生活服务类产品的团队来说，这是一条被低估的获客路径。

要吃到这部分流量，需要在三件事上做准备：

  • 页面信息与搜索意图对齐：标题、摘要与页面主体要回答用户搜索的问题，而不是堆砌关键词。
  • 配置可被收录的页面：把希望被检索的页面纳入索引配置，并提供清晰的路径。
  • 首屏即结论：用户从搜索进来带着明确问题，首屏就要给出结果或明确的操作入口。

在运营层面，百度小程序的常见做法是把「查询类功能」放在前面：输入一个条件，立刻返回结果；再把「服务类功能」作为下一步动作，引导用户登录或下单。这样既满足了搜索用户的即时需求，也保留了转化的空间。相比之下，一上来就要求登录、要求授权的做法，在这个生态里流失率会明显更高。

百度小程序开发：Swan 结构与页面

百度小程序的框架叫 Swan，页面结构与微信小程序最接近：同样是「模板 + 样式 + 逻辑」三件套，Page 注册页面，动态数据用双大括号绑定，条件渲染用 s-if。如果团队已经做过微信小程序，迁移到百度的成本主要来自后缀与命名空间。

<view class="card">
  <text class="title">标题字段</text>
  <input placeholder="输入要查询的城市" bindinput="onInput" />
  <button bindtap="onQuery">查询</button>
  <view class="result">结果条数文本</view>
</view>
<!-- 标题与结果条数用双大括号绑定 data 字段；结果区域用 s-if 控制是否渲染 -->

逻辑层用 swan 命名空间发起请求，条件渲染使用 s-if 而不是 wx:if，这是迁移时最需要留意的语法点：

Page({
  data: { title: "城市查询", list: [] },
  onQuery() {
    swan.request({
      url: "https://example.com/api/city",
      data: { city: this.data.city },
      success: function (res) {
        this.setData({ list: res.data.list });
      }.bind(this)
    });
  }
});

这里顺带说一个容易踩的坑：回调函数里的 this 不再指向页面实例，直接调用 this.setData 会报错。要么用 bind(this) 绑定上下文，要么在回调外先把 var that = this; 存下来。这是所有小程序平台的共性问题，不只出现在百度端。