豹趣科技服务端研发一面：项目深挖与系统设计

《面试题目》

1. 实习里的数据权限重构是怎么做的？为什么选择在 SQL 查询层做数据权限控制？
2. 大创项目团队怎么分工？为什么你是负责人？从用户视角介绍一下完整业务流程。
3. 项目有没有真实落地？医院实际使用后遇到过哪些问题？最严重的三个是什么？
4. 蓝牙连接不稳定具体是什么原因？
5. 介绍一下项目后端整体架构、数据模型、核心表及关键字段。
6. 目前系统是单节点，如果用户从几百增长到全国规模，需要做哪些改造？单节点扩展到多节点有哪些问题？
7. 前端重复提交导致数据库出现重复记录，怎么保证接口幂等？本地锁有什么问题？多节点下怎么办？
8. AI Coding 在项目中占多少？作为服务端开发，使用 AI Coding 时需要给 AI 哪些特殊的上下文和约束？
9. 十亿级用户表设计：邮箱 + 密码登录，单表扛不住以后怎么分库分表，同时保证登录时能快速定位数据？
10. 多租户百万级数据异步导出：要求能查看导出进度，大租户不能影响其他租户，怎么遍历百万级数据、生成文件并提供下载？
11. 并发扣积分：两个请求同时扣 7 分，如何通过数据库保证积分不会扣成负数？
12. 求职方向、央国企和互联网怎么考虑？

《参考解析》

接口幂等：本地锁只在单进程内有效，多节点部署后两个请求会落到不同实例，锁形同虚设。真正的幂等要在数据层收敛：一是业务唯一键 + 数据库唯一索引，重复插入直接失败；二是客户端携带幂等 token（前端进入提交页时向后端申请），服务端用 Redis SETNX 抢占并设置短 TTL，同一个 token 第二次请求直接返回首次结果；三是状态机式更新，如 UPDATE ... WHERE status='待处理'，靠受影响行数判断是否抢到。前端按钮置灰只是体验优化，不能当幂等手段。

十亿级用户表分库分表：邮箱登录的关键是「按什么分片、能不能路由」。常见做法是加一列 email_hash = crc32(lower(email))，按 hash 取模分 N 库 M 表，登录时先算 hash 直接定位分片，避免全库扫。同时要处理热点与扩容：一致性哈希或预分片（先分 1024 个逻辑分片再映射到物理库）能让扩容只搬部分数据。邮箱注册还要考虑大小写、别名归一化，唯一性校验靠全局唯一索引或单独的邮箱映射表。

多租户百万级数据异步导出：同步导出必然超时，应改成任务制——请求落库生成导出任务（租户、条件、状态、进度、文件地址），后台线程池或消息队列消费。遍历百万级数据用游标分页（按主键 WHERE id > last_id ORDER BY id LIMIT N）或流式游标，避免深分页 OFFSET。租户隔离靠两件事：每个租户独立队列/配额，以及线程池按租户维度限流，大租户最多打满自己的配额，不挤占别人。进度用「已处理行数 / 总行数」写回任务表，前端轮询或推送；文件写对象存储并给带签名的临时下载链接。

并发扣积分：核心是让数据库来做原子判断。写法一：UPDATE points SET balance = balance - 7 WHERE user_id = ? AND balance >= 7，受影响行数为 0 就说明余额不足，天然防负。写法二：乐观锁版本号 UPDATE ... WHERE version = ?，失败重试。写法三：SELECT ... FOR UPDATE 悲观锁把行锁住再算，适合后续逻辑复杂的场景。无论如何都不能「先查余额、再判断、再更新」，那是典型的检查-使用竞态。

给 AI Coding 的上下文与约束：项目特有的东西必须显式喂进去——目录结构与分层约定、数据模型和表字段含义、内部 SDK 与工具类的正确用法、错误处理与日志规范、既有代码风格。约束上要明确「不要新增依赖」「不要改数据库 schema」「不要动公共接口签名」这类边界，并要求它先给出改动计划再落地，最后靠编译、类型检查和测试兜底。评价标准是「AI 写的代码是否和团队现有代码长得一样」，上下文给得越准，返工越少。