后端开发其实没你想的那么难
很多人认为后端技术很复杂，但其实一般项目的技术其实压根就没有那么高要求。什么查询优化，数据缓存弄着弄那的，结果一看数据才几万条。
复杂的其实是业务，而不是技术。技术你不会可以学，但业务可能上一秒做好了，下一秒产品经理就说：“这个流程改一下。”
后端其实很简单
后端的开发，本质其实就是三个步骤：
接收数据 → 处理数据 → 返回数据
说白了就是前端把请求发过来，你拿到参数，处理一下，再返回结果。我们平时讲的“CRUD”（增删查改）其实就是这样。
所有的后端技术，几乎都是围绕这个流程展开的。
- 需要数据保存？那就用数据库（简单的甚至可以直接写文件）。
- 数据多了服务器撑不住？加缓存、做负载均衡。
- 功能越来越多？拆分成多个模块、服务，搞微服务。
- 有登录注册等功能？那就得加权限系统、认证、加密存储。
- 要提高性能？那可能还要用队列、限流、异步等等。
但就算你一开始啥都不会，只要把这个流程搞清楚，一步一步照着做，基本上就能写出一个能用的后端系统。
比如我们用 Express 写一个最简单的后端：
const express = require('express')
const app = express()
app.get('/', (req, res) => {
res.send('Hello World')
})
app.listen(3000)
以上就是一个简单的后端。访问 localhost:3000 就能看见 Hello World 字样。
如果遇到了需要接收参数的情况，就根据请求类型从请求头里面取出来就行。
拿到参数了就调方法，调完方法接着就返回数据。
但也别小看“简单”
说它简单，是说入门容易，真要做出一个靠谱、稳定、可扩展的系统，那难度还是很高的。
比如下面这些看起来“简单”的需求，其实每一个做起来都藏着坑：
- 订单功能：库存怎么扣减？并发会不会超卖？失败怎么回滚？限购怎么控制？
- 权限管理：一个用户既是管理员又是普通用户怎么办？子权限继承怎么设计？不同模块的权限怎么统一管理？
- 支付系统：怎么防止重复支付？怎么处理支付回调？支付状态同步失败怎么办？
这就是为什么说“复杂的不是技术，而是业务”。
因为技术可以查文档，学教程，但业务是你踩过坑、看过线上事故、参与过版本迭代，才能真正掌握的。
框架的意义
那问题来了：既然后端开发流程这么简单，那为什么各种后端框架还层出不穷？
答案是：框架本质上就是对底层的封装，是为了简化流程、提升效率，让开发者少踩坑。
不用框架
我使用现金，得先找到现金，然后出门，来到菜市场，再找对应的商铺才能买菜，没标价要手动问价，可能还要费劲心思砍价，同时现金支付，要注意对方找的是不是假币，现金交易还不好记录。
使用框架
我使用电子支付，出门边上就是生活超市，要买的东西全部都在一个分区，全部明码标价，不议价，电子支付不需要担心假币，支付后有电子账本自动记账可以查看。
通过框架，我们简化了流程，去除了不必要的重复代码，还提高了效率。在以上例子中：
- 钱就是我们接口需要的参数。
- 菜市场的各类商铺是我们将要调用的方法。
- 费劲心思问价砍价是需要校验参数，获取值，处理值。
- 注意假币是处理异常。
- 记账是日志记录。
- 买的东西是返回结果。
你依然是买菜，但效率、体验、稳定性，完全不一样了。
这也是为什么大家愿意花时间学习框架，甚至在已有框架之上再二次封装业务框架，为了就是统一流程，减少重复劳动。
框架虽好，灵活性也可能受限
诚然，使用框架能大大提升开发效率，但它也不是万能的。
就像前面所说，用框架开发，就像去超市买菜，虽然方便、省时、有保障，但也失去了一部分自由。
你去超市买菜，看到价格是 1块5一把，称重、打包、结账、走人，全流程高效流畅。
在菜市场，这菜也许只要1块钱，你还能砍价，甚至老板心情好送你几根辣椒。你想多抓一把，也没人管你。
你还可以：
- 自己挑选哪一把菜叶子嫩。
- 问老板“这菜农药打了没？”
- 让他顺便帮你洗一下。
- 买完还顺口问一句：“明天有没有其他菜？”
自由度高，选择灵活，操作空间大。
回到开发中，框架也是一样
框架帮你封装了流程、约定了规范、隐藏了细节——确实让你写代码时更轻松。但如果你想“多抓一把菜”时，就可能发现：
- 框架已经规定好怎么路由、怎么校验、怎么处理异常，你很难跳出来做自己的定制逻辑。
- 某个默认中间件不合你胃口，想替换却牵一发动全身。
- 想接入一个边缘功能（比如一个定制化的权限模型、非主流的认证方式），发现“框架不支持”、“要 hack”。
- 调试流程时，不清楚内部执行顺序、看不到原始调用栈，排错更难。
- 性能优化上也可能被“框架包袱”拖累，比如部分自动注入、拦截器、ORM 封装本身就有开销。
你想走小路，因为它是一条捷径，可框架却不知道，非要导航你走大道，绕一大圈。
所以，不必神化框架，也别排斥框架。
关键是你是否理解它的机制，知道它给你带来了什么，又限制了什么。
真正的自由，是你知道规则之后，依然可以做选择。
写在最后
后端开发，其实没有那么神秘。
- 会写逻辑 = 可以做后端
- 能分析问题 = 可以解决业务需求
- 会用工具 + 肯动脑子 = 可以持续成长。
别怕技术看起来多复杂，大多数项目用的技术其实都很基础。
怕的不是你不会技术，而是你不愿意去理解业务。
如果你能把“流程处理”变成“业务理解”，那你已经不是一个“写后端”的人了，而是一个“解决问题”的人。
最终，不论你用什么语言、什么框架，写的还是“前端请求 → 后端处理 → 返回结果”的那件事，只不过你做得更稳、更快、更聪明了而已。
那时，你就会发现，所谓的后端开发，其实从来不是在堆技术名词，而是在解决一个又一个问题。