编程不只是语法，而是思维方式
这几年，随着现代编程语言越来越普及，越来越多人开始接触一些以前听起来有点“高深”的词：
声明式编程、函数式编程、命令式编程、面向对象编程……
很多人第一次看到这些概念时，会有一种感觉：
“是不是又是程序员喜欢发明新名词？”
“我平时写个 Java、Python、JavaScript，不也一样能干活吗？”
“这些编程方式，到底是思想差异，还是只是写法不一样？”
说实话，这种疑惑非常正常。
因为大多数程序员最开始学编程，学的其实不是“编程范式”，而是“语法 + API + 框架”。
会写 if、for、class、new，会调库，会做业务，项目能跑，就已经开始写代码了。
但随着代码越写越多，项目越做越复杂，你会慢慢发现：
真正决定代码质量、可读性、可维护性的，很多时候不是语法本身，而是你到底在用什么思维组织代码。
而命令式、声明式、函数式这些词，本质上讲的就是这个问题：
你是怎么告诉计算机做事的？
今天这篇文章，我就尽量用比较通俗的方式，把这些常见编程思想讲清楚，也顺带说说它们之间到底是什么关系，以及除了这些之外，还有哪些常见的编程方式。
一、先说结论：这些不是“互相取代”的关系，而是“看问题的角度不同”
很多人一看到这些概念，就容易下意识地比较：
- 到底命令式更高级，还是声明式更高级？
- 函数式是不是比面向对象更先进？
- 现代语言是不是都在淘汰命令式？
我先说我的观点：
这些范式，大多数时候不是谁消灭谁，而是谁更适合什么场景。
它们的差别，不在于“谁更牛”，而在于：
- 你更关心过程，还是结果
- 你更喜欢控制细节，还是抽象细节
- 你更强调状态变化，还是数据变换
- 你更想让代码“可执行”，还是“可组合”
很多现代语言之所以越来越强，不是因为它们只支持一种范式，
而是因为它们开始同时吸收多种范式的优点。
比如：
- Java 本来更偏面向对象、命令式，但后来加入了 Lambda、Stream、Record
- JavaScript 既能写事件驱动，也能写函数式风格
- Python 既能命令式写脚本，也能写声明式列表推导
- SQL 几乎就是声明式的代表
- React 这种前端思想，也大量带着声明式味道
所以真正重要的，不是死记术语，
而是搞清楚：
这些方式背后，分别在解决什么问题。
二、命令式编程：告诉计算机“怎么一步一步做”
先说最容易理解的：命令式编程（Imperative Programming）。
它的核心思想其实很朴素：
你把每一步操作写给计算机看，告诉它先干什么，再干什么。
比如你要从一个列表里找出大于 10 的数字，再把它们平方，最后放进一个新列表。
命令式写法大概像这样：
List nums = List.of(3, 11, 20, 5, 15);List result = new ArrayList<>();for (Integer n : nums) { if (n > 10) { result.add(n * n); }} 这段代码的特点非常明显：
- 先创建结果集
- 再遍历原始数据
- 再判断条件
- 再执行添加动作
你把“过程”完整写出来了。
这就是命令式编程最核心的味道：
强调步骤、强调状态变化、强调控制过程。
它为什么这么普遍？
因为它很符合人的直觉。
我们平时教别人做事，本来也是这样说的：
- 先把材料拿出来
- 然后洗干净
- 再切好
- 最后下锅炒
这其实就是一种命令式表达。
命令式编程的优点
它最大的优点，就是：
直接、清楚、容易理解执行顺序。
尤其在这些场景里，命令式特别好用：
- 流程控制复杂
- 需要精确控制每一步
- 状态变化很多
- 底层逻辑明确
- 性能优化需要掌握细节
比如写：
- 网络通信
- 文件处理
- 线程控制
- 游戏循环
- 系统底层逻辑
- 复杂业务编排
命令式风格都很常见。
命令式编程的问题
但命令式写多了，也容易出现一个问题：
代码非常关注“过程”，慢慢会淹没“意图”。
还是刚才那段代码，你一眼看到的是：
- 创建了个 ArrayList
- 写了个 for
- 写了个 if
- add 了东西
但你真正想表达的意图其实只是：
从列表里筛选出大于 10 的数字，并求平方
也就是说，过程比意图更显眼。
当业务一复杂，嵌套一多，变量一堆，命令式代码就很容易变得啰嗦、分散、难组合。
所以后来很多语言和框架，都开始往“更高层的表达”走，这就引出了声明式。
三、声明式编程：告诉计算机“我要什么”，而不是“我怎么做”
声明式编程（Declarative Programming） 的核心思想可以概括成一句话：
你描述目标，不强调步骤。
还是刚才那个例子，如果用 Java Stream 写，可能会变成这样：
List nums = List.of(3, 11, 20, 5, 15);List result = nums.stream() .filter(n -> n > 10) .map(n -> n * n) .toList(); 你会发现，这种写法很不一样。
它不再显式告诉计算机：
- 先创建容器
- 再遍历
- 再 if 判断
- 再 add
它表达的是：
- 过滤
- 映射
- 收集
也就是说，它更像是在说：
我想要一批满足条件的数据，而不是我准备怎么循环处理它。
这就是声明式的核心魅力：
代码更接近“目的”，而不是“手工步骤”。
最经典的声明式例子：SQL
如果说哪个世界最能体现声明式，很多人第一个会想到 SQL。
比如：
SELECT name, ageFROM userWHERE age > 18ORDER BY age DESC;你没有告诉数据库：
- 先怎么扫描磁盘
- 再怎么过滤记录
- 再怎么排序
- 用什么索引
- 走几次循环
你只是声明：
我要年龄大于 18 的用户，并按年龄倒序排列。
至于底层怎么优化、怎么执行，由数据库引擎自己决定。
这就是声明式非常典型的特征：
你负责表达需求，系统负责实现过程。
声明式编程的优点
它最大的优点通常有三个：
第一，更贴近业务意图。
代码读起来更像“在描述要做什么”。
第二，更容易组合和抽象。
一连串 map、filter、sort、reduce，比手写多层循环更容易拼装。
第三，更方便底层优化。
比如 SQL 查询优化器、Stream 并行处理、前端虚拟 DOM diff，本质上都受益于“描述结果而非固定步骤”。
声明式编程的局限
但声明式也不是万能的。
如果你面对的是一个过程很复杂、状态不断变化、异常路径很多的系统流程，仅仅声明“我要什么”可能不够，你还是得清晰写出控制逻辑。
另外，声明式有时候会隐藏执行成本。
比如你写 Stream 很优雅，但如果底层产生了很多中间对象，或者写了一堆不必要的链式调用，性能和调试体验可能并不好。
所以声明式不是“更先进的命令式替代品”，而是：
在合适的问题上，用更高层的方式表达意图。
四、函数式编程：把程序看成“数据变换”，而不是“状态操作”
接下来是最容易被误解的一个：函数式编程（Functional Programming）。
很多人一提函数式，第一反应就是：
“哦，就是 Lambda。”
“就是 map、filter、reduce。”
“就是少写 for 循环。”
这只能算碰到一点边，但不完整。
函数式编程真正的核心思想是：
把程序尽量看成函数之间的组合，把计算过程看成输入到输出的变换。
它强调几个关键词：
- 纯函数
- 不可变数据
- 函数组合
- 少副作用
- 高阶函数
先说最重要的：纯函数。
什么叫纯函数？
简单说，一个函数如果满足两点，就可以理解为纯函数：
第一，同样的输入，永远得到同样的输出。
第二，不偷偷修改外部状态，不产生难以预期的副作用。
比如：
public int add(int a, int b) { return a + b;}这就是典型纯函数。
你给它 1, 2，永远返回 3。
它不会顺便改数据库，也不会打印日志，也不会改全局变量。
而下面这种就不是：
private int total = 0;public int addToTotal(int n) { total += n; return total;}它依赖内部状态，也修改内部状态。
同样的输入，不一定产生同样的结果。
函数式编程
为什么函数式喜欢纯函数？
因为纯函数有一个巨大优势：
好理解、好测试、好组合。
你不用担心它背后偷偷干了别的事。
函数像数学公式一样，输入输出关系比较稳定。
这会让代码更适合：
- 并发
- 推理
- 复用
- 测试
- 重构
函数式不只是“写短一点”
很多人误以为函数式只是让代码更短。
其实真正重要的不是“短”，而是把副作用隔离，把数据变换变清晰。
比如订单金额计算：
public BigDecimal calculateFinalAmount(BigDecimal price, BigDecimal discountRate) { return price.multiply(BigDecimal.ONE.subtract(discountRate));}这种函数式味道就很强。
它不依赖数据库，不改外部对象，不关心调用上下文。
它只是完成一次纯粹的计算。
如果这种风格逐步扩展到系统里，你会发现一个很大的好处：
复杂系统里最容易失控的，往往不是计算本身，而是状态和副作用。
比如：
- 哪个对象被谁改了
- 哪个线程共享了哪些数据
- 哪个方法顺手更新了缓存
- 哪个流程调用时偷偷发了消息
函数式思维，本质上是在尽量减少这些“不透明的变化”。
五、函数式和声明式很像，但它们不是一回事
这是最容易混淆的地方。
很多人会把声明式和函数式混为一谈，觉得它们差不多。
确实，它们经常一起出现，但它们关注点不一样。
声明式更关心“表达方式”
它更强调：
你是在描述目标，还是描述步骤？
比如 SQL 很声明式，但它不一定是函数式。
HTML 也很声明式，但也谈不上函数式。
函数式更关心“计算模型”
它更强调：
你是不是通过函数组合、纯函数、不可变数据来组织程序？
所以它们的关系更像是：
- 有些代码可以既是声明式的，又带函数式味道
- 有些代码是声明式的，但不是函数式
- 有些代码是函数式的，但不一定非常声明式
比如 Java 的 Stream：
List result = nums.stream() .filter(n -> n > 10) .map(n -> n * n) .toList(); 这段代码既有声明式味道，也有函数式味道。
声明式在于：它描述的是“筛选并映射”这个意图。
函数式在于：它通过函数链、数据流转换、高阶函数来组织逻辑。
所以这两个词不是一个东西，只是经常一起出现。
六、命令式、声明式、函数式，真正差别到底在哪？
如果要用最通俗的话来概括，我觉得可以这样理解：
命令式
告诉计算机：你按这几个步骤做。
声明式
告诉计算机：我想要这个结果。
函数式
把问题拆成一连串稳定的数据变换。
还是拿“处理订单列表”举例。
假设我们要找出已支付订单，计算它们的总金额。
命令式写法
BigDecimal total = BigDecimal.ZERO;for (Order order : orders) { if (order.isPaid()) { total = total.add(order.getAmount()); }}特点是：
看得见循环、变量变化、累加过程。
声明式 / 函数式风格写法
BigDecimal total = orders.stream() .filter(Order::isPaid) .map(Order::getAmount) .reduce(BigDecimal.ZERO, BigDecimal::add);特点是：
看得见意图，看不见底层循环细节。
两者谁对谁错？
都没错。
真正的问题是：
- 你当前更需要控制细节，还是表达意图
- 这段逻辑会不会频繁变化
- 这段代码未来是不是要被复用和组合
- 团队读起来哪种更清晰
编程范式最怕的，不是不会，而是宗教化。
好像只要用了函数式就高级，只要写 for 循环就落后。
这其实也是一种误区。
七、为什么现代语言越来越重视声明式和函数式？
这个变化不是偶然的。
我觉得背后有几个很现实的原因。
1. 业务复杂度越来越高了
以前很多程序是单机、小脚本、小模块。
现在动不动就是分层、分布式、并发、异步、流处理、前后端分离、云原生。
系统越复杂，越需要代码表达得更抽象、更稳定、更可组合。
声明式和函数式，正好很适合应对这种复杂度增长。
2. 并发和异步越来越常见
一旦程序开始多线程、并发执行，“状态可变”就会变成风险源。
这也是为什么函数式里“不可变”“纯函数”会越来越受欢迎。
因为它天然更适合并发推理。
3. 工程越来越强调可维护性
现在很多代码不是写给自己看的，而是写给团队、写给未来看的。
声明式和函数式风格的一个优点，就是：
更容易把“我想干什么”写清楚。
当代码的意图比细节更清楚时，长期维护成本通常会更低。
4. 现代框架本身就在推动这种风格
比如：
- SQL 天生声明式
- Stream API 带函数式味道
- React 强调声明式 UI
- 配置式框架也越来越声明式
- 数据处理、规则引擎、工作流引擎，也都偏向“描述需求”
所以很多人不是主动去学这些思想，而是在现代开发里自然碰到了它们。
八、但别忘了，底层世界依然离不开命令式
这里我也想讲一个很容易被忽略的点：
声明式、函数式看起来更优雅，但计算机底层最终仍然要执行具体步骤。
也就是说，你写 SQL，并不代表数据库不用执行命令。
你写 Stream，并不代表 JVM 不会迭代。
你写 React，也不代表浏览器不用操作 DOM。
只是这些步骤，被更底层的引擎替你接管了。
所以本质上可以这么理解：
- 命令式更接近执行过程
- 声明式更接近问题表达
- 函数式更接近数学化建模
现代开发不是要彻底摆脱命令式，
而是尽量把重复、低层、样板化的命令式细节，交给更成熟的抽象去处理。
但一旦你需要进入底层优化、异常控制、资源管理、状态协调，
命令式依然是躲不开的。
所以不要把这些范式理解成“进化树”，好像谁一定淘汰谁。
更准确一点说，它们像工具箱。
九、除了这些，还有哪些常见的编程思想？
后面这个部分我不展开太深，就给你做一个顺手的“视野扩展”。
除了命令式、声明式、函数式，常见的编程方式还有这些：
1. 面向对象编程（OOP）
强调对象、封装、继承、多态。
更关注“谁负责什么行为”，适合大型业务系统建模。
Java、C# 这些语言长期都深受它影响。
2. 面向过程编程
更接近命令式，但通常比命令式更强调“按过程拆函数”，而不是按对象建模。
C 语言风格很典型。
3. 事件驱动编程
程序的执行不是一条主线跑到底，而是由事件触发。
前端交互、GUI、消息系统、Node.js 生态里都很常见。
4. 响应式编程
强调数据流和异步事件流。
你可以把它理解成更适合处理“持续变化的数据”的一种模型。
像 Reactor、RxJava、前端响应式框架都有这类思想。
5. 逻辑式编程
你只描述规则和事实，让系统自己推导结果。
Prolog 这类语言很典型。
虽然主流业务开发里不常见，但规则引擎、推理系统里能看到它的影子。
6. 并发 / Actor 模型
把系统拆成多个相互通信的独立单元，而不是共享大量状态。
像 Erlang、Akka 这些思想就很有代表性。
7. 数据驱动 / 配置驱动
这类严格说不一定是经典范式，但在现代企业软件里很常见。
很多系统不是写死逻辑，而是通过配置、规则、流程、元数据驱动行为。
你会发现，现代软件世界越来越像一个“混合体”。
一个真实项目里，常常不止一种思想，而是多种思想叠加。
十、真正重要的，不是背概念，而是知道什么时候该用哪种思维
写到这里，我想说一个我自己的真实看法。
很多程序员学这些概念，最容易犯两个错：
一个是根本不管，觉得这都是术语游戏。
另一个是太当回事，搞成信仰之争。
其实都没必要。
学这些范式，真正的价值不在于你以后能在面试里多背几个词，
而在于你开始意识到：
写代码，不只是“把功能实现出来”，更是在选择一种组织复杂度的方式。
你写一个模块时，脑子里要慢慢有这种意识：
- 这段逻辑，是不是更适合命令式地精细控制？
- 这段数据处理，是不是更适合声明式表达？
- 这部分计算，是不是可以做成纯函数，减少副作用？
- 这块业务，是不是该用面向对象来承载职责？
- 这类异步消息，是不是更适合事件驱动或响应式处理？
当你开始这样想问题时，你的代码思维就已经不只是“会写”，而是在逐步走向“会设计”。
你学的从来不只是语法，而是如何跟复杂世界打交道
很多人刚学编程时，以为学的是关键字、语法、库函数。
写久了才慢慢明白，语法只是外壳，真正重要的是背后的思维方式。
命令式告诉你如何掌控过程。
声明式提醒你先表达目标。
函数式教你减少副作用，把计算变得更干净。
面向对象让你思考责任归属。
事件驱动和响应式，则是在适应越来越复杂的系统协作。
所以程序员成长到后面，往往不是学会了更多语法，
而是逐渐理解：
同一个问题，可以有很多种写法；
而不同写法背后，其实代表着不同的思维方式。
你以为你在学代码。
其实你在学的，是如何用更合适的方式，去描述这个世界、拆解这个世界、控制这个世界。
而这，才是编程真正有意思的地方。
如果你是 Java / 后端 / 全栈开发者，关注我一起走。
本号持续输出：
- Java 核心 & 高并发 & JVM
- Spring / 架构设计 / 实战踩坑
- JavaScript/TS/Vue/大前端
- AI × 编程 / Agent × 工程化
关注我，少踩坑，多走捷径。欢迎点赞 、收藏 ⭐、转发给需要的朋友
--------------------------------------------------
技术不只是“会写”，更重要的是写得值钱。
