全栈项目场景题
场景 1：设计一个登录系统，你会怎么做？
面试官可能这样问：
你负责从前端到后端实现登录注册系统，会怎么设计？
回答思路：
- 前端表单校验和错误提示。
- 后端校验账号密码。
- 密码加盐哈希存储。
- 使用 session 或 token 维护登录态。
- 设计刷新 token 或过期策略。
- 权限路由和接口鉴权。
- 登录失败限流和日志审计。
项目化解释：
真实项目里，登录不是一个表单加接口这么简单。前端要处理 loading、错误提示、回车提交、重复点击。后端要防止密码明文存储，要限制连续失败次数。
如果用 JWT，我会让 access token 短期有效，refresh token 长期但可撤销。前端路由权限只做体验，后端每个敏感接口都必须校验权限。
追问点：
JWT 如何主动失效？
JWT 天然无状态，主动失效需要额外机制，例如维护 token 黑名单、使用短 access token + 可撤销 refresh token、用户密码变更后更新 token 版本号。
token 存 localStorage 还是 Cookie？
localStorage 使用方便但更怕 XSS；Cookie 配合 HttpOnly 更不容易被 JS 读取，但要处理 CSRF。具体选择要看前后端架构和安全要求。
如何防暴力破解？
对登录失败次数、IP、账号、设备做限流和冷却；必要时加验证码、风险识别和告警。密码要使用安全哈希存储。
如何做单点登录？
常见方案是统一认证中心。业务系统跳转认证中心登录，登录成功后拿授权码或 token，再换取用户身份。企业场景常见 OAuth2、OIDC、CAS。
场景 2：订单列表查询很慢，你怎么优化？
面试官可能这样问：
后台订单列表越来越慢，产品还要求支持多个筛选条件，你怎么排查和优化？
回答思路：
- 先看接口耗时、SQL 慢查询和返回数据量。
- 给高频筛选字段加索引。
- 使用分页，避免一次返回大量数据。
- 只返回页面需要字段。
- 对复杂统计异步计算或缓存。
- 前端筛选条件加防抖，避免频繁请求。
项目化解释：
我会先拿一条慢请求的 requestId 查后端日志，再看 SQL 执行计划。如果发现按 status + created_at 查询很频繁，就考虑联合索引。如果返回了很多详情字段但列表只展示 8 列，就精简返回。
前端也要配合：搜索框防抖，切换筛选时展示 loading，不要让用户以为页面卡死。
追问点：
联合索引顺序怎么考虑？
一般把等值查询字段放前面，范围查询和排序字段放后面，并结合最左前缀原则。最终要用 EXPLAIN 验证执行计划。
offset 分页有什么问题？
数据量大时，offset 越靠后扫描和丢弃的数据越多，性能会变差。数据频繁变化时还可能出现重复或遗漏。
cursor 分页适合什么场景？
适合按时间、ID 等稳定顺序连续翻页的场景，例如消息流、订单列表、动态列表。它性能更稳定，但不适合任意跳页。
如何避免导出大数据拖垮服务？
导出任务异步化，限制导出范围和频率，分批查询，生成文件后通知用户下载。大导出不要在同步接口里一次性完成。
场景 3：文件上传失败率很高怎么办？
面试官可能这样问：
用户上传大文件经常失败，你会怎么设计一个更稳定的上传方案？
回答思路：
- 前端校验文件大小、类型。
- 大文件分片上传。
- 每个分片可重试。
- 后端或对象存储合并分片。
- 用文件 hash 支持秒传和断点续传。
- 展示上传进度和失败重试。
- 做权限、病毒扫描和访问控制。
项目化解释：
如果文件几百 MB，一次上传失败就要重来，体验很差。我会把文件切成多个 chunk，每个 chunk 上传成功后记录状态。网络断了之后，只需要继续传未完成的 chunk。
上传完成后由服务端校验 hash，确认文件完整，再保存 metadata。对于私有文件，不能直接给公开访问 URL。
追问点：
分片大小怎么选？
要在并发效率和失败重传成本之间取平衡。分片太小请求太多，太大失败重传成本高。可以按网络和文件大小动态选择。
秒传怎么实现？
前端计算文件 hash，上传前问后端是否已存在相同文件。如果存在且用户有权限复用，就直接创建文件记录，不再上传内容。
如何处理重复文件？
用文件 hash 做内容去重，用业务记录区分不同用户或目录下的引用。注意同 hash 文件的权限不能混用。
如何防止上传恶意文件？
限制类型和大小，校验 MIME 和文件签名，重命名存储，隔离访问域名，高风险文件做病毒扫描，禁止上传文件被当作代码执行。
场景 4：上线后接口突然 500，你怎么处理？
面试官可能这样问：
新版本上线后部分用户接口报 500，你作为全栈工程师怎么排查？
回答思路：
- 先确认影响范围和是否需要回滚。
- 查看最近发布内容。
- 根据 requestId 查后端日志。
- 看错误栈、数据库、缓存、第三方服务。
- 如果影响大，先回滚或关闭 feature flag。
- 修复后补测试和监控。
项目化解释：
线上问题先止血，不是先慢慢研究。比如发现 500 来自新字段为空导致后端异常，我会先回滚或加兼容逻辑，然后再补数据迁移和空值测试。
复盘时要问：为什么测试没发现？为什么监控没提前告警？后续要补哪些自动化检查？
追问点：
什么情况下回滚？
核心链路不可用、错误率明显升高、数据写入错误、性能严重下降且无法快速修复时应优先回滚或关闭功能开关。
如何设计 requestId？
每个请求进入网关或服务时生成唯一 requestId，贯穿前端、网关、后端、数据库日志和第三方调用。用户反馈问题时可以快速串起整条链路。
如何做灰度发布？
按用户、租户、地区、机器或流量比例逐步放量，并监控错误率、延迟、业务指标。异常时快速停止灰度或回滚。
如何避免数据库变更导致回滚困难？
数据库变更要向前兼容，先加字段再切代码，避免上线时直接删除字段或修改语义。大变更用双写、灰度读和延迟清理。
场景 5：如何从 0 到 1 做一个博客系统？
面试官可能这样问：
如果让你设计一个博客系统，你会怎么做？
回答思路：
- 前端：首页、文章列表、详情、分类、搜索、后台编辑。
- 后端：文章 CRUD、登录、权限、评论、上传。
- 数据库：用户表、文章表、分类表、标签表、评论表。
- SEO：静态生成或服务端渲染。
- 性能：缓存热门文章、图片优化、分页。
- 安全：后台鉴权、XSS 防护、评论审核。
- 部署：CI/CD、静态资源 CDN、日志监控。
项目化解释：
我会先做 MVP：文章列表、详情、后台发布。不要一开始就做复杂权限和推荐系统。等核心链路稳定后，再加搜索、标签、评论和统计。
如果博客主要是内容展示，可以优先 SSG，比如 VitePress 或 Next.js 静态生成，速度快、部署简单、成本低。
追问点：
Markdown 如何渲染和防 XSS？
Markdown 渲染后要对 HTML 做白名单过滤，禁止危险标签和属性，例如 script、事件属性和不可信链接。也可以限制只允许安全 Markdown 语法。
如何设计标签和分类？
分类通常是层级或单选归属，标签是多对多。可以设计文章表、分类表、标签表和文章标签关联表。
如何做全文搜索？
小规模可以用数据库模糊查询或前端索引，大规模可以接 Elasticsearch、Meilisearch 或 Typesense。搜索要考虑分词、权重、高亮和权限过滤。
如何统计文章访问量？
可以记录访问事件，再异步聚合 PV、UV。高访问量场景可用 Redis 计数，定期落库，避免每次访问都直接写数据库。