dto 应有意识地封装而非简单封禁，每个接口专属命名dto、禁用跨服务对象引用、字段级暴露用@jsonproperty(access=write_only)前置控制、通过构造函数/builder强制校验状态、版本升级用带版本号的新dto替代。
微服务架构中，DTO 的数据暴露不是“要不要封”，而是“怎么有意识地封”。核心在于用 DTO 切断内部模型与外部契约的强绑定，让每个服务对外只说它该说的话。
明确 DTO 的边界职责
一个 DTO 只服务于一个明确的接口场景，比如 UserProfileDTO 用于用户详情页，UserSummaryDTO 用于列表页。不复用、不泛化。避免出现“万能 UserDTO”——它容易随业务膨胀而不断加字段，最终变成内部实体的镜像，失去隔离意义。
- 每个 API 接口对应一个专属 DTO，命名体现用途（如
OrderCreateRequestDTO、OrderStatusResponseDTO） - 禁止 DTO 中直接引用其他服务的领域对象或 VO/DO
- DTO 字段必须是基础类型（
String、Long、LocalDateTime等）或本 DTO 自定义的嵌套 DTO，不能含 JPA 实体、Service 返回的 DO 或 PO
字段级暴露控制要前置到类定义
敏感字段的隐藏不能靠运行时过滤逻辑，而应从 DTO 类结构本身约束。Jackson 的 @JsonProperty(access = JsonProperty.Access.WRITE_ONLY) 是最轻量、最可靠的方案——它在序列化阶段就剔除字段，不依赖额外配置或拦截器。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在 UserDTO 中对
password、idCard、internalCode等字段直接加@JsonProperty(access = WRITE_ONLY) - 嵌套 DTO（如 AddressDTO 嵌入在 UserDTO 中）同样需独立标注，不因外层 DTO 安全就放松内层
- 避免使用
@JsonIgnore全局忽略，它无法区分读写场景；也不推荐靠@JsonView动态切换，增加调用方理解成本
用构造函数和 Builder 封装初始化逻辑
DTO 不该允许任意 setter 修改状态，尤其当字段间存在隐含约束（如 status 和 reason 必须成对出现）。通过构造函数或 Builder 强制校验，把“无效状态”挡在对象创建之前。
- 提供全参构造函数，要求关键字段不可为空（配合 Lombok 的
@Builder(builderMethodName = "create")） - 对布尔型开关字段（如
isVerified），用verified命名 + 构造传参，避免 setter 被误调 - 禁止无参构造 + 大量 setter 的“开放式”构建方式，那等于放弃封装性
版本演进时用新 DTO 替代字段增删
API 版本升级不靠给老 DTO 加字段或改语义，而是定义新 DTO。例如 v2 接口返回 UserV2DTO，它可继承 UserV1DTO 并新增 lastLoginAt，但绝不修改原字段含义或删除已有字段。
- DTO 类名带版本号（
UserResponseV1DTO、UserResponseV2DTO），避免歧义 - Controller 层按 Accept Header 或路径前缀（
/v2/users）路由到对应 DTO 构建逻辑 - 旧 DTO 保留在代码中，供兼容性支持，但不再新增功能
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
