Java是强制面向对象语言，所有代码必须依附于类，所谓“面向过程”只是局部static方法的伪风格，本质仍受OO约束，且暴露数据行为割裂、难扩展、类型安全弱等问题。
面向对象的核心是“谁来做”，面向过程的核心是“怎么做”
Java 是强制面向对象的语言，class 是一等公民，连最简单的 main 方法都必须写在类里。这不是语法糖，而是设计约束：你无法真正写出纯面向过程的 Java 程序——没有全局函数，没有独立于类的变量，所有行为必须依附于对象或 static 成员。
所谓“面向过程风格”，只可能出现在局部：比如在某个 static 方法里堆逻辑、不封装数据、不拆分职责。但这本质仍是“用面向对象的壳，干面向过程的事”，运行时仍受 JVM 类模型和访问控制约束。
static 方法不是面向过程的通行证
很多人误以为把一堆逻辑塞进 public static void doSomething() 就是面向过程编程。其实不然：
-
static方法仍属于某个class，受该类的访问修饰符（private/protected）、包可见性、继承关系影响 - 它无法直接访问非
static成员，反而暴露了数据与行为的割裂——这恰恰违背面向过程“数据+操作紧耦合”的原始意图 - 多个
static工具方法分散在不同类中，比 C 语言的.h+.c更难统一管理，也更难做单元测试（依赖静态上下文）
真正接近面向过程的写法，反而是用单例类 + 全局状态 + 链式 static 调用，但这种模式在 Java 中极易引发并发问题和测试隔离失败。
对象建模失败时，面向过程“错觉”最强烈
当你看到这样的代码，容易觉得“这很面向过程”：
public class Calculator {
public s
tatic int add(int a, int b) { return a + b; }
public static int multiply(int a, int b) { return a * b; }
public static double average(double... nums) {
return Arrays.stream(nums).average().orElse(0.0);
}
}
但它的问题不在“是否面向过程”，而在于建模缺失：
- 没有
Number或Expression抽象，所有操作都是离散函数 - 无法扩展：比如支持复数、矩阵、带单位的物理量计算，就得不断加
static方法，而不是通过子类或策略注入 - 类型安全弱：
add("1", "2")编译不过，但add(1, 2)和add(1L, 2L)可能隐式转换出错，而面向对象可通过泛型 + 接口约束输入
Java 的泛型擦除、缺乏运算符重载、不支持多方法分派，确实让某些场景下“对象”显得笨重。但这不是倒退回面向过程的理由，而是提醒你：该用 interface 定义契约，用 record 封装不可变数据，用 sealed 限制实现范围。
编译期和运行时的差异比理念区别更实际
争论“该不该面向对象”不如看 JVM 怎么执行：
- 所有非
static方法调用最终转为invokevirtual指令，依赖运行时类型；static方法是invokestatic，无动态绑定开销 - 对象实例必走堆内存分配（除非逃逸分析优化），而面向过程风格的局部变量全在栈上——但 Java 不允许你手动控制“数据是否属于某个实体”
-
final类、private字段、var局部变量这些特性，其实在模糊范式边界：它们既服务于封装（OO），也服务于确定性（OP）
真正要小心的，不是范式标签，而是 new 出来却从不设字段、所有方法都 static、类名像工具包（Utils、Helper）却不定义领域概念——这种代码在协作中会迅速腐化，因为没人能说清“这个数据该由谁负责”。
