先声明一下立场，省得有人看完标题觉得我在阴阳谁。我特别反感那种“面了个候选人，发现对方是水货”的吐槽贴，技术面试本来就是一个双向筛选的过程，对方没准备好，可能是经验问题、可能是紧张、也可能是我们问的方式本身就有问题。但今天这个面试让我想聊的东西，恰恰不是“这个人行不行”，而是她背后的成长路径里缺了什么。
那天面的是一个工作了两年前端女生，简历上写得很漂亮，Vue、React、小程序、Node 都有涉及，项目经验也写了三四个。我问了个我自己觉得特别贴近业务的场景题：如果现在要你给一个餐饮点单小程序做登录功能，用户可以不登录先点餐，结算的时候再登录，你会怎么设计？她愣了一下，然后开始跟我聊 token 怎么存、localStorage 和 cookie 的区别、用什么加密方式。我说你先别管技术选型，你告诉我这个需求本质要解决什么问题。她想了半天，说“就是登录一下嘛，获取用户信息，然后调下单接口”。
到这里我心里基本有数了。这不是技术能力的问题，是思维方式的问题——她从来没把登录当作一个业务流程来理解过，更没想过登录状态跟购物车、订单、支付之间的状态关系。她脑子里装的是一堆零散的“知识点”，但没建立起“业务场景驱动技术设计”的脑子。
这篇文章我不想写成面试吐槽，我想认真拆一下“点单登录”这种看起来简单、实际藏了一堆坑的业务场景。不管你是刚入门的前端，还是面了好几年人的技术面试官，抑或是在做小程序、H5、后台管理系统的开发者，我相信你都能从中看到一些自己踩过或正在踩的东西。
1. 面试现场复盘：为什么一个“点单登录”能把人问懵
1.1 面试官问的真实意图是什么
先说我的提问逻辑。问一个餐饮点单场景，核心考察的是五个维度：
第一种是业务流程梳理能力。用户进店扫码、选菜加购、结算下单——这个链条里登录在哪个节点出现？是不是必须出现？强制登录和弱登录各自的影响是什么？很多人一上来就默认“登录是第一步”，但现实中大量点单场景恰恰是“先逛后登录”。
第二种是状态管理意识。游客状态下购物车是本地数据，登录之后购物车要不要同步到服务端？同步的时机是什么？按什么维度合并？如果不考虑这些，直接“用户登录后调接口拿到购物车”，那游客加了三个菜、登录后又从服务端拉了个空购物车，用户的菜就丢了。这不是技术问题，是产品事故。
第三种是异常情况处理。token 过期了怎么办？用户下单到一半session失效怎么恢复？支付回调的时候用户已经退出登录要不要紧？这些在实际开发里一定是会遇到的问题，不是“理论上可能发生”。
第四种是工程边界认知。登录不是一个孤立页面，它牵扯到用户态、请求拦截、路由守卫、全局状态、接口鉴权、数据持久化、第三方授权等等。能不能把这些点串起来，直接反映一个人平时写代码是在写“页面”还是在做“系统”。
第五种是沟通表达能力。面对一个开放性问题，是能结构化地先讲清楚主流程、再展开边界分支，还是东一榔头西一棒槌、想到哪说到哪。这个能力在真实协作里太重要了，尤其是跨端、跨团队合作。
回到那个女生。她不是没答上来，她是根本没有意识到这道题的入口在“业务分析”而不是“技术方案”。她把“点单登录”理解成一个登录页面的UI和一种token存储方式，而不是一个涉及游客态、登录态、订单状态、支付状态转换的小型状态机。
1.2 候选人简历与现场表现的反差说明了什么
她的简历上有几个项目，其中一个还写了“使用 Vuex 管理用户状态、实现 token 持久化”。按理说，她接触过用户体系，多少应该有点概念。但当我把“登录”放进一个具体业务场景里，她脑子里那些概念就全部失效了。
这就暴露了一个很普遍的学习路径问题：很多人学前端，是“照着别人的项目代码敲一遍”，而不是“从业务需求出发自己设计一套方案”。敲代码的时候你会看到别人的 store 里有一个 user 模块，里面有 token、userInfo 字段，但你不会去想为什么这些字段要放在这里、它们和订单模块有什么通信关系、用户刷新页面之后 store 里的数据怎么恢复。你只是知道“要这么写”，但不知道“为什么非要这么写”。
所以当我把场景换成一个她没做过的点单小程序，她脑子里的知识就组织不起来了。知识不是她的，只是她硬盘上的缓存。这句话糙了点，但很多人的学习状态确实就是这样。
那作为一个技术面试官，我得到的信息不是“这个人技术差”，而是“这个人没有经过真正的业务锤炼，或者锤炼了但没思考”。这两种情况都是可以培养的，但前提是候选人自己得意识到问题在哪，而不是觉得面试官在故意刁难。
2. 拆开“点单登录”这个场景：它到底藏了多少个状态管理问题
2.1 需求侧的真实流程是什么样的
用户到店，掏出手机扫桌上二维码，小程序打开就是菜单。这个时候用户什么都没做，连手机号都没授权。用户浏览菜品，加入购物车，继续逛，继续加。终于决定下单了，点“去结算”，这个时候系统要求登录——微信一键授权手机号，或者输入手机号验证码。登录成功后，刚才购物车里的东西还在，然后提交订单、发起支付、支付成功、等待上菜。
这个流程里，登录发生在“下单前”这个节点。问题来了：登录前用户已经产生了一系列行为和数据，登录这个动作不能把这些数据弄丢，也不应该把这些数据立刻陌生化。
但现实中很多开发是怎么做的？用户点结算，发现未登录，跳登录页，登录成功，返回结算页，然后前端把购物车给清了，因为“下单成功后购物车就该清空”——可这时候单还没提交成功呢。或者反过来，登录态一刷新，Vuex 里 user 信息丢了，购物车也没了，用户一脸懵。
这就是业务理解不到位造成的 bug。登录不是独立功能，它是一系列状态的中转站。你设计登录方案的时候，脑子里得有完整的用户行为链路，得知道你动了登录这个环节，会影响哪些上游状态、哪些下游状态。
2.2 登录态、游客态与购物车数据的三种关系
在点单场景里，登录前后涉及到的状态主要有三类：
第一类是用户身份态。游客态、登录态、登录态过期/失效，三个状态之间的转换是系统维护的核心。游客态下，所有用户维度数据都存在本地（或匿名sessionId标识的临时服务端存储里）；登录态下，数据才能落到用户账号维度。
第二类是购物车数据态。这里头有个很容易被忽略的点：购物车数据的归属方是“设备”还是“用户账号”。如果归属是设备，那登录前后购物车自然一致，因为你还是同一台手机；如果归属是用户账号，那登录的时候就要做一次“本地购物车/临时购物车与账号历史购物车的合并”。大多数点单场景采用的是“前段设备为主、账号为辅”的策略，但设计的时候你得主动去定义这个规则，而不是直接调接口交给后端决定。
第三类是订单状态机。草稿状态、已提交未支付、已支付、制作中、已完成、已取消。登录失败或 token 过期正好卡在提交订单和调起支付之间，这个区间状态怎么恢复、怎么保证用户不重复下单、怎么处理支付回调与订单状态的同步。这些都是典型的“边界状态”，面试时候能答出其中两三条，就已经超过相当多候选人了。
2.3 状态流转方案的一个简化设计参考
我这里提供一个极简但可落地的状态流转思路，面试里能把这个讲清楚，是很加分的：
游客态： - 用户浏览菜单 -> 加购 -> 购物车存本地（localStorage / storage key: cart_guest） - 点击结算 -> 触发登录 登录过渡态： - 登录成功 -> 拿到 token + userInfo - 检查本地临时购物车是否存在 - 存在 -> 调服务端合并接口（入参：本地购物车明细、当前账号ID，返回：合并后购物车） - 不存在 -> 拉取账号历史购物车 登录稳定态： - 购物车数据切换到服务端主数据 - 本地临时购物车标记为“已合并”并清除 - 后续所有加购、删购直接同步服务端，本地只保留一份用于快速渲染的cache这个方案不是唯一答案，但它是符合业务直觉的一种处理方式：先体验后身份，身份切换不破坏体验。
3. 为什么很多前端把“登录”理解成“token 那些事”
3.1 前端八股文对身体和思想的磨损
我不否认 token、localStorage、cookie、session 这些概念是登录功能的技术地基，但如果一个前端聊“登录”就只能聊到这一层，那说明她的技术体系是八股驱动的，用一个专业点的说法是“知识点离散，缺少结构化思维”。
现在很多前端求学者是怎么准备面试的？刷题。网上八股文一背，Vue 生命周期、diff 算法、闭包、原型链、event loop、HTTP 状态码，每个都能说两句。但面试官问“你怎么设计一个倒计时组件”“你的 webpack 打包体积太大了，排查思路是什么”“用户反馈页面在 Android 微信里打开白屏 3 秒，你怎么定位”——很多人就卡住了。
技术学习的本质不是记忆术语，而是建立“输入到输出”的因果推理能力。你拿到一个需求，能判断出它涉及哪些子系统、哪些状态需要管理、哪些边界情况需要兜底、哪些异常路径需要演练。这个能力不是背出来的，是做出来的，是踩坑踩出来的，是看别人代码问“为什么这么写”问出来的。
3.2 一个优秀的登录方案应该回答哪些问题
如果有人问我“你会怎么做登录”，我期待的答案不是某个框架的 API，而是这样一组问题的逐个回答：
业务侧：登录发生在哪个节点？如果不登录能不能完成核心闭环？登录的转化入口在哪？第三方登录和手机号登录如何取舍，为什么？
技术侧：登录态用什么标识？前端存储还是 httpOnly cookie？刷新页面后登录态怎么恢复？接口 401 后是全局跳登录页还是弹窗提示？连续多个请求同时 401 怎么避免重复弹窗？退出登录要不要清本地缓存、要不要通知其他模块？
安全侧：token 泄漏风险怎么控制？是否需要 refresh token？敏感接口要不要二次校验？前端如何防止抓包重放？
协作侧：登录状态由前端管还是由后端下发？多端（小程序+公众号H5+App）登录态如何打通？前后端接口约定有哪些字段？
这些问题不是一张试卷的题目，它们就是日常开发中真刀真枪要处理的细节。能主动把这些未知问题找出来的人，才是真正在“做工程”，而不是在“写页面”。
4. 一个真实场景里的登录方案设计与实现思路
我拿一个我之前帮朋友改造过的点单小程序为例，讲讲一个相对完整的登录方案需要怎么拆解、落地要踩哪些坑。
4.1 场景描述与初始约束
项目背景：一个线下连锁餐饮品牌要做扫码点单，现有系统是公众号H5和一个小程序，后端是一个老系统，接口鉴权全靠一套老 token 方案，没有 OAuth 的概念。需求是：不强制登录先点菜，结算时若未登录则引导绑定手机号。
一开始找的开发给的方案就是简简单单的“登录页 + 调接口存 token”。结果上线第一天就出问题：A 用户手机点完菜没支付，锁屏了一会儿，回来 token 过期，结算页刷新变成了新用户，购物车是空的，用户直接骂街。
这就是典型的安全与体验的平衡问题：token 设太长容易被人偷，设太短用户菜都没点完就被踢下线。对点单场景这种低强交互的应用来说，体验优先程度远高于安全强度，所以不能拿着一个通用后台管理系统的会话策略去套它。
4.2 方案要点拆解与关键技术决策
我最终采用的方案大概有这么几个关键点：
登录动作位置后移，不做全局强制。小程序的首页、菜品列表、菜单详情、购物车页面，全部不需要登录。只有点击“去结算”时才判断登录态。
购物车数据采用“本地优先、服务端同步”的混合策略。游客状态下购物车只存本地缓存；登录状态下，读接口去拉服务端购物车；登录过渡时，前端把本地车合并进服务端，后端返回合并结果。为了让用户感知不到这个过程，页面停留在结算页，等合并完成再渲染。
// 登录成功后触发购物车合并，是一个极简示意 async function onLoginSuccess(userInfo) { const localCart = storage.get('cart_guest') || [] if (localCart.length > 0) { const mergedCart = await api.mergeCart({ userId: userInfo.id, items: localCart.map(i => ({ skuId: i.skuId, count: i.count })) }) store.commit('cart/set', mergedCart) storage.remove('cart_guest') } else { const remoteCart = await api.fetchCart() store.commit('cart/set', remoteCart) } }会话刷新用“静默 refresh + 失败重登”，不做全局 401 跳转。小程序里 wx.login 能拿到临时 code，用 code 去后端换 token 的问题在于 code 是一次性的，所以我会在请求拦截器里做一层“当前 token 是否过期”的判断，如果过期就尝试用自定义的 refreshToken 去刷新，刷新成功把新 token 存下来重发请求；刷新失败才走“需要登录”的逻辑。这样可以避免用户点个结算被弹出去登录页的尴尬，也避免多个并发请求同时 401 导致弹出多个登录框。
退出登录不只是清 token。我见过有团队做退出登录就调一个接口把 token 删了、前端 store 清一下，结果购物车也没了。这里必须区分：退出的是登录态，但用户在这台设备上的本地偏好、本地临时数据是否清除，是需要单独定义的业务规则，不是技术规则。
4.3 前端代码层面的防坑实操
这段代码层面我觉得值得给出一个可复用的防坑清单：
坑一：并发请求同时 401。用户一次性进结算页，页面里可能同时发出三个请求：获取收货地址、获取购物车、获取优惠券。如果这三个请求同时返回 401，你的拦截器可能就会同时触发三次登录。解法是做一个全局的 isRefreshing 锁：
let isRefreshing = false let pendingQueue = [] async function handleUnauthorized(originalRequest) { if (!isRefreshing) { isRefreshing = true try { const newToken = await refreshToken() pendingQueue.forEach(cb => cb(newToken)) pendingQueue = [] originalRequest.headers.Authorization = `Bearer ${newToken}` return request(originalRequest) } finally { isRefreshing = false } } else { return new Promise(resolve => { pendingQueue.push(newToken => { originalRequest.headers.Authorization = `Bearer ${newToken}` resolve(request(originalRequest)) }) }) } }坑二：登录返回后页面状态需要恢复。小程序 pages 之间跳转，登录页通常是通过navigateTo跳过去的，用户登录成功后应该navigateBack回来，而不是重新redirectTo到首页。很多人习惯登录成功就跳首页，这在电商场景会吞掉用户正在做的事情，很伤体验。
坑三：token 持久化的存储键名不要写死。一个团队可能有多个项目，每个项目的用户登录态存储键名如果都叫token，混合开发时（比如同一个 webview 里既有主业务又有子模块）容易冲突。建议用“项目名 + 环境 + 用途”的方式：[project][env][feature]。
4.4 后端协作中的关键约定
不用后端配合纯前端把登录做完，是不可能的事。至少这几个接口设计是前端要主动推动的：
会话刷新接口：要求后端支持 refreshToken 机制，或者至少提供一个“旧 token 换新 token”的接口。没有这个，前端只能被动等 401，体验会断。
合并购物车接口：要求后端能接受一个“游客购物车明细数组 + 账号ID”入参，内部完成与账号历史数据合并。没有这个接口，合并逻辑就得前端做，会非常痛苦。
接口鉴权统一返回语义：要求后端在 session 失效时返回统一的 code（比如 401），而不是有的接口返回 200 但 errorCode 是 10086，有的接口直接返回 500。不统一的话前端拦截器会写得像一团乱麻。
我强烈建议前端同学在日常工作里主动去和后端同学过一次你们接口的异常返回约定，把“前端怎么判断 session 失效”“401 之后什么时机刷新”这些问题落实到文档上。这比你自己刷再多的状态管理题都管用。
5. 面试官与候选人视角：从“点单登录”看真实能力模型
5.1 面试官应该怎么问才能问到真东西
文章看到这里的读者有不少应该也是技术面试官或者即将开始面试别人的人。我自己也反思过，一道开放场景题如果引导不当，很容易变成考官单方面输出，最后还怪候选人不行。
我的建议是：问场景题的时候，分阶段给提示，观察对方在提示下的反应速度和学习能力，而不是指望对方一口气答出一份完整方案。
比如：
- 第一问：用户不登录可以点单吗？你会把登录节点放在哪里？
- 第二问：游客加了三个菜，登录成功后购物车怎么处理？
- 第三问：如果支付到一半 token 过期了，你怎么设计恢复策略？
- 第四问：你这个方案里，前后端接口需要做什么配合？
这四个问题难度是递进的，从业务直觉到状态管理到异常处理到跨端协作，正好形成一个完整的能力光谱。对方卡在中间某一层不可怕，怕的是第一层就想不明白——那不是经验问题，是压根没在做业务。
5.2 候选人该怎么准备这类场景题
如果你是一个准备面试的前端同学，看到这篇文章，我希望你能理解一个重要的观点：面试官问一道题，不是在考它本身，而是在看你脑子里对象的结构。
波音“点单登录”这种题也有类似价值。它看起来简单，非常适合用来探测你的系统思维。所以准备的方向不是去背“点单登录的标准答案”，而是建立一套分析任意业务场景的通用框架：
拿到一个需求，先问自己五个问题——
- 核心业务主流程是什么样的？
- 主流程里的关键状态有哪些？
- 状态之间如何转换、由什么触发？
- 每一步可能出现的异常情况有哪些？
- 我的方案里，哪些是前端职责、哪些需要协作方配合？
这五个问题想清楚了，哪怕你没做过点单，你也能把一个超市自助收银、一个预约挂号、一个二手交易流程说得有逻辑、有层次。
5.3 这个场景题背后真正考核的能力排序
我后来跟几位同行聊过这个面试题，大家基本认可一个能力排序：
第一等：业务理解力。能不能清晰讲出“这个系统为谁解决什么问题、核心闭环是什么”。第二等：状态抽象能力。能不能从纷繁的功能点里抽出关键状态和转换关系。第三等：边界意识。能不能主动想到异常流程、失败补偿、数据一致性。第四等：技术实现力。在确定方案后，能不能熟练落地。第五等：协作沟通力。能不能把你的方案讲给别人听、并能反向驱动后端或产品完善设计。
排在这个序列里，你再回头看那个面试女生的问题——她展示出来的是第四等能力的一部分，而第一、第二、第五等都很弱。这不是“技术不行”，而是认知层级还停留在“完成任务”而不是“理解系统”的阶段。
但我真不觉得这是她一个人的问题。很多刚入行的前端，包括我自己刚工作那阵子，也是这样的。每天被排期推着走，拿到设计稿就开始写样式调接口，很少停下一秒问一句：我写的这个页面，在整个业务流程里起到什么作用？它跟前后页面之间的状态是怎么衔接的？
如果说这篇长文有唯一一个我特别想传达的体会，就是这个：做前端，不要只做一个“把设计稿变成页面”的人，要做一个“把业务问题变成技术方案”的人。你代码写得快、样式写得好是加分项，但能看懂业务漏洞、能推理边界条件、能把一团乱麻的需求捋成清晰的状态流，才是让你从“能干活”跨越到“值钱”的那道门槛。
6. 从面试现场延伸出去的非技术向杂谈
6.1 面试官也有局限
这里说点偏题但值得一想的内容。
面试其实只能采到一个人真实能力的非常小的截面。一个人在一个小时的对话里发挥失常，有太多可能的原因了：也许她昨天加班到凌晨，也许她对这个公司本来就没那么想去，也许她只是被我的提问方式绕晕了。所以我不支持那种“面了一个xxx，直接判死刑”的风气，更反感拿一次面试表现去嘲笑一个人的专业能力。
但反过来，对候选人来说，每次都把面试发挥不好归因到“状态差”也不解决问题。如果你发现自己连着几场面试都被类似的题目卡住，那就该想想这背后是不是有一个被自己忽略的知识盲区了。技术面试这种场景，对很多人来说就是压力测试，既然是压力测试，就更值得在面试前认真做几轮故意的、刻意的复盘。
6.2 什么样的前端面试题才算好题
我自己这几年做过大量面试，逐渐总结出一个观点：好的面试题永远是“看门狗型”的，它要能迅速区分出“见过”和“经历过”。很多八股题只能筛出“背过”，区分不了“经历过”。而场景题的好处是它的答案没有唯一标准，却能暴露出你脑子里是否沉淀过真实的决策过程。
比“点单登录”复杂得多的场景题我也出过，比如“让你设计一个地铁路线规划页面的实时刷新策略”“一个视频评论区在高并发弹幕下怎么做限流失控”，这类题我在不同人身上拿到的答案能差出好几个等级。但简单题也未必没价值，关键是你怎么引导、怎么追问、怎么从浅层回答里继续挖。
6.3 写给那些正在成长的前端：把接口、状态、场景焊在一起
说了这么多，该收个尾了。
如果你刚好是那个类型——技术基础打得还行、但面对业务需求时总有一种“大概知道怎么做却又说不清楚为什么”的感觉，那我劝你接下来的工作里重点做三件事：
第一，每接一个需求，先写一段“业务理解”给自己看。用文字把主流程、关键状态、边界分支写清楚，再开始写页面。哪怕不发给别人，只是自己梳理，也会帮你发现很多“做了但没想过”的盲区。
第二，遇到问题不要只搜“报错信息”，要学会搜“场景关键词”。比如搜“点单 购物车 合并 登录 token”，你会看到大量真实开发者踩坑记录，这些内容比语法手册价值高得多。
第三，多参与面试，但不是为了跳槽，是为了做“认知体检”。哪怕不通过，面试官问你的那些你没答好的问题，就是你当前能力地图上的空白区。把这些空白区记下来，逐个拆解补全，比闷头刷技术书快得多。
最后再分享一句我在带团队时经常跟新人说的话：编程语言和框架只是你的表达工具，真正的产品是在这些工具背后流动的数据和状态。你工具很熟值得高兴，但别把工具本身当成了目的。想通这一点，类似“点单登录搞不清”的尴尬，就会越来越少了。
