我做项目后才理解：技术选型不是堆技术栈

刚开始做项目的时候，我其实挺容易被“技术丰富度”吸引。

看到别人项目里有 Redis、有消息队列、有分布式锁、有 Elasticsearch，再加一点监控、容器化、限流熔断，就会下意识觉得这个项目很强。

但自己真正做过几个项目之后，我慢慢发现，技术选型这件事远没有“会不会用更多组件”这么简单。

很多学生项目最大的问题，不是技术太少，而是每个技术都沾了一点，但你说不清它为什么一定要在这里出现。

我以前的误区：以为技术越多，项目越完整

这个误区我现在看挺典型的。

因为学生阶段很容易把项目当成一个展示板，想把学过的东西都塞进去，觉得这样简历更好看，面试也更有内容。

但后面我发现，这样做的副作用很明显：

• 系统边界变模糊了。
• 复杂度上来了，但收益不明显。
• 面试官一追问，你自己都讲不清为什么这么设计。

尤其是当一个组件只是“因为别人也在用”才被加进来时，它最后几乎一定会变成项目里的空心部分。

我后来开始怎么判断一个技术该不该上

我现在会先问自己几个问题。

第一，它解决的到底是不是当前项目的真实问题。

第二，不用它会怎样，用了它具体换来了什么。

第三，它引入的新复杂度我能不能讲清楚。

第四，如果面试官追问为什么是它而不是别的方案，我有没有像样的回答。

如果这几个问题答不上来，我就会警惕自己是不是又在“为技术而技术”。

以 xTimer 为例，我后面更能理解取舍了

比如 Redis ZSet 这个点，以前我可能会停在“因为 Redis 快，所以用了它”。

但现在我会更愿意说：

“我把它放在调度热层，是因为数据库直接高频扫描成本高，而 Redis 的有序结构适合承接临近任务推进。但我没有让它承担最终状态，因为任务恢复、状态追踪和一致性语义还是更适合放数据库。”

这两种说法，表面上都叫“用了 Redis”，但后者明显更像真正思考过。

再比如是否直接用 XXL-JOB。这个问题也不是一句“我想自己实现一下”就结束了。真正值得讲的是：你为什么愿意承担自研的复杂度，它换来了什么，你又失去了什么。

我现在越来越重视“边界感”

技术选型说到底不是组件收集，而是在系统里划边界。

哪个组件负责快，哪个负责稳，哪个负责异步解耦，哪个只是辅助能力，这些如果不清楚，项目最后就会变成一种看上去什么都有，实际上哪一层都没站稳的状态。

而且这种问题面试时特别容易暴露。因为面试官不需要把整个系统拆穿，他只要追着问两三个“为什么”，你是不是想清楚了基本就看出来了。

我现在反而更欣赏“克制”

有时候一个项目真正显得成熟，不是因为用了很多技术，而是因为你知道哪些地方先不用。

比如一个阶段任务量还没上来，就没必要为了“高并发叙事”硬塞一堆中间件。一个问题还没有明显瓶颈，也没必要为了显得高级去做复杂架构。

克制不是保守，而是你知道复杂度本身也是成本。

如果现在让我给过去的自己一句提醒

我会说，别把技术选型理解成“我要展示我会什么”，而要把它理解成“我要为系统问题做什么取舍”。

只有这样，项目里的技术才不是贴标签，而是真的长在系统里。