name: wechat-miniapp-zh displayName: 微信小程式開發助手 slug: wechat-miniapp-zh version: 1.0.0 author: ikun license: MIT language: zh-CN description: | 微信小程式開發的全流程助手——從 appid 申請、原生 / Taro / uni-app 選型、雲開發 / 自建後端選型， 到登入鑑權、支付、訂閱訊息、稽核避坑。區別於通用 Web 開發，專攻微信生態特殊性。 覆蓋：技術選型、架構設計、關鍵 API、稽核駁回原因 5 大類、安全合規。 觸發：使用者說 "微信小程式"、"小程式開發"、"Taro"、"uni-app"、"雲開發"、"wx.login"、"小程式支付"、"訂閱訊息"、"稽核駁回"。 keywords: ["微信小程式", "小程式開發", "Taro", "uni-app", "雲開發", "wx.login", "微信支付", "訂閱訊息", "小程式稽核", "appid", "WXML", "WXSS"]

微信小程式開發助手

這個 skill 解決什麼

微信小程式和 Web 開發完全是兩個物種： - 沒有 DOM、沒有 window、沒有 localStorage（有自己的 wx.setStorage） - 路由不是 react-router / vue-router（是 wx.navigateTo 那一套） - 沒有第三方 npm 包用（90% 的 npm 包都跑不起來） - 登入、支付、訊息全是微信家的 API - 稽核被駁回不告訴你具體哪行錯（只給一句"違反 X.X 條款"）

這個 skill 幫你： 1. 選型決策：原生 / Taro / uni-app 選哪個 2. 關鍵 API 速查：登入、支付、訂閱訊息、wx 全家桶 3. 稽核避坑：5 大類駁回原因 + 修復策略 4. 架構設計：雲開發 vs 自建後端怎麼選

不做的事：不替你寫完整業務程式碼（場景太多）；不做 UI 設計；不做支付證書申請那種純賬號工作。

選型決策（一上來就要對）

3 種主流方案對比

決策樹

是不是隻釋出微信？
├─ 是 → 團隊會 React 嗎？
│       ├─ 會 → Taro（更現代）或 原生（更穩）
│       └─ 不會 → 原生（學習成本最低）
└─ 否（要發抖音 / 支付寶 / H5 / App）→
        ├─ 團隊 React → Taro
        └─ 團隊 Vue → uni-app（多端相容性最好）

後端選型（雲開發 vs 自建）

雲開發（CloudBase）

• 適合：MVP / 輕量應用 / 不會運維
• 優勢：免伺服器、免域名備案、自帶雲函式 / 資料庫 / 儲存
• 劣勢：貴（DAU 上去 1 萬 + 每月 2k+）、不能用複雜的 SQL、遷出難
• 成本：免費版 1 萬次呼叫 / 月，付費版按用量

自建後端（Node / Java / Python + 伺服器）

• 適合：業務複雜 / 長期產品 / 團隊有後端
• 優勢：可控、便宜、能用任何技術棧
• 劣勢：需要伺服器 + 域名 + 備案 + ICP（最少 1 個月）、要自己運維
• 成本：阿里雲 / 騰訊雲輕量伺服器 60 元 / 月起

決策建議

7w4.net小蔥技能。

• 3 個月內 MVP → 雲開發
• 正式產品 / 長期 → 自建（早晚要遷，越早越好）

關鍵 API 速查

1. 登入與使用者資訊

// 1. 拿臨時登入憑證
wx.login({
  success: async (res) => {
    // res.code 5 分鐘有效，要立即發給後端
    const { openid, session_key } = await fetch('/api/wx/login', {
      method: 'POST',
      body: JSON.stringify({ code: res.code })
    }).then(r => r.json())
    // 儲存 openid 到本地
    wx.setStorageSync('openid', openid)
  }
})

// 2. 後端用 code 換 openid（必須服務端做，不能前端）
// GET https://api.weixin.qq.com/sns/jscode2session?
//   appid=xxx&secret=xxx&js_code=CODE&grant_type=authorization_code

坑： - wx.getUserInfo 2021 年起已廢棄，必須用 <button open-type="getUserProfile"> 主動觸發 - 頭像暱稱從 2022 年起需要用 <button open-type="chooseAvatar"> 單獨獲取 - 手機號必須用 <button open-type="getPhoneNumber"> 使用者主動授權 → 後端解密

2. 微信支付（最複雜 API）

// 前端：調起支付
wx.requestPayment({
  timeStamp: '...',  // 來自後端
  nonceStr: '...',
  package: 'prepay_id=...',
  signType: 'MD5',
  paySign: '...',
  success: (res) => { /* 支付成功 */ },
  fail: (err) => { /* 支付失敗/取消 */ }
})

// 後端流程：
// 1. 建立訂單到自己資料庫
// 2. 調微信統一下單 API（unifiedorder）
// 3. 拿到 prepay_id，組裝支付引數 + sign 給前端
// 4. 監聽微信回撥（必須驗籤 + 冪等處理）
// 5. 更新訂單狀態

坑： - 支付證書申請要 1 周（商戶號 → 申請 API 證書 → 下載 → 上傳伺服器） - 沙箱環境不可信，必須真實測試 - 退款需要再申請退款 API（預設不開通） - 回撥一定要做冪等（微信會重試）

3. 訂閱訊息（替代舊版模板訊息）

// 前端：使用者點選觸發，請求訂閱
wx.requestSubscribeMessage({
  tmplIds: ['xxx', 'xxx'],  // 後臺預先申請的模板 ID
  success: (res) => { /* res 裡看每個模板是否同意 */ }
})

// 後端：使用者操作後傳送
POST https://api.weixin.qq.com/cgi-bin/message/subscribe/send
{
  "touser": "使用者 openid",
  "template_id": "xxx",
  "page": "pages/order/detail?id=123",
  "data": { "thing1": { "value": "您的訂單已發貨" } }
}

坑： - 訂閱訊息是一次訂閱一次傳送（使用者每次都要重新訂閱） - 模板必須按微信類目申請（涉及行業資質） - 傳送時機有嚴格限制（使用者操作後 7 天 / 24 小時）

4. 資料儲存

// 同步（小資料量，<10KB 推薦）
wx.setStorageSync('key', value)
const value = wx.getStorageSync('key')

// 非同步（推薦用法）
wx.setStorage({ key, data })

// 單 key 上限 1MB，整個小程式 10MB

稽核駁回 5 大原因 + 修復

原因 1：未提供測試賬號

• 現象："提供測試賬號供稽核員體驗"
• 修復：在提交稽核備註裡寫"測試賬號 / 密碼"或"遊客可體驗"

原因 2：涉及虛擬支付

• 現象：iOS 端禁止虛擬物品（課程、會員、幣）支付，被駁回
• 修復：iOS 端必須關閉支付入口或轉用蘋果 IAP（個人小程式無法接 IAP）

原因 3：誘導分享 / 關注

• 現象："分享獲獎勵"、"關注公眾號才能用"
• 修復：把"必須分享 / 關注"改成"建議分享 / 關注"，福利改成普惠

原因 4：未稽核類目超範圍

• 現象：申請了"工具" 類目，裡面做了商城功能
• 修復：擴充套件類目（小程式後臺 → 服務類目 → 新增），有的類目要資質證明

原因 5：使用者協議 / 隱私協議缺失

• 現象：首次進入未彈出隱私協議、或協議內容不完整
• 修復：
• 必須在 app.json 裡配 __usePrivacyCheck__: true
• 首次進入彈隱私協議（用 wx.requirePrivacyAuthorize）
• 協議內容必須包含：收集什麼資訊 / 如何使用 / 如何保護 / 使用者權利

安全合規（高頻忽略點）

AI 執行流程

第一步：摸場景

1. 你是要做新小程式還是最佳化已有的？
2. 業務型別是什麼？（電商 / 工具 / 內容 / 社交 / 政務）
3. 團隊技術棧？（會 React / Vue / 還是從零學）
4. 是否要多端（除微信外的支付寶 / 抖音 / H5 / App）？
5. 預算情況（決定雲開發 vs 自建）？
6. 有沒有具體卡住的問題？（如稽核駁回、支付整合、效能最佳化）

第二步：給方案

按問題型別給： - 選型問題 → 輸出選型決策表 + 推薦 - API 問題 → 輸出程式碼示例 + 坑提示 - 稽核問題 → 輸出駁回型別分析 + 修復步驟 - 架構問題 → 輸出推薦架構圖 + 選型理由

第三步：自檢 checklist

• [ ] 涉及版本相容性的 API 註明微信版本要求
• [ ] 涉及證書 / 備案的提示前置時間
• [ ] 涉及合規的提示《個保法》《網際網路資訊服務管理辦法》
• [ ] 程式碼示例可直接執行（不是虛擬碼）
• [ ] 給了"下一步具體怎麼做"的步驟

輸出格式

## 你的問題
（複述）

## 推薦方案
（選型 / 架構 / API / 修復）

## 程式碼示例
```javascript
// 註釋清楚，不寫廢話

注意事項 / 坑

• 坑 1：XXX
• 坑 2：XXX

下一步行動

1. 先做 XXX
2. 然後 XXX
3. 最後 XXX

相關資料

• 官方文件：https://developers.weixin.qq.com/miniprogram/dev/...
• 社群帖子：xxx ```

終止條件

• 使用者拿到了可執行的方案 / 程式碼 / 步驟
• 涉及合規 / 安全的關鍵點提示完整
• 使用者沒追問"為什麼"

不主動寫完整業務程式碼（場景太多）；不主動給完整 UI 實現。

這個 Skill 質量較好，針對微信小程式開發者的實際痛點編寫，覆蓋全面且實用。優勢在於內容接地氣（稽核避坑、支付整合等本土化問題）、程式碼示例可執行、常見坑點標註清晰。不足之處是缺少示例演示和 FAQ，實際使用時可能需要結合其他資料學習。