面试题库生成器：分类/难度/考察点/参考答案/评分标准
输入岗位 JD/技术栈/能力模型，输出结构化面试题库：分类、难度、考察点、标准问题、追问引导、参考答案、评分细则、红旗信号
提示词
你是资深面试官与题库设计专家。任务：为岗位生成专业、可复用、可评分的面试题库，支撑标准化面试、减少主观偏见。
约束：
- 题库结构：
- 分类：技术硬技能、系统设计、行为/软技能、领域知识、编码实战、价值观/文化
- 每题含：题目、难度(L1-L3)、考察点、标准回答要点、追问引导(3 层)、评分细则(1-5 分)、红旗信号、优秀/及格/不及格示例
- 覆盖度：每分类≥5 题，总题数≥30 题，支持按岗位级别筛选
- 编码题：含完整题目描述、输入输出示例、约束条件、参考解法、复杂度分析、常见坑、变体扩展
- 系统设计题：含需求澄清清单、架构图要素、核心组件、权衡决策、扩展性/可用性/一致性考量、容量估算
- 行为题：STAR 原则、追问模版、能力指标映射
- 输出：Markdown 题库文档 + JSON 结构化（ATS/面试工具导入）+ 面试官使用手册
输出格式：
面试题库：{岗位名称} v{版本}:
使用说明:
- 面试时长：60 min = 1 编码 + 1 系统设计 + 2 行为 + 1 价值观
- 评分：各题 1-5 分，加权总分 ≥ 3.5 通过
- 红旗：出现 1 个红旗信号直接降级或挂起
题库总览:
| 分类 | 题数 | 难度分布 | 权重 |
|---|---|---|---|
| 技术硬技能 | 8 | L1×3, L2×3, L3×2 | 25% |
| 系统设计 | 3 | L2×2, L3×1 | 25% |
| 编码实战 | 2 | L2×1, L3×1 | 20% |
| 行为/软技能 | 6 | L1×2, L2×3, L3×1 | 15% |
| 领域知识 | 4 | L1×2, L2×2 | 10% |
| 价值观/文化 | 3 | L2×3 | 5% |
分类题目详情:
技术硬技能:
Q1: Go 语言 - 调度器原理 (L2):
题目：简述 Go 调度器 GMP 模型，为何要引入 P？
考察点：GMP 理解、调度触发时机、系统监控、抢占式调度
标准回答要点：
- G-M-P 三元关系：G=Goroutine, M=OS线程, P=逻辑处理器(资源)
- P 的作用：本地运行队列、内存缓存、调度决策单元
- 调度触发：syscall、channel、time.Sleep、runtime.Gosched、GC、抢占信号
- 系统监控：netpoller、sysmon 抢占长时间运行 G
追问引导：
- L1：Goroutine 与线程区别？
- L2：为何要抢占式调度？非抢占会怎样？
- L3：设计一个高优先级任务插队机制怎么做？
评分细则：5=完整阐述 GMP+抢占+sysmon；4=GMP 清楚但抢占模糊；3=仅知 G/M/P 概念；2=混淆协程/线程；1=完全不会
红旗：认为 Goroutine 就是线程、不知抢占、把 channel 当锁用
优秀示例：能画出 GMP 状态流转图、说出 sysmon 10ms 监控周期
少样本示例
展示完整题库结构、6大分类、每题含考察点/追问/评分/红旗、系统设计含需求澄清/架构/权衡/容量、编码题含约束/解法/坑/变体
输入
岗位：高级后端工程师 - 用户增长方向 (L3/L4)
技术栈：Go、gRPC、MySQL、Redis、Kafka、K8s
核心能力：高并发分布式系统、存储优化、观测排障、工程文化
输出
面试题库：高级后端工程师-用户增长方向 v1.0:
使用说明:
- 面试时长：60 min = 1 编码(20min) + 1 系统设计(20min) + 2 行为(15min) + 价值观(5min)
- 评分：各题 1-5 分，加权总分 ≥ 3.5 通过，技术硬技能/系统设计/编码权重各 25%/25%/20%
- 红旗：出现 1 个红旗信号直接降级或挂起，需面试官书面记录理由
题库总览:
| 分类 | 题数 | 难度分布 | 权重 |
|---|---|---|---|
| 技术硬技能 | 8 | L1×3, L2×3, L3×2 | 25% |
| 系统设计 | 3 | L2×2, L3×1 | 25% |
| 编码实战 | 2 | L2×1, L3×1 | 20% |
| 行为/软技能 | 6 | L1×2, L2×3, L3×1 | 15% |
| 领域知识 | 4 | L1×2, L2×2 | 10% |
| 价值观/文化 | 3 | L2×3 | 5% |
分类题目详情（节选）:
技术硬技能:
Q1: Go - 内存逃逸分析与优化 (L2):
题目：什么是内存逃逸？如何通过编译器标志定位？举 3 个常见逃逸场景及优化。
考察点：逃逸原理、-gcflags=-m 使用、场景识别、优化手段
标准回答要点：
- 逃逸：本应在栈上分配的变量跑到堆上，增加 GC 压力
| 2. 定位：go build -gcflags=-m=2 2>&1 | grep -E "escapes | moved to heap" | - 常见场景：
- 指针逃逸：返回局部变量指针、闭包引用外部变量
- 接口逃逸：interface{} 存具体类型、fmt.Println 类函数
- 切图/Map 扩容逃逸：make 容量不足、append 超容量
- 优化：预分配容量、值传递替指针、对象池 sync.Pool
追问引导：
- L1：栈与堆区别？
- L2：逃逸一定不好么？何时可接受？
- L3：如何在不改业务逻辑前提下，通过编译器指导优化逃逸？
评分细则：5=原理+工具+3场景+优化；4=原理+工具+2场景；3=知原理会工具；2=仅知概念；1=完全不会
红旗：认为逃逸只与指针有关、不知 -gcflags、说「用对象池解决所有逃逸」
Q2: MySQL - 索引失效场景与排查 (L2):
题目：列举 5 个导致索引失效的场景，如何用 EXPLAIN 验证？
考察点：B+ 树原理、最左前缀、隐式转换、函数操作、不等于/范围查询、EXPLAIN 关键列
标准回答要点：
- 违反最左前缀：联合索引 (a,b,c) 查询 where b=1
- 隐式类型转换：varchar 字段 where id=123(数字)
- 索引列运算：where DATE(create_time)='2025-01-01'
- 否定/不等于：where status!=1、where id>100 范围过大
- OR 条件未全索引：where a=1 OR b=2 (b 无索引)
- EXPLAIN 看：type=ALL/key=NULL/rows 偏大/Extra=Using where
追问引导：
- L1：什么是回表？
- L2：覆盖索引如何避免回表？
- L3：千万级表加索引如何不锁表？
评分细则：5=5场景+EXPLAIN 关键列；4=4场景+EXPLAIN；3=3场景；2=1-2场景；1=不会
红旗：认为加索引总是好、不知覆盖索引、线上直接加索引不考虑锁表
系统设计:
Q1: 设计支持 10w QPS 的用户登录系统 (L3):
题目：设计日活 5000 万、登录峰值 10w QPS 的用户登录系统，要求高可用、低延迟、防刷、可审计。
需求澄清清单：
- 登录方式：账密/手机验证码/三方 OAuth/单点登录
- 安全：密码加密/验证码频控/设备指纹/风控引擎
- 会话：Token 类型/过期/刷新/多端踢下线/单点登出
- 审计：登录日志/异地登录告警/合规留存
- 非功能：P99<200ms、可用性 99.99%、数据一致性/最终一致性
架构要素：
- 接入层：Nginx/网关 → 限流/熔断/路由/协议转换
- 网关层：鉴权/路由/聚合/协议适配
- 登录服务：无状态、水平扩展、读写分离
- 缓存层：Redis Cluster 存 Session/验证码/设备指纹/风控缓存
- 数据层：MySQL 主从/分库分表(user_id 取模)/只读实例
- 消息队列：Kafka 异步写登录日志/风控事件/审计日志
- 风控引擎：规则引擎+ML 模型，实时拦截/挑战/封禁
核心权衡：
- 强一致 vs 高性能：登录核心路径走 Redis，异步落库 MySQL
- 安全 vs 体验：风控异步不阻塞主流程，高风险二次验证
- 扩展性：无状态服务+分片缓存+分库分表，水平线性扩展
容量估算： - Redis: 5000 万用户 × 500B Session ≈ 25GB，集群 6 分片
- MySQL: 5000 万 × 1KB ≈ 50GB，分 32 表，单表 1.5GB
- Kafka: 10w QPS × 1KB × 86400s ≈ 8.6TB/天，保留 7 天
追问引导： - L1：如何防止密码撞库？
- L2：验证码服务如何抗刷？
- L3：多机房异地多活如何做会话同步？
评分细则：5=完整架构+容量+权衡+追问深度；4=架构完整+容量估算；3=基础架构+关键组件；2=仅画图无细节；1=无法展开
红旗：单点数据库、无限流、无风控、密码明文、Session 存在本地内存
编码实战:
Q1: 实现一个线程安全的 LRU 缓存 (L2):
题目：用 Go 实现支持并发的 LRU Cache，接口：Get(key) (value, ok)、Put(key, value)、Delete(key)、Len()、Cap()。要求 O(1) 时间复杂度。
约束：
- 并发安全、无锁或细粒度锁
- 内存友好、无内存泄漏
- 支持过期淘汰（可选加分）
参考解法要点：
- 双向链表 + HashMap：链表维护访问顺序，Map 快速定位
- 读写锁分离：Get 读锁，Put/Delete 写锁，或分段锁
- 淘汰：尾部节点移除，Map 同步删除
- 过期：延迟删除+定时扫描，或时间轮
复杂度：Get/Put/Delete 均 O(1)
常见坑：
- 并发下链表断裂/环路
- 过期清理导致锁竞争
- 内存泄漏：删除节点未置 nil、闭包引用
变体扩展：LFU、ARC、支持 TTL、分布式缓存一致性
评分细则：5=完整实现+并发安全+测试用例+基准测试；4=完整实现+并发安全；3=单线程版正确；2=逻辑有bug；1=不会
红旗：用切片实现 O(n)、全局大锁、无并发考虑、内存泄漏
行为/软技能 (STAR 原则):
Q1: 讲一个你主导的最复杂的技术重构项目 (L2):
题目：描述一个你主导的技术重构项目，背景、目标、你的角色、关键决策、结果、复盘。
考察点：项目复杂度、技术判力、推动力、结果导向、复盘深度
追问引导 (STAR)：
- Situation：什么背景？为什么必须重构？不重构后果？
- Task：你的具体目标？如何拆解？如何评估风险？
- Action：你做了什么？如何说服干系人？如何平衡业务与重构？关键技术决策？
- Result：量化结果？性能/稳定性/效能提升多少？业务影响？
- Reflection：最大教训？若重来会怎么做？如何沉淀为团队能力？
能力指标映射： - 技术判力：方案选型合理性、权衡清晰度
- 推动力：跨团队协作、阻力化解、资源争取
- 结果导向：量化指标、业务价值、交付节奏
- 成长性：复盘深度、方法论沉淀、他人赋能
评分细则：5=复杂度高+量化结果+深度复盘+方法论沉淀；4=复杂度高+量化结果+复盘；3=有重构经验+基本结果；2=参与过但非主导；1=无相关经验
红旗：只谈技术不谈业务、无量化结果、甩锅他人、无复盘、方案选型无权衡
价值观/文化:
Q1: 如果发现团队采用的技术方案有明显缺陷，但大家都不想改，你会怎么做？ (L2):
题目：某核心服务用了 3 年的旧框架，性能瓶颈明显、维护成本高，但团队习惯了、不愿重构，你怎么推动？
考察点：影响力、换位思考、数据驱动、循序渐进、心理安全感
标准回答要点：
- 先收集数据：性能基准、故障记录、维护工时、招聘阻力、竞品对标
- 找盟友：技术领袖、受苦最深的同事、业务方
- 小步试错：选非核心模块试点、对比数据、建立信心
- 降低门槛：封装迁移工具、写最佳实践、结对编程、导师制
- 激励对齐：纳入 OKR、技术债偿还可视化、技术分享荣誉
- 兜底方案：双轨并行、灰度发布、一键回滚、止损线
追问引导：
- L1：如何量化「维护成本高」？
- L2：如果 VP 不支持重构，你怎么办？
- L3：如何避免「为了重构而重构」？
评分细则：5=数据驱动+盟友+试点+降低门槛+激励+兜底；4=数据+试点+激励；3=有想法但缺落地；2=只会抱怨；1=放弃或强推
红旗：抱怨不作为、强推不顾业务、无数据支撑、不顾团队感受、搞「大爆炸」重构