门店平板换了个微信号登录，小程序里还挂着上一位导购的优惠券，是不是必须重启才算换账号？

结论先行：门店平板换了个微信号登录，小程序里还挂着上一位导购的优惠券、订单或会员价，多数不是微信把账号弄混，而是设备本地缓存、页面内存和后端查询条件没跟着账号走。2026 年项目交付里，微信侧 openid 会随微信号变化，但本地 Storage、全局状态和未销毁页面不会自动重置。这三处只要有一处还指向旧账号，用户看到的就是上一个人的数据。

换微信号后还显示上一个人的数据，通常卡在哪几层？

这类问题很少是单一原因，交付现场更常见的是几层叠加。排查顺序建议按账号标识、本地缓存、页面内存、后端归属往下看，别一上来就改登录组件。

1. 账号标识层：确认当前请求带的是不是新账号的登录态，openid 或用户 ID 是否已更新。常见坑是登录回调还没跑完，页面就发了请求，带的是旧 token。
2. 本地缓存层：检查 Storage 里的用户信息、购物车、浏览记录、草稿箱是否还挂着旧账号的 key。很多小程序把用户信息写在本地，换账号后没有清。
3. 页面内存层：全局状态、事件监听、定时器、未销毁的页面栈都可能保留上一个账号的数据。只清缓存不清页面状态，切回来仍可能看到旧内容。
4. 后端归属层：所有涉及用户数据的查询都要带当前账号条件，不能只靠前端传参。后端按 openid 或用户 ID 过滤，是防止旧数据被错误使用的一道闸。

前两层决定用户“看不看得到旧数据”，后两层决定旧账号数据“会不会被错误使用”。只做前端清理，后端仍按设备或旧会话取数，风险还在；只做后端过滤，前端页面不重建，用户视觉上仍会觉得没换过来。

2026 年为什么更容易碰到账号串号？

2026 年常见做法里，一个用户持有多个微信号、门店导购共用一台工作手机、测试同学在同一台设备上来回切账号，都比早些年更普遍。小程序运行在微信容器里，账号切换时平台会换 openid，但不会替开发者清掉本地 Storage、全局数据和页面栈。平台换的是身份，不是你的缓存。

从交付经验看，越把用户信息、会员等级、优惠券、购物车直接存在本地的小程序，越容易在换账号后暴露串号。尤其是先用旧账号浏览、再用新账号登录的半途切换，页面内存里还留着旧数据，接口又已经返回新账号结果，视觉上就会新旧混在一起。只要业务涉及订单、支付或隐私资料，账号隔离就不该往后排。

• 共用设备场景：门店平板、导购手机、家庭共用平板，换账号频率高，串号概率也高。
• 多微信号用户：同一个人有工作号和生活号，来回切换时容易触发。
• 测试与验收场景：测试同学在一台手机上切多个账号，如果没清缓存，会误报成线上问题。
• 隐私与合规场景：订单、地址、发票抬头属于个人信息，串号不只是体验问题。

三种处理方式对比：清缓存、按账号分桶、后端强校验

处理账号串号常见三类做法，不一定三选一，很多项目是组合使用。先看业务对数据残留的容忍度：只是展示型浏览记录，清掉即可；涉及订单和隐私，后端过滤不能省。下面是经验区间，实际取决于缓存项数量和接口数量。

• 方案 A：登录成功时清掉与用户相关的本地缓存，并重建页面栈。适合缓存 key 不多、账号切换不频繁的小程序。经验开发量约半天到 1 天，回归约半天。风险是清得太狠，可能把游客态收藏或未提交草稿一起清掉。
• 方案 B：按账号维度分桶存数据，缓存 key 里带 openid 或用户 ID。适合需要保留多账号各自浏览记录或草稿的场景。经验开发量约 1 到 2 天，回归要覆盖多账号来回切换，比较容易漏掉旧账号残留。
• 方案 C：前端只存登录凭证，用户数据全部由后端按当前账号返回。适合订单、支付、发票、隐私资料等场景。经验开发量约 2 到 4 天，取决于接口改造数量。好处是即使前端缓存没清干净，接口也不会把旧账号数据吐出来。

组合建议是：前端做一次登录后的定向清理，后端所有用户数据查询强制带当前账号条件，关键页面在 onShow 时重新拉一次数据。三件事缺一件，都可能在某个边界场景露出来。

交付现场：门店平板轮流登录时怎么收口？

项目里常见一种情况：预算和周期都压得紧，测试只安排了一台旧手机，甲方运营同学拿它来回切三个微信号验收。做法是在登录成功回调里先清用户相关缓存，再让个人中心、订单页和优惠券页在 onShow 时重新请求，后端查询条件统一带当前用户 ID。代价是要多花半天到一天做多账号回归；如果跳过这一步，上线后客服工单往往会集中到“看到别人订单”这一类，返工成本比提前做高。按项目交付里的常见区间，账号隔离核对最好在提测前完成一轮，别等验收当天才发现。

适用与不适用的边界

账号隔离不是每个小程序都要重投入。判断标准是：同一台设备是否可能被多个微信号使用，以及本地是否存了用户维度的业务数据。两个条件满足一个，就值得做基础隔离；两个都不满足，优先级可以往后放。

• 适合做：门店导购共用手机或平板、会员系统、多微信号用户、同一设备可能切换账号、本地存购物车或草稿、涉及订单和隐私资料。
• 不必重投入：一人一机固定账号、纯展示无登录、不存用户数据、本地只存一次性 token 的轻量工具类小程序。
• 边界句：如果小程序本身没有登录态，也不在本地存任何用户维度数据，换微信号后通常不会串号，不必为了“以防万一”上一套账号分桶。
• 边界句：如果业务只允许一个微信号对应一个用户，且设备不共用，前端登录清缓存加后端按账号查询通常够用，不必做复杂的多账号数据保留。

常见问题

换微信号后，小程序必须重启才算换账号吗？

不一定。但如果不主动清缓存和重建页面栈，用户很可能仍看到旧账号数据。2026 年常见做法是登录成功后定向清理用户缓存并刷新关键页面。

只清小程序 Storage 够不够，要不要连页面栈一起清？

多数情况下不够。页面内存、全局状态和定时器也可能保留旧账号数据。清理 Storage 后，关键页面还应在 onShow 重新拉取当前账号数据。

头像变了但订单列表还是旧的，为什么？

头像通常来自用户信息接口，换账号后更新较快；订单列表若只在首次进入时请求，或本地缓存了旧列表，就不会跟着变，需要在进入或切回时重新请求。

后端按 openid 隔离就够了吗，还要不要 unionid？

看业务是否需要跨公众号、小程序识别同一个人。只在单一小程序内做数据隔离，openid 通常够用；要跨应用打通账号，再考虑 unionid。

换账号后是否串号，先按账号标识、本地缓存、页面内存、后端归属四层核对，别一上来就改登录组件。涉及订单、支付和隐私数据的，后端按当前账号过滤通常是优先项；纯展示、一人一机固定账号的小程序，可以先做登录清理，不必堆复杂方案。2026 年验收时，多账号来回切换宜列入回归清单。