面向对象的new与面向过程的main本质不同：Java强制以类为单位组织代码，所有行为必须依附于类型或对象，而C等语言中main是独立入口，函数自由定义调用。
面向对象的 new 和面向过程的 main 函数调用本质不同
Java 强制以类为单位组织代码，main 方法必须写在某个 class 里，哪怕你只写一行逻辑。这不是语法限制，而是设计契约：所有行为必须依附于对象或类型。而面向过程语言（如 C）中，main 是独立入口，函数可自由定义、调用，不绑定任何结构体或实例。
实操上，如果你试图“绕开对象”写 Java，比如把全部逻辑塞进 static 方法里、不用 new、回避字段和封装——那只是披着 Java 外壳写 C 风格代码，JVM 照跑，但失去了类型协作、多态分发、依赖注入等机制支撑。
-
new Person("Alice")触发构造、内存分配、初始化链；而create_person("Alice")（假设有）只是普通函数调用，无生命周期管理 - 面向对象中，
person.getName()的实际执行逻辑可能由子类重写；面向过程中，get_name(person)总是固定实现 - Java 不允许全局变量（除
static字段），也不支持裸函数定义——这是编译器级约束，不是风格建议
private 字段 + public 方法 是 OOP 的最小可行封装单元
面向过程关注“怎么做”，所以函数参数往往暴露内部结构，比如传入一个 int[] 和长度 len，调用方得自己维护一致性；面向对象关注“谁来做”，把数据和操作打包成类，用 private 封装状态，靠 public 方法提供受控访问。
例如：ArrayList 内部用 Object[] 存数据，但你不需知道数组是否扩容、索引是否越界——这些由 add()、get() 方法内部处理。换成面向过程，你就得手动管理数组容量、检查边界、同步修改长度变量。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 没有
private字段的类，等于把结构体成员全公开，和 C 的struct+ 一堆操作函数无异 -
public方法若只做简单 getter/setter，没业务语义（比如setName()不校验空值），封装就流于形式 - JavaBean 规范（
getXxx/setXxx）是工具友好约定，不是 OOP 本质；真正关键的是“谁持有状态、谁负责维护不变量”
继承与 super 调用体现控制权转移，不是代码复用捷径
很多人把 extends 当作“复制父类代码”的手段，结果写出深度继承树，一改全崩。实际上，继承的核心语义是“is-a”关系 + 可替换性（Liskov 替换原则）。super.method() 不是“复用父逻辑”，而是子类在扩展点上主动让渡部分控制权。
比如 BufferedInputStream extends InputStream，子类不覆盖 read() 就无法工作；但若你写 Student extends Person，又在 Student 里重写全部方法、完全忽略 super，那继承就退化成模板继承，失去多态意义。
- 滥用
protected字段会让子类直接读写父类内部状态，破坏封装，比public更隐蔽危险 -
final类或方法不是为了“防止别人乱改”，而是明确表达“此处无扩展意图”，避免误继承 - Java 8 后，接口中
default方法提供了更轻量的行为共享方式，比继承更适合横向能力组合
面向过程思维写 Java 最容易卡在 NullPointerException 和并发问题上
面向过程习惯“我来管内存、我来同步、我来判空”，但在 Java 中，对象引用默认为 null，线程调度不由代码控制。一个面向过程风格的工具类，比如 StringUtils.join(List<string>)</string>，如果没对 list 做 Objects.requireNonNull 检查，下游调用就极易抛 NullPointerException——而面向对象的做法是让 List 实现类自己保证内部一致性，或通过不可变集合（如 ImmutableList）从源头杜绝 null。
并发更是典型：面向过程常用全局计数器 + synchronized 块硬锁，但 Java 的 AtomicInteger、ConcurrentHashMap 或 CompletableFuture 都是围绕对象状态设计的协作模型，不是函数式原子操作的拼接。
- 静态工具类（如
Collections）是面向过程遗存，它们安全的前提是参数不可变或已校验；一旦传入可变对象，风险由调用方承担 - Spring 的
@Service类天然单例，但方法内局部变量线程安全；而面向过程风格的“全局状态+函数调用”极易在并发下出错 - Null 安全不是靠文档约定，而是靠
@NonNull注解、Optional返回、构造时强制非空——这些都需要对象边界来承载约束
