对象操作工程化规范聚焦可读性、可维护性、可预测性，通过清晰命名（如useremail、isverified）、分层结构（分离输入/领域/输出对象、控制嵌套深度）、防御编程（构造校验、只读视图、显式转换）实现好用、好管、少出错。
对象操作的工程化规范，核心是让对象既好用、又好管、还不容易出错。它不是堆砌规则，而是围绕“可读性、可维护性、可预测性”三个目标展开。命名、结构、防御，三者环环相扣：名字不清，结构难懂；结构混乱，防御无从下手；缺乏防御，再好的命名和结构也会在运行时崩塌。
属性命名：让人一眼看懂“它是什么、从哪来、怎么用”
命名不是语文考试，而是接口契约。重点不在“美不美”，而在“有没有歧义、会不会误导、是否留有扩展余地”。
-
用名词短语，避免动词或模糊缩写：比如
userEmail比email更明确（谁的邮箱？），isVerified比verified更清晰（这是状态，不是动作） -
区分来源与用途：来自数据库字段的属性加后缀如
createdAtDb，来自前端表单的加前缀如formSubmittedAt，避免后续混淆数据源头 -
布尔属性统一用
isXxx/hasXxx/canXxx：不写active或flag这类易引发真假猜测的名称 -
数值类属性标明单位或范围：如
timeoutMs、retryCount、maxRetries，不写timeout或retries
结构设计：按职责分层，不把所有东西塞进一个对象里
对象不是数据筐，而是有边界的协作单元。结构松散导致逻辑散落，结构过紧又阻碍复用和测试。
-
拆分读写关注点：输入对象（如
UserCreateRequest）、领域模型（如User）、输出对象（如UserSummaryDto）应分离。避免用同一个类既接收参数又持久化还返回给前端 -
嵌套深度控制在两层以内：
user.profile.address.city可接受，user.org.team.members[0].contact.preferred.method就该警惕——说明职责过度集中，应提取中间实体如ContactPreference -
可选字段显式标记，不可为空字段强制构造：用语言特性支持（如 TypeScript 的
?、Kotlin 的可空类型、Java 的@NonNull注解）让空值意图可见，而不是靠文档或注释“提醒” - 避免“上帝对象”：一个对象若超过 15 个属性，或同时承担校验、计算、序列化、缓存等多重职责，大概率需要拆解
防御性编程：在对象生命周期关键节点主动设防
防御不是给每个字段加 if (x == null)，而是在对象创建、赋值、转换、使用这四个环节建立检查关口。
- 构造即校验：对象实例化时就验证必填字段、格式（如邮箱正则）、取值范围（如年龄 0–150）。拒绝“先造出来，再慢慢修”的做法
-
setter/with 方法做轻量约束：对可变对象，修改属性前检查合法性（如
setAmount(BigDecimal amount)检查是否为负）；不可变对象则全部通过构造器或 builder 控制 -
对外暴露只读视图：返回集合时用
Collections.unmodifiableList()或ImmutableList，防止外部误改内部状态 -
跨层传递时做显式转换，不裸传原始对象：比如 DAO 层返回的
UserEntity不直接交给 Controller，必须经UserEntity.toDto()转换，中间可过滤敏感字段、补全默认值、做空安全包装
