真正能杜绝非法变更的是明确的不可变设计、访问控制机制和构造阶段校验；需用final/readonly锁死字段、封装不可变集合、防御性返回getter、构造即校验、工厂方法兜底，并以纯函数替代this依赖。
不能靠“约束 this”来杜绝非法变更——this 本身不控制属性可变性，它只是运行时的上下文引用。真正能杜绝非法变更的，是明确的不可变设计、访问控制机制和构造阶段校验。
用 final / readonly / 不可变类型锁死字段
Java 中所有关键字段声明为 final，确保构造完成后值不可改；TypeScript 使用 readonly 修饰符；Kotlin 用 val。这些不是语法装饰，而是编译期强制契约：一旦赋值，任何后续赋值操作都会报错。
- final 字段配合安全发布（如通过 synchronized 或 volatile 写入共享变量），能保证其他线程看到的一定是完整初始化后的状态
- 避免在构造器中调用非 private / 非 final 方法——子类可能绕过 final 语义，提前访问未初始化字段
- 集合类字段优先用 unmodifiableList/set/map 包装，或直接使用 ImmutableList.copyOf()（Guava）
禁止暴露可变内部状态
对象提供 getter 不等于必须返回原始可变对象。常见陷阱是 getter 返回 ArrayList 或 HashMap 引用，外部直接修改导致内部状态被篡改。
- getter 应返回防御性拷贝（如 new ArrayList(this.items)）或不可变视图（Collections.unmodifiableList(this.items)）
- 对复杂嵌套对象（如 User → Address → Street），逐层封装只读接口，而非暴露整个链路的可变引用
- DTO 和领域模型严格分离：输入对象允许修改，领域对象从构造起就冻结，输出对象仅含只读字段
构造即校验 + 工厂方法兜底
非法变更往往源于对象创建时就携带了矛盾状态，比如 status=“ACTIVE” 但 lastLoginTime=null。这类问题必须在实例化前拦截。
- 构造函数内做全量业务校验：必填字段非空、状态组合合法、数值范围合规，不满足则抛 IllegalArgumentException
- 复杂校验逻辑不塞进构造器，改用静态工厂方法（如 User.create(validatedDto)），先验再建，失败不产实例
- 禁止构造器中调用外部服务、启动线程、注册监听器——这些行为既破坏不可变性，又引发 this 逃逸风险
用语言特性替代 this 驱动的可变逻辑
很多所谓“this 变更风险”，本质是把对象当状态筐滥用。现代工程实践倾向消除对 this 的依赖，而非规范它的用法。
- 将计算逻辑抽成纯函数：validate(user) 而非 user.validate()，参数显式传入所需字段，不隐式读写 this
- React/Vue 等框架中优先用函数组件 + Hooks，彻底规避 this 绑定与状态污染问题
- 必要时用解构提前提取字段：const { id, email, role } = user; 后续逻辑不再依赖 user.xxx，自然规避误改
