值对象的核心是无标识、不可变、以属性组合定义相等性；其价值在于语义清晰、避免副作用、天然线程安全，而非底层内存分配优化。
值对象（Value Object）本身不依赖堆分配，也不存在“栈上分配红利”这种技术概念——Java 等主流 JVM 语言中，对象默认在堆上分配，是否逃逸、能否标量替换、是否被 JIT 优化为栈内结构，完全由 JVM 运行时决定，开发者无法主动“使其享受栈上分配红利”。
值对象设计的核心目标不是绕过JVM机制，而是建模准确性和可维护性
DDD 中的值对象本质是：无标识、不可变、以属性组合定义相等性。它的价值在于语义清晰、避免副作用、天然线程安全。重构重点应落在以下方面：
- 确保真正不可变：所有字段 final，构造后无 setter，不暴露可变内部状态（如返回 List 时不返回原始引用，而用 Collections.unmodifiableList 包装）
- 重写 equals/hashCode 基于全部业务属性：例如 Money(amount, currency)、Address(street, city, zip) 必须完整参与比较，不能漏掉任意一个语义字段
- 消除隐式共享与副作用：避免在值对象方法中修改外部状态或调用非纯函数；若需计算衍生值（如 Address.normalized()），应返回新实例而非修改自身
关于“栈上分配”的常见误解与事实
有人误以为把值对象写成 record 或精简类就能强制栈分配，但实际：
- JVM 的逃逸分析（Escape Analysis）是自动触发的，仅当对象未逃逸出当前方法作用域，且未被同步、未被反射访问、未被存储到静态/堆变量中时，才可能被标量替换（Scalar Replacement）——此时字段被拆解为局部变量，间接实现“类似栈分配”效果
- record 类型只是语法糖，生成的仍是普通类，不影响逃逸判定；它有助于快速实现不可变性和结构化 equals/hashCode，但不改变内存分配行为
- 手动使用 ThreadLocal 或对象池模拟“栈语义”，反而破坏值对象的无状态、可共享本质，违背 DDD 原则，且极易引入并发或复用 bug
真正提升性能与表达力的重构方向
比起纠结底层分配，应聚焦让值对象更贴合领域语义，并为 JVM 提供优化机会：
- 缩小作用域：将值对象作为方法参数或局部变量使用，避免长期持有（如不存入集合、不设为字段），显著提升逃逸分析成功率
- 避免包装类型滥用：用 int/long 替代 Integer/Long 表示金额单位（配合货币代码），减少装箱开销和 GC 压力
-
合理使用 record（Java 14+）：对纯数据组合（如 Range
、Point2D）直接用 record，编译器自动生成不可变结构和正确 equals，降低出错概率 - 警惕“伪值对象”：含 lazy 初始化、缓存字段、Builder 模式或 withXxx 方法链的对象，已丧失值对象本质，应重构为实体或分离计算逻辑
值对象的价值不在内存位置，而在它让业务意图一目了然、让变更影响范围可控、让测试边界清晰。优化应从模型准确性出发，而不是反向迁就虚拟机实现细节。
