我把这些踩坑经验写成 12 个中文 AI 技能包，开源成 vue-uniapp-skills，支持 Cursor Rules、Claude Code Skills、Trae Rules、Codex（AGENTS.md），一行命令装进项目。

一行安装

在 uni-app 项目根目录执行：

npx -y github:MsNan/vue-uniapp-skills

只装某个工具，或只装部分技能：

npx -y github:MsNan/vue-uniapp-skills --tool cursor
npx -y github:MsNan/vue-uniapp-skills --skills uniapp-request,uniapp-cross-platform
npx -y github:MsNan/vue-uniapp-skills --list

12 个技能覆盖什么

技能长什么样：以请求封装为例

AI 最容易写错的是 401。多个接口同时 401 时，如果每个都去刷新 token、每个都跳登录页，用户会看到一串闪屏。技能里的写法是：并发 401 共享一个 refreshing Promise，刷新失败只跳一次登录。

let refreshing: Promise<boolean> | null = null
async function refreshToken(): Promise<boolean> {
  const user = useUserStore()
  if (!user.refreshToken) return false
  refreshing ||= new Promise<boolean>((resolve) => {
    uni.request({
      url: BASE_URL + '/auth/refresh',
      method: 'POST',
      data: { refreshToken: user.refreshToken },
      success: (r: any) => {
        if (r.statusCode === 200 && r.data.code === 0) {
          user.setToken(r.data.data)
          resolve(true)
        } else resolve(false)
      },
      fail: () => resolve(false),
    })
  }).finally(() => { refreshing = null })
  return refreshing
}

另外几条硬约束也会写进规则里：

• 用 uni.request，不要用 axios（小程序没有 XHR，除非单独装适配器）
• 标签用 view / text / image，不用 div / span / img
• 尺寸用 rpx，1px 边框单独用 px
• 平台差异大时用条件编译，并给出降级方案

跨端条件编译怎么写

<!-- #ifdef MP-WEIXIN -->
<button open-type="getPhoneNumber" @getphonenumber="onPhone">手机号登录</button>
<!-- #endif -->
<!-- #ifdef H5 || APP-PLUS -->
<SmsLogin />
<!-- #endif -->

JS 用 // #ifdef，CSS 用 /* #ifdef */。平台标识：H5、MP-WEIXIN、APP-PLUS、MP（所有小程序）。业务层尽量调统一接口，平台细节收到 platform/ 里。

适合谁

• 用 Cursor / Claude Code / Trae / Codex 写 Vue3 + uni-app 的同学
• 接单、做毕设、维护小程序的人（审核清单和分包规则特别实用）
• 想让 AI「一开始就写对」，而不是生成完再改 20 分钟的人

相关链接

• 源码：github.com/MsNan/vue-uniapp-skills
• 同系列：cn-dev-mcp（国内开发者离线 MCP 工具集）
• 博客项目页：msnan.github.io

MIT 开源。有问题或想加新技能，直接提 Issue / PR。

⚠️ 先说风险：个人微信的第三方自动化违反《微信个人账号使用规范》，存在封号风险。本文仅供学习 Windows UI 自动化与消息处理的技术思路，请勿用于商业或骚扰用途，实验请用小号。

一、背景：为什么选 UI 自动化

想让程序读微信群消息，常见路子有三条：Hook 注入、协议逆向、UI 自动化。前两条风险高、维护成本也高，微信一升级就要重新逆向。UI 自动化走的是 Windows 给读屏软件准备的无障碍接口（UI Automation），只"看"界面、"按"键盘，不碰进程内存，实现上最朴素。

代价也很明确：

• 只能在 Windows 上跑，而且必须是已登录的交互式桌面（锁屏就读不到）；
• 强依赖微信客户端版本——实测 4.1.8.107 可用，4.1.13 起关闭了无障碍接口，任何 UI 自动化方案都读不到内容。

整个项目只依赖一个开源库 uiautomation（Apache-2.0），读写微信界面的部分自己封装在 wxui/ 里。

二、wxui：把微信窗口"读"出来

2.1 找主窗口：别只认一个类名

第一个坑：微信主窗口的 ClassName 不固定。同一台机器上实测出现过 mmui::MainWindow 和 Qt51514QWindowIcon 两种，重启后还会变。所以按"类名 + 标题 + 尺寸"多特征匹配：

MAIN_WINDOW_CLASSES = ("mmui::MainWindow", "Qt51514QWindowIcon")
MIN_MAIN_WIDTH = 500
MIN_MAIN_HEIGHT = 400

for child in root.GetChildren():
    cls = str(child.ClassName or "")
    name = str(child.Name or "")
    rect = child.BoundingRectangle
    if cls not in MAIN_WINDOW_CLASSES:
        continue
    if name != "微信":
        continue
    w, h = rect.width(), rect.height()
    if w < MIN_MAIN_WIDTH or h < MIN_MAIN_HEIGHT:
        continue   # 登录窗、托盘小窗也可能同类名，用尺寸排除
    if w * h > best_area:
        best, best_area = child, w * h

2.2 先判断"读不读得到"，再谈别的

版本不对时，症状是"窗口找得到，内容全是空的"，非常迷惑。我用 WM_GETOBJECT 直接探测窗口有没有实现无障碍接口：

def _has_accessibility(hwnd):
    # 返回 0 表示完全没有 —— 实测微信 4.1.13.12 就是 0
    return int(ctypes.windll.user32.SendMessageW(
        hwnd, _WM_GETOBJECT, 0, ctypes.c_long(_OBJID_CLIENT).value))

返回 0 就直接抛 AccessibilityUnavailable，和"微信没启动"的 WeChatNotRunning 区分开：前者等多久都没用，后者可以等。把不同性质的失败分成不同异常，上层才能做对的决策。

2.3 新消息怎么算：最长公共后缀对齐

UI 自动化只能拿到"当前屏幕上可见的消息列表"，没有消息 id。每轮轮询拿到一个列表，要算出"本轮新增"。

直觉做法是用集合去重，但那样"同一个人连发两条『在吗』"会被吞掉一条。最后用的是最长公共后缀对齐：

def diff_new(previous, current):
    """
        previous:  A B C D
        current:      C D E F   -> 新增 E F
    刻意不用集合去重，所以「D D」这种重复内容能正确识别成两条。
    """
    prev_keys = [m.key() for m in previous]
    cur_keys = [m.key() for m in current]
    max_k = min(len(prev_keys), len(cur_keys))
    for k in range(max_k, 0, -1):
        if prev_keys[-k:] == cur_keys[:k]:
            return current[k:]
    # 完全对不上：可能切了会话或列表被整体刷新，交给上层重建基线
    return None

对不上时返回 None 而不是"全部当新消息"——后者会导致一次性回复一大堆，相当于刷屏。

2.4 判断"是不是自己发的"：看气泡颜色

不识别自己的消息，机器人就会自问自答进入死循环。UIA 树里没有可靠的"发送方"字段，位置判断又受窗口宽度和缩放影响，最终方案是沿消息行中线横扫像素，找最宽的非背景色块（即气泡），按颜色判定：

if best is None or best[0] < 30:
    return None
color = best[1]
if _rgb_close(color, SELF_BUBBLE_RGB):
    return True
if _rgb_close(color, PEER_BUBBLE_RGB):
    return False
return None

关键约定：判不出来返回 None，业务层把 None 当成"不可回复"，绝不默认成"别人发的"。另一个踩过的坑是视口边缘只露出半截的消息，行中线落在可见区外，扫出来是空的——所以采样 y 要先夹到列表可见范围内。

2.5 发送：宁可不发，绝不发错群

发错群是最严重的事故，所以 send_text 做了三道确认：

cur = self.current_chat()
if cur != expect_chat:
    raise TargetMismatch("发送前复核不通过 ...")

uia.SetClipboardText(text)          # 中文用剪贴板粘贴，SendKeys 打中文不可靠
box.SendKeys("{Ctrl}a", waitTime=0.05)
box.SendKeys("{Ctrl}v", waitTime=0.15)

cur2 = self.current_chat()          # 输入过程中焦点可能被别的窗口抢走
if cur2 != expect_chat:
    raise TargetMismatch("输入完成后复核不通过 ...")

box.SendKeys("{Enter}", waitTime=0.1)
verified = self._verify_sent(text, verify_timeout)   # 回读界面确认

最后一步 _verify_sent 会在几秒内回读最近的"自己发的消息"，确认内容真的出现了。"调用没报错"不等于发出去了，这一步不能省。

三、三层回复决策链

收到一条消息后，按顺序走三层，命中即停：

为什么业务指令必须排在 AI 前面？**订单号、库存、金额这类有唯一正确答案的问题，交给大模型它会编，而且编得很像真的。**所以这类问题先由业务指令拦下：

result = handlers.route(sender, content, group, api=API, db=DB, store=STORE)

if isinstance(result, handlers.AIAnswer):
    # 查到真实数据了，让 AI 只负责"用人话组织一下"
    if AI and AI.enabled:
        text = _ai_reply(trace, sender, content, group,
                         extra_context=result.as_context())
        if text:
            return text, "业务指令+AI播报"
    # AI 不可用就把原始数据直接给出去，总比不回强
    return result.as_context(), "业务指令(AI不可用,直出数据)"

if isinstance(result, str) and result:
    return result, "业务指令"

text = match_rules(sender, content, group)
if text:
    return text, "关键词规则"

if AI and AI.enabled:
    ...  # 第 3 层：AI 兜底

"业务指令 + AI 播报"模式下，system prompt 里会硬性追加：

sys_text += f"\n\n【以下是系统查询到的真实数据，回答必须基于它，不要编造】\n{extra_context}"

AI 只负责措辞，不负责事实。

四、多模型降级与熔断

AI 层支持配置多个 OpenAI 兼容接口（智谱、DeepSeek、通义等），按顺序尝试，一个失败就换下一个：

for p in self.providers:
    if not p.available:
        continue
    text = p.chat(messages)
    if text:
        self.memory.add(group, "user", f"{sender}: {content}")
        self.memory.add(group, "assistant", text)
        return text

log.warning("[AI] 所有模型都失败了，降级不回复")
return None

单个 provider 连续失败 3 次就熔断 120 秒，避免每条消息都去撞一个已经挂掉的接口：

def _mark_fail(self, reason):
    self._fails += 1
    if self._fails >= 3:
        self._blocked_until = time.time() + 120
        self._fails = 0

几个兼容性细节：

• 有的厂商 base_url 自带 /v1，有的不带，_endpoint() 统一拼成 .../chat/completions；
• 智谱 GLM-4.5 起的"思考模式"会把输出吃光、content 返回空，需要传关闭开关；但别的厂商传了这个字段会直接 400，所以按"厂商 + 模型名"双重判定，宁可不传也不要报错；
• 会话记忆按群隔离，只保留最近几轮，控制 token 成本。

五、降低封号风险的几道闸

再强调一次：这些措施只能降低风险，不能消除。

def check(self, sender, group):
    while self._hour_window and now - self._hour_window[0] > 3600:
        self._hour_window.popleft()
    if len(self._hour_window) >= config.MAX_REPLIES_PER_HOUR:
        return False, f"已达每小时上限 {config.MAX_REPLIES_PER_HOUR} 条"
    if now - self._sender_last.get(sender, 0) < config.PER_SENDER_COOLDOWN:
        return False, f"对 {sender} 冷却中"
    if now - self._group_last.get(group, 0) < config.PER_GROUP_COOLDOWN:
        return False, f"群 {group} 冷却中"
    return True, ""

• 每小时上限：滑动窗口计数；
• 同人冷却 / 同群冷却：避免短时间对同一人、同一群连续回复；
• 随机延迟：random.uniform(*config.REPLY_DELAY_RANGE)，不在收到消息的同一秒回复；
• 连续发送失败保护：连续失败到阈值进入冷静期，期间只收不发，不在微信异常时反复操作。

注意 check 和 commit 是分开的：只有真正发送成功才记入冷却和计数，失败的尝试不占额度。

六、踩过的坑汇总

1. 内容指纹去重误杀：最初在 id 去重之外又叠了一层"内容指纹去重"，结果用户故意连发两条"在吗"，第二条被吞了。后来改为：适配层已经按序列对齐分配稳定 id 时，关掉指纹去重。
2. 去重有效期不能永久：否则同一个人今天说"在吗"、明天再说"在吗"，第二次永远收不到回复。
3. @ 功能放弃了：微信的 @ 需要从候选列表里挑人，无法在发送前确认挑对了，干脆改成在正文里带称呼。
4. 昵称不稳定：多条消息同一瞬间到达时，只有最后一条能拿到发送者昵称，其余只能显示"群成员"。依赖严格白名单的场景要提前评估。
5. 微信会静默自动升级：这是故障复发的头号原因，升级到 4.1.13+ 就彻底读不到。部署时必须堵掉自动更新，启动时也会打印当前微信版本用于排查。
6. 剪贴板被覆盖：中文用剪贴板粘贴发送，会覆盖系统剪贴板，挂机的机器上要知道这一点。

七、小结

这个项目最大的体会是：UI 自动化的难点不在"能不能读到"，而在"读错了怎么办"。 判不出是谁发的就不回、会话对不上就不发、发了要回读确认、AI 不知道的事不让它答——每一处都选择保守，代价是偶尔漏回，换来的是不发错、不刷屏、不胡说。

再次提醒：个人微信自动化有封号风险，仅供学习交流，请用小号测试。

完整源码开源在 GitHub https://github.com/MsNan/wechat-group-bot

顺带一提，作者之前还开源了一个 uni-app 商城项目，有兴趣可以看看：https://github.com/MsNan/taohaowu-shop

技术栈：后端 Express + jsonwebtoken + lowdb；前台 uni-app（Vue 3 + Pinia）；管理后台为原生 JS 单页。

一、整体思路

关键点在于：两类 Token 用同一个 SECRET 签发，但载荷字段不同，各自的中间件只认自己的字段。这样即使用户拿着自己的 Token 去请求 /api/admin/*，也会因为没有 admin 字段被拒绝；反过来管理员 Token 没有 uid，也调不了用户接口。

二、密钥配置：开发与生产区分

const SECRET = process.env.JWT_SECRET || (process.env.NODE_ENV === 'production' ? (await import('node:crypto')).randomBytes(32).toString('hex') : 'taohaowu-dev-secret')

这一行做了三层兜底：

1. 优先读环境变量 JWT_SECRET；
2. 生产环境没配置时，启动时随机生成 32 字节密钥，避免使用人人都知道的默认值；
3. 开发环境用固定字符串，方便重启后 Token 仍然有效。

注意第 2 点的副作用：服务每次重启，所有已签发的 Token 都会失效。所以生产环境一定要显式配置 JWT_SECRET，随机密钥只是安全兜底，不是推荐用法。

三、前台用户：签发与校验

1. 登录签发

app.post('/api/auth/login', async (req, res) => {
  const { phone, code } = req.body
  const c = db.data.codes[phone]
  if (!c || c.code !== String(code) || Date.now() > c.exp) return fail(res, '验证码错误或已过期')
  delete db.data.codes[phone]
  let u = db.data.users.find(u => u.phone === phone)
  if (!u) { u = { id: nid(), phone, nickname: '淘友' + phone.slice(-4), createdAt: Date.now() }; db.data.users.push(u) }
  if (u.disabled) return fail(res, '账号已被禁用', 403)
  await db.write()
  ok(res, { token: jwt.sign({ uid: u.id }, SECRET, { expiresIn: '30d' }), user: u })
})

几个细节值得注意：

• 验证码校验通过后立即 delete，保证一码一用，防止重放；
• String(code) 统一类型，避免前端传数字导致 !== 判断失败；
• 首次登录自动注册，登录和注册合并成一个接口；
• 载荷里只放 uid，不放手机号、昵称等信息。JWT 只是 Base64 编码而不是加密，任何人都能解出载荷内容。

2. 校验中间件

function auth(req, res, next) {
  const t = (req.headers.authorization || '').replace(/^Bearer /, '')
  try { req.uid = jwt.verify(t, SECRET).uid; if (!req.uid || db.data.users.find(u => u.id === req.uid)?.disabled) throw 0; next() } catch { fail(res, '请先登录', 401) }
}

这个中间件把所有失败情况都收敛到一个 catch 里，统一返回 401：

• 没带 Token / 格式错 / 签名不对 / 已过期 —— jwt.verify 直接抛错；
• Token 合法但没有 uid（比如拿管理员 Token 来调）—— 手动 throw 0；
• 用户已被后台禁用 —— 同样 throw 0。

最后一点很重要：JWT 本身是无状态的，签出去就无法撤回。30 天有效期内如果用户被封禁，单靠 jwt.verify 是拦不住的。这里每次请求都去查一下用户的 disabled 标记，用一次轻量查询换来了"即时封禁"的能力。

使用时直接挂在路由上：

app.get('/api/me', auth, (req, res) => ok(res, db.data.users.find(u => u.id === req.uid)))

四、管理后台：签发与统一守卫

const safeEq = (a, b) => { const x = Buffer.from(String(a)), y = Buffer.from(String(b)); return x.length === y.length && crypto.timingSafeEqual(x, y) }
app.post(A + '/login', (req, res) => {
  const { username, password } = req.body || {}
  if (!safeEq(username, ADMIN_USER) || !safeEq(password, ADMIN_PASSWORD)) return fail(res, '账号或密码错误', 401)
  ok(res, { token: jwt.sign({ admin: username }, SECRET, { expiresIn: '12h' }), edition: EDITION })
})
const guard = (req, res, next) => {
  try { const p = jwt.verify((req.headers.authorization || '').replace(/^Bearer /, ''), SECRET); if (!p.admin) throw 0; next() } catch { fail(res, '请先登录后台', 401) }
}
app.use(A, (req, res, next) => (req.path === '/login' ? next() : guard(req, res, next)))

和用户侧相比有三处不同：

1. 用 timingSafeEqual 比较密码。 普通的 === 在遇到第一个不同字符时就返回，攻击者理论上可以通过响应时间差逐位猜测。crypto.timingSafeEqual 是常量时间比较，但它要求两个 Buffer 长度一致，否则直接抛异常，所以前面先判断了 x.length === y.length。

2. 有效期只有 12 小时。 后台权限大，Token 泄露的代价远高于普通用户，缩短有效期是最简单的降低风险的方式。

3. 用前缀中间件统一守卫。 不必在每个后台路由上手动写 guard，而是 app.use('/api/admin', ...) 一次性拦截，只放行 /login。新增后台接口时不会因为忘记加中间件而裸奔，这比逐个路由挂中间件更不容易出错。

此外，管理员密码也做了和 SECRET 类似的兜底：

if (!ADMIN_PASSWORD) {
  if (process.env.NODE_ENV === 'production') { ADMIN_PASSWORD = crypto.randomBytes(9).toString('base64url'); console.warn('[admin] 未设置 ADMIN_PASSWORD，本次随机密码：' + ADMIN_PASSWORD) }
  else { ADMIN_PASSWORD = 'admin123'; console.warn('[admin] 开发模式默认账号 admin / admin123，生产环境请设置 ADMIN_PASSWORD') }
}

生产环境绝不使用弱口令默认值，这是很多开源项目上线后被入侵的常见原因。

五、uni-app 请求封装：自动携带 JWT

export function request(url, { method = 'GET', data } = {}) {
  const token = uni.getStorageSync('token')
  return new Promise((resolve, reject) => {
    uni.request({
      url: API_BASE + '/api' + url, method, data,
      header: token ? { Authorization: 'Bearer ' + token } : {},
      success: r => {
        if (r.statusCode === 200 && r.data.code === 0) return resolve(r.data.data)
        const msg = r.data?.message || '请求失败'
        if (r.statusCode === 401) { uni.removeStorageSync('token') }
        uni.showToast({ title: msg, icon: 'none' }); reject(new Error(msg))
      },
      fail: e => { uni.showToast({ title: '网络开小差了', icon: 'none' }); reject(e) }
    })
  })
}

要点：

• 每次请求时才读取 Token，而不是在模块顶部读一次缓存起来。否则登录后旧模块里的变量还是空值，要刷新页面才生效。
• 没有 Token 时不发送 Authorization 头，避免后端收到 Bearer undefined。
• uni.request 的 success 回调只要服务器有响应就会触发，包括 4xx/5xx，只有网络层失败才进 fail。所以必须同时判断 statusCode 和业务码 code。
• 统一解包 r.data.data，业务代码拿到的直接就是数据。

登录成功后在 Pinia 中写入 Token：

async login(phone, code) {
  const r = await api.login(phone, code)
  this.token = r.token; this.user = r.user
  uni.setStorageSync('token', r.token); uni.setStorageSync('user', r.user)
  // ...合并游客购物车
},
requireLogin() {
  if (this.token) return true
  uni.navigateTo({ url: '/pages/login/login' }); return false
}

六、管理后台的 401 处理

async function api(url, opt = {}) {
  const r = await fetch('/api/admin' + url, { method: opt.method || 'GET', headers: { 'Content-Type': 'application/json', ...(token ? { Authorization: 'Bearer ' + token } : {}) }, body: opt.body && JSON.stringify(opt.body) })
  const j = await r.json().catch(() => ({}))
  if (r.status === 401 && url !== '/login') { logout(); throw new Error('登录已过期') }
  if (j.code !== 0) { toast(j.message || '请求失败'); throw new Error(j.message) }
  return j.data
}

注意 url !== '/login' 这个条件：登录接口密码错误时也返回 401，如果不排除，用户输错密码会被当成"登录过期"，提示信息就错了。这是 401 统一处理时非常常见的一个坑。

七、常见坑总结

1. 用户 Token 越权调用后台接口。 两套 Token 共用 SECRET 时，中间件必须校验角色字段（本文的 uid / admin），只校验签名等于没有角色隔离。更严格的做法是两个角色使用不同的密钥。

2. 封禁后 Token 依然可用。 JWT 无法主动撤销，需要在中间件里查一次用户状态，或者维护黑名单。

3. 生产环境沿用默认密钥 / 默认密码。 一旦源码公开，等于把签名密钥公开，任何人都能伪造管理员 Token。

4. 401 只清了 Storage，没清内存状态。 本文的 uni-app 封装在 401 时执行了 uni.removeStorageSync('token')，但 Pinia 里的 this.token 还在，requireLogin() 仍会返回 true，页面会显示已登录。修正方法是在 401 时同时调用 store 的 logout()。由于 store 本身也 import 了 request.js，两者存在循环引用，所以 useShopStore() 要放在回调内部调用，而不是在模块顶层执行：

   js

   import { useShopStore } from '../store'
   // ...
   if (r.statusCode === 401) { uni.removeStorageSync('token'); try { useShopStore().logout() } catch (e) {} }

5. 登录接口自身的 401 被误判为过期，如第六节所示，需要排除登录地址。

6. 把敏感信息放进载荷。 JWT 载荷可被任意解码，只放 ID 和角色标识。

7. uni.request 的 success 不等于成功。 一定要判断 statusCode。

八、小结

这套方案的核心可以归纳为三句话：同一密钥、不同载荷、中间件只认自己的字段；有效期按权限大小区分；前端在请求层统一携带 Token、统一处理 401。对于中小型项目，这样已经能满足大部分双角色场景。如果后续角色增多，可以把载荷改为 { sub, role }，再写一个 requireRole('admin') 的中间件工厂来扩展。

完整代码见 GitHub：MsNan/taohaowu-shop

一套 uni-app 代码跑 H5、小程序和 App，后端 Node.js + Express，自带 /admin 管理后台，开源免费。本文按真实代码讲技术栈、架构和几段关键实现。

一、技术栈

二、整体架构

src/                 uni-app 前端（pages / components / store / api）
  api/request.js     统一请求封装，自动带 JWT
server/
  index.js           前台全部 REST 接口（约 200 行）
  admin.js           管理后台接口
  edition.js         免费版 / 付费版功能开关
  admin/             后台页面（原生 JS）
  seed.json          商品、分类、轮播种子数据

前台和后台共用同一份 lowdb 数据，后端构建 H5 后还会顺手托管 dist/build/h5，所以一个 npm start 就能同时访问商城和后台。

前台已实现：首页（搜索、轮播、秒杀倒计时、商品流）、分类、搜索、商品详情与规格弹层、购物车（游客购物车登录后自动合并）、手机号验证码登录（模拟短信）、收货地址、下单 → 模拟收银台 → 订单列表/详情、售后申请（仅退款 / 退货退款 / 换货）。

三、关键代码

1. JWT 登录

验证码登录成功后签发 token，未注册手机号自动建号：

app.post('/api/auth/login', async (req, res) => {
  const { phone, code } = req.body
  const c = db.data.codes[phone]
  if (!c || c.code !== String(code) || Date.now() > c.exp) return fail(res, '验证码错误或已过期')
  delete db.data.codes[phone]            // 验证码一次性
  let u = db.data.users.find(u => u.phone === phone)
  if (!u) { u = { id: nid(), phone, nickname: '淘友' + phone.slice(-4), createdAt: Date.now() }; db.data.users.push(u) }
  if (u.disabled) return fail(res, '账号已被禁用', 403)
  await db.write()
  ok(res, { token: jwt.sign({ uid: u.id }, SECRET, { expiresIn: '30d' }), user: u })
})

鉴权中间件同时检查“用户是否被后台禁用”：

function auth(req, res, next) {
  const t = (req.headers.authorization || '').replace(/^Bearer /, '')
  try {
    req.uid = jwt.verify(t, SECRET).uid
    if (!req.uid || db.data.users.find(u => u.id === req.uid)?.disabled) throw 0
    next()
  } catch { fail(res, '请先登录', 401) }
}

前端在 request.js 里统一加 Authorization: Bearer <token>，收到 401 就清掉本地 token。后台登录用 crypto.timingSafeEqual 比较账号密码，签发的 token 里带 admin 字段，和前台 token 互不通用。

2. 订单状态流转

状态：待付款 → 待发货 → 待收货 → 已完成，待付款可转 已取消。用一个小工厂函数统一做“当前状态是否允许这个动作”的校验，并记录时间线：

function transit(from, to, msg, extra) {
  return async (req, res) => {
    sweep(); const o = myOrder(req.uid, req.params.id)
    if (!o) return fail(res, '订单不存在', 404)
    if (!from.includes(o.status)) return fail(res, `当前状态「${o.status}」不可操作`)
    o.status = to; o.timeline.push({ t: Date.now(), s: msg }); extra?.(o, req); await db.write(); ok(res, o)
  }
}
app.post('/api/orders/:id/pay',     auth, transit(['待付款'], '待发货', '支付成功（模拟）', ...))
app.post('/api/orders/:id/cancel',  auth, transit(['待付款'], '已取消', '用户取消订单', ...))
app.post('/api/orders/:id/confirm', auth, transit(['待收货'], '已完成', '已确认收货，交易完成'))

未支付超时自动取消（默认 15 分钟，PAY_TIMEOUT_MS 可改）：定时器每 10 秒扫一次，查询订单前也会先扫一次。

function sweep() {
  const now = Date.now(); let changed = false
  for (const o of db.data.orders)
    if (o.status === '待付款' && now > o.expireAt) { o.status = '已取消'; o.cancelReason = '超时未支付'; changed = true }
  if (changed) db.write()
}
setInterval(sweep, 10 * 1000)

3. 免费版 / 付费版授权校验思路

所有功能登记在一张表里，free 人人可用，pro 需要授权：

export const FEATURE_TABLE = {
  'admin.products': 'free', 'admin.orders': 'free', 'admin.dashboard.basic': 'free', ...
  'admin.dashboard.charts': 'pro', 'admin.export.csv': 'pro', 'admin.aftersale': 'pro',
  'admin.products.batch': 'pro', 'admin.rewards.manage': 'pro', 'admin.users.disable': 'pro'
}

启动时用 EDITION、LICENSE_OWNER、LICENSE_SALT、LICENSE_KEY 校验授权码（TH-PRO- + sha256(owner:salt) 前 16 位），不匹配就自动回退免费版。关键在于接口层拦截，不是只把前端按钮藏起来：

const need = f => (req, res, next) =>
  has(f) ? next() : fail(res, '该功能属于付费版，请配置授权后使用', 402)
app.get(`${A}/orders-export`, need('admin.export.csv'), ...)
app.get(`${A}/aftersales`,    need('admin.aftersale'), ...)

实话说一句：开源代码里的离线校验只是“功能开关”，不是防破解机制。想做真正的授权，需要服务端在线校验。

四、截图

五、运行步骤

需要 Node.js 18+。

git clone https://github.com/MsNan/taohaowu-shop.git
cd taohaowu-shop/server && npm install && npm start   # http://localhost:3000
# 另开终端，在项目根目录
npm install && npm run dev:h5                          # H5 开发调试
# 或 npm run build:h5，构建后直接访问 http://localhost:3000

• 管理后台：http://localhost:3000/admin/ ，开发模式默认 admin / admin123；生产环境务必设置 JWT_SECRET 和 ADMIN_PASSWORD（不设置时会生成随机密码打印到控制台）。
• 验证码：开发模式会打印在后端控制台，并显示在登录页。
• 微信小程序：npm run build:mp-weixin，用微信开发者工具导入 dist/build/mp-weixin。
• App：用 HBuilderX 打开项目云打包（iOS 需要 Apple 开发者账号）。
• 端到端测试：node tests/e2e.cjs（puppeteer-core + 无头 Chrome）。

六、局限（写在前面免得踩坑）

• lowdb 是单文件数据库，只适合演示和小流量，正式环境建议换 MySQL/PostgreSQL。
• 短信和支付都是模拟的，上线需要接入真实短信服务和微信/支付宝支付。

获取源码

• 免费版（开源）：https://github.com/MsNan/taohaowu-shop
• 付费进阶版（趋势图表、CSV 导出、售后审核、批量上下架、用户禁用、打赏核对）：正在整理，上架后会在公众号「程序员项目库」发通知
• 交流：关注公众号「程序员项目库」

本项目仅供学习参考。