技术决策情景题 🔧

技术选型、架构设计、技术债务的高分回答指南

场景一：选型 React 还是 Vue

📌 场景描述

新项目启动，你作为技术负责人，需要决定用 React 还是 Vue。你怎么做这个决策？

🎯 面试官考察点

技术判断力
决策依据是否充分
是否考虑团队因素
能否推动落地

✅ 高分回答

结构化总览：

我会分四步来做决策：明确评估维度 → 对比分析 → 结合团队情况 → 推动落地

第一步：明确评估维度

不要上来就说"我觉得 React 好"，先建立评估标准：

评估维度	考量点
业务场景	项目类型、复杂度、交互丰富程度
团队因素	团队技术栈熟悉度、学习成本
生态支持	组件库、工具链、社区活跃度
招聘市场	人才储备、招聘难度
长期维护	框架稳定性、升级成本
现有资产	是否有可复用的代码/组件

第二步：对比分析

React vs Vue 核心差异（前端视角）：

维度	React	Vue
学习曲线	较陡（JSX、Hooks 概念多）	较平缓（模板直观）
灵活性	高（自由度大，但规范靠团队）	中（官方提供全家桶）
生态	最丰富（组件库、状态管理多）	成熟（官方生态统一）
类型支持	TS 支持优秀	Vue3 TS 支持改善很多
大型项目	更常见于大厂复杂项目	中小型项目更快启动
国内生态	很好	非常好（国内社区活跃）

面试加分点：

两个框架从能力上讲都能满足绝大多数场景，差异更多在于团队和生态，而不是技术本身。

第三步：结合团队情况决策

实际决策往往取决于：

markdown

## 优先选 React 的情况
- 团队已有 React 经验
- 项目需要对接大量 React 生态（如 Ant Design）
- 追求最大灵活性和可控性
- 招聘市场 React 人才更多

## 优先选 Vue 的情况
- 团队 Vue 经验更丰富
- 快速启动、快速交付
- 需要完整官方解决方案
- 团队新人多，学习成本要低

示例话术：

从技术上看两者都能满足需求。但考虑到我们团队 80% 的人更熟悉 React，而且我们有沉淀的 React 组件库可以复用，选 React 可以减少学习成本和开发周期。

第四步：推动落地

做完选型不是结束：

markdown

## 落地步骤
1. **文档输出**：写选型决策文档，记录选择理由
2. **规范建立**：目录结构、代码规范、组件规范
3. **基础设施**：脚手架、CI/CD、Lint 配置
4. **培训支持**：对不熟悉的成员提供学习资源

💡 收尾金句

技术选型没有绝对的对错，关键是选择有依据、考虑了团队因素、能够落地执行。选择后坚定执行，比反复纠结更重要。

场景二：项目有大量技术债务什么时候还

📌 场景描述

项目积累了大量技术债务，代码质量差、扩展困难。领导问你要不要还债、什么时候还。

🎯 面试官考察点

技术债务认知
长短期权衡能力
ROI 思维
沟通能力（技术话题用业务语言）

✅ 高分回答

结构化总览：

我会分三步处理：评估债务影响 → 制定还债策略 → 推动执行

第一步：评估技术债务影响

先搞清楚债务的严重程度：

评估维度	问题
开发效率	改一个功能要改多少地方？
线上稳定性	是否频繁出 Bug？
新人上手	新人要多久才能独立开发？
扩展成本	新需求实现难度有多大？
安全风险	是否有安全隐患？

债务分类：

类型	例子	影响
高危债务	安全漏洞、数据风险	必须立即处理
阻塞债务	每次开发都受影响	尽快处理
累积债务	代码风格混乱、缺少注释	渐进处理
可接受债务	不影响开发、暂时 work	暂时搁置

第二步：制定还债策略

常见策略对比：

策略	适用场景	风险
大重构	债务严重、有重构窗口期	周期长、风险高
渐进重构	业务持续迭代、无专门时间	周期长但可控
随需求还	每次开发时顺手优化	覆盖面有限
技术专项	专门排期处理某类债务	需要资源支持

推荐策略：渐进重构 + 技术专项结合

markdown

## 渐进重构原则
- **Boy Scout Rule**：每次提交让代码比之前更好一点
- **随需求重构**：做到哪里就优化到哪里
- **不做无关重构**：只重构和当前需求相关的部分

## 技术专项处理
- 识别影响最大的债务（用数据说话）
- 单独立项，明确收益和验收标准
- 和业务需求一起排期

第三步：如何说服领导给资源

关键：用业务语言讲技术问题

错误示范：

❌ "代码写得太烂了，必须重构"
❌ "技术债务很多，需要时间还"

正确示范：

markdown

## 用数据说话

1. **效率数据**
   "同样的需求，以前 3 天，现在要 7 天，因为要处理历史包袱"

2. **稳定性数据**
   "过去一个月 5 次线上问题，3 次和老代码有关"

3. **人力成本**
   "新人上手要 2 个月，是行业平均的 2 倍"

4. **给出 ROI**
   "投入 2 周重构 XX 模块，后续每个需求可以节省 2 天"

示例话术：

目前技术债务主要影响开发效率，同类需求的开发时间比半年前多了 50%。我建议用 2 周时间做一次核心模块重构，预期可以把这类需求的开发时间降低 40%。后续用渐进方式持续优化。

💡 收尾金句

技术债务就像信用卡，借的时候爽，利息会越滚越多。我会用数据让领导看到"不还债"的成本，推动合理排期。

场景三：是否要引入新框架或工具

📌 场景描述

团队有人提议引入新框架/工具（如 TailwindCSS、Zustand、TanStack Query），你怎么评估？

🎯 面试官考察点

技术评估能力
收益风险判断
团队视角

✅ 高分回答

结构化总览：

我会从四个维度评估：解决什么问题 → 收益评估 → 风险评估 → 落地成本

第一步：明确要解决什么问题

先问"为什么"：

markdown

## 引入新工具的常见原因
- 现有方案有明确痛点
- 新工具效率更高
- 社区/行业趋势
- 技术尝鲜（要警惕这个）

## 要回答的问题
- 现有方案的痛点是什么？
- 不引入能否解决？
- 解决这个问题的价值有多大？

示例话术：

这个提议挺好，我想先了解一下：你觉得现在的方案最大的痛点是什么？引入这个能解决什么问题？

第二步：收益评估

收益维度	评估点
开发效率	能提升多少效率？可量化吗？
代码质量	能减少 bug？提升可维护性？
开发体验	团队是否认可？
生态适配	和现有技术栈是否兼容？

第三步：风险评估

风险维度	评估点
学习成本	团队需要多久掌握？
迁移成本	现有代码要改多少？
稳定性	框架成熟度？社区活跃度？
锁定风险	如果后续不维护了怎么办？
招聘影响	新人是否容易上手？

第四步：落地建议

评估完后：

结论	建议
收益大 + 风险可控	小范围试点 → 推广
收益大 + 风险高	做 POC 验证 → 再决定
收益小 + 风险低	可选引入，不强推
收益小 + 风险高	不引入

示例话术：

我的建议是先在一个新项目上试点，跑 2-3 个迭代后看效果。如果效果好、团队认可，再推广到其他项目。

💡 收尾金句

引入新工具不是为了"技术先进"，而是为了解决实际问题。我会用收益/风险评估来做决策，而不是跟风。

场景四：自研还是用开源方案

📌 场景描述

某个能力（如组件库、低代码平台、监控系统）需要决定是自研还是用开源/商业方案。

🎯 面试官考察点

成本考量能力
长期 vs 短期思维
技术判断力

✅ 高分回答

结构化总览：

我会从四个维度评估：场景匹配度 → 成本对比 → 维护能力 → 长期演进

评估维度对比

维度	自研	开源/商业
定制化	完全满足需求	可能有取舍
启动成本	高（从零开始）	低（开箱即用）
维护成本	持续投入	社区维护（开源）/ 付费（商业）
技术债	自己扛	社区扛（开源）
升级迭代	自主可控	跟随版本升级
人员依赖	依赖核心人员	知识更通用

决策矩阵

条件	建议
核心竞争力、高度定制需求	自研
通用需求、有成熟方案	开源/商业
资源有限、时间紧张	开源/商业
有专门团队维护	可考虑自研
安全/合规要求高	倾向自研

常见场景建议

场景	建议
组件库	基于 Ant Design/Element 二次封装
脚手架	基于 CRA/Vite 定制
监控系统	Sentry + 自定义上报
低代码	除非核心业务，否则用商业方案
埋点系统	取决于数据敏感度

示例话术：

对于组件库，我建议基于 Ant Design 做二次封装，而不是完全自研。理由是：组件库的基础能力已经很成熟，我们投入资源在"轮子"上性价比不高。但业务组件需要根据我们的设计规范封装，这部分要自己做。

💡 收尾金句

自研还是用开源，核心看"这个事情是不是我们的核心竞争力"。如果不是，就用成熟方案，把资源投入到真正有差异化的地方。

场景五：如何推动技术方案落地

📌 场景描述

你设计了一个好的技术方案，但团队执行时总是走样或者落地不了。

🎯 面试官考察点

方案推动能力
团队影响力
执行力

✅ 高分回答

结构化总览：

我会从四个层面保障落地：共识对齐 → 标准制定 → 工具支撑 → 持续跟进

第一步：共识对齐

方案不是我说了算：

markdown

## 对齐方式
- 充分的技术评审（让大家参与讨论）
- 解释"为什么"比"是什么"更重要
- 听取反对意见，合理的要吸收
- 最终方案大家认可，而不是强推

常见落地困难原因：

原因	对策
不理解为什么	多解释背景和收益
觉得太复杂	简化方案或分阶段
惯性思维	从新项目开始，逐步推广
没时间	纳入正式排期

第二步：标准制定

把方案变成可执行的规范：

markdown

## 规范文档
- [ ] 方案设计文档
- [ ] 代码规范文档
- [ ] 目录结构规范
- [ ] 最佳实践示例
- [ ] FAQ 常见问题

## 模板和示例
- [ ] 代码模板
- [ ] 参考项目

第三步：工具支撑

靠工具约束，而不是靠自觉：

层面	工具化手段
代码规范	ESLint + Prettier 强制
目录结构	脚手架生成
组件规范	Storybook 文档化
Commit 规范	Commitlint
代码质量	SonarQube + Code Review

第四步：持续跟进

落地不是一次性的事：

markdown

## 跟进机制
- [ ] 定期检查执行情况
- [ ] 收集反馈，持续优化
- [ ] 新人培训包含规范内容
- [ ] Code Review 时关注规范执行

💡 收尾金句

技术方案落地 = 共识 + 规范 + 工具 + 跟进。好方案不是设计出来就完了，能落地执行才是真的好。

面试追问准备

追问	要点
如果团队不认可你的方案怎么办？	倾听反对意见、用数据说话、小范围试点验证
如何平衡技术追求和业务需求？	业务优先但技术也要规划，找合适时机还债
遇到过选型失败的经历吗？	诚实分享、重点讲学到了什么
如何让团队接受新技术？	培训、结对编程、渐进推广

技术决策情景题 🔧 ​

目录 ​

场景一：选型 React 还是 Vue ​

📌 场景描述 ​

🎯 面试官考察点 ​

✅ 高分回答 ​

第一步：明确评估维度 ​

第二步：对比分析 ​

第三步：结合团队情况决策 ​

第四步：推动落地 ​

💡 收尾金句 ​

场景二：项目有大量技术债务什么时候还 ​

📌 场景描述 ​

🎯 面试官考察点 ​

✅ 高分回答 ​

第一步：评估技术债务影响 ​

第二步：制定还债策略 ​

第三步：如何说服领导给资源 ​

💡 收尾金句 ​

场景三：是否要引入新框架或工具 ​

📌 场景描述 ​

🎯 面试官考察点 ​

✅ 高分回答 ​

第一步：明确要解决什么问题 ​

第二步：收益评估 ​

第三步：风险评估 ​

第四步：落地建议 ​

💡 收尾金句 ​

场景四：自研还是用开源方案 ​

📌 场景描述 ​

🎯 面试官考察点 ​

✅ 高分回答 ​

评估维度对比 ​

决策矩阵 ​

常见场景建议 ​

💡 收尾金句 ​

场景五：如何推动技术方案落地 ​

📌 场景描述 ​

🎯 面试官考察点 ​

✅ 高分回答 ​

第一步：共识对齐 ​

第二步：标准制定 ​

第三步：工具支撑 ​

第四步：持续跟进 ​

💡 收尾金句 ​

面试追问准备 ​

技术决策情景题 🔧

目录

场景一：选型 React 还是 Vue

📌 场景描述

🎯 面试官考察点

✅ 高分回答

第一步：明确评估维度

第二步：对比分析

第三步：结合团队情况决策

第四步：推动落地

💡 收尾金句

场景二：项目有大量技术债务什么时候还

📌 场景描述

🎯 面试官考察点

✅ 高分回答

第一步：评估技术债务影响

第二步：制定还债策略

第三步：如何说服领导给资源

💡 收尾金句

场景三：是否要引入新框架或工具

📌 场景描述

🎯 面试官考察点

✅ 高分回答

第一步：明确要解决什么问题

第二步：收益评估

第三步：风险评估

第四步：落地建议

💡 收尾金句

场景四：自研还是用开源方案

📌 场景描述

🎯 面试官考察点

✅ 高分回答

评估维度对比

决策矩阵

常见场景建议

💡 收尾金句

场景五：如何推动技术方案落地

📌 场景描述

🎯 面试官考察点

✅ 高分回答

第一步：共识对齐

第二步：标准制定

第三步：工具支撑

第四步：持续跟进

💡 收尾金句

面试追问准备