面试官问："用户 token 应该存在哪？"很多人脱口而出：localStorage。这个回答不能说错，但远称不上好答案。一个好答案，至少要说清三件事：有哪些常见存储方式，它们的优缺点是什么为什么大部分团队会从 localStorage 迁移到 HttpOnly Cookie实际项目里怎么落地、怎么权衡「安全 vs 成本」这篇文章就从这三点展开，顺便帮你把这道高频面试题吃透。三种存储方式，一张图看懂差异前端存 token，主流就三种：localStorage：用得最多，但也最容易出事大部分项目一开始都是这样写的，把 token 往 localStorage 一扔就完事了： ...

给了超出预期的包，还是非常满意的，比快手还要高出一截，终于结束秋招了啊虽然感觉后面的路依旧很难走但也要一步一步慢慢来了祝大家顺利也祝自己顺利

面完试，HR 给我来一句：“感谢你的时间。”我瞬间懂了——这不是感谢，这是抢救。他们怕我还抱着希望，所以特地提前拔管。五个字，看似温柔，实则比“你不合适”还坚决：连“我们会再联系你”的假话都懒得编，连“本次流程已结束”的敷衍都不愿意给，礼貌值满分，诚意值清零。你能感受到一种独特的企业文化：贴心地把话讲死，体面地把人挂掉。面试失败的最高礼仪，就是不浪费彼此时间。

三、核心技术场景考察及候选人表现（一）考察场景高并发秒杀场景：1 万人同时抢购 100 个库存的商品，要求保证用户体验、系统稳定性与扩展性（二）候选人方案及面试官质疑候选人核心方案：前端先获取 token（通过 Lua 脚本实现锁机制），再凭 token 下单；后续考虑通过 MQ 异步处理、库存分片等方式优化面试官核心质疑点超卖与少卖风险：Lua 脚本仅解决锁竞争问题，下单环节的复杂逻辑（风控等）可能导致下单失败，已分发 token 会造成少卖；锁机制无法完全避免超卖系统扩展性不足：面对 1000 万人抢 1 万个商品的场景，数据库难以承载高并发读写，token 机制与数据库扛压能力不匹配异步...