技术是要为业务服务的

在当今互联网时代，技术的发展日新月异。从 AI 大模型到物联网，从区块链到低代码平台，各种新技术层出不穷，开发者们似乎一不留神就会被时代抛弃。

但在相关社区中，经常能听到一些类似的声音：

• “学了那么多技术，感觉没什么用。”
• “我学了 XX 技术，接下来该学什么？”
• “框架太多了，根本学不过来。”

更有甚者直接跑去人家开源项目主页提 Issue ：“别搞了，学不动了”。

这些焦虑背后的共同点，是把学习技术当成了目的，而忘记了技术存在的根本意义——服务业务，解决问题。

技术的本质是解决问题的手段

任何技术的出现，都源于业务需求。技术不是自娱自乐的玩具，而是业务发展的工具:

• HTTP 协议是无状态的，每次请求在服务器看来都是全新、独立的。为了管理用户状态，Session，Cookie 等状态管理机制应运而生。
• 单纯依靠内存存储状态非常脆弱，服务器重启或进程崩溃会导致会话丢失。为保证业务数据的持久性，数据库成为了不可或缺的基础设施，用于存储用户信息、产品数据等核心业务数据。
• 随着访问量增加，数据库频繁查询带来的负载问题愈发突出。为提高性能、减轻数据库压力，缓存机制被引入，成为支撑高并发业务的重要手段。
• 随着业务复杂度增加，单体应用难以快速迭代和扩展。微服务架构将业务拆分成独立模块，各自管理生命周期和资源，从而提高系统灵活性和开发效率。
• ...

透过以上例子可见，技术本身不是目标，而是手段。学习技术的核心目的是解决实际问题、支持业务发展。

应该选择匹配的技术

在实际工作中，技术的决策应该基于业务场景的具体需求，而非社区热度或个人喜好。

没必要在几百日活时考虑几百万的并发，优秀的系统架构是演化出来的，而非预先过度设计的。先做出来再考虑优化，况且很多项目实际往往还没来得及进行优化就被裁撤。

能够使用简单方案解决的问题，就不需要引入复杂内容，因为额外的技术组件会增加系统复杂度、维护成本和故障点。如无必要，勿增实体。

尽量使用成熟的技术而非新颖的，技术的稳定性要高于它的新奇性，新技术可能有很多优点，但破坏项目只需要一个缺点。

此外，团队技术栈的统一有利于知识共享，人才培养和维护效率，比单纯追求最佳技术更重要。

但是很多人却在追求着技术，而不考虑实际业务，口头上常常挂着高并发，微服务，大数据，缓存击穿等高大上术语，结果一问 UV，DAU 就不说话了。

技术为业务赋能

尽管说技术需要为业务所服务，但有些时候，技术是可以成为业务的。尤其是当一项技术具有颠覆性、稀缺性或能够构建生态时，它就可能直接成为业务的核心。

譬如近几年大火的 AI 大模型。最初只是技术研究和算法突破的成果，但随着其通用性和广泛的适用场景逐渐展现出来，不仅支撑了传统业务的升级，还衍生出了新的商业模式。

技术不是最终目标，业务价值才是。每一个技术选型、架构设计、性能优化的背后，都应该回答一个问题：它能为业务带来什么价值？

把技术看作解决问题的手段而非目的，焦虑就会减少，学习也会更有方向。不需要再问“我该学什么技术”，而是思考“这个问题该用什么技术最有效”。