实体类字段和集合中禁止使用Optional，因其不实现Serializable、不被JPA/Hibernate识别、无法被Jackson/Gson正确序列化；应改用null+Optional包装的getter、空集合或状态码表达可选性。
实体类属性或集合里直接用 Optional，会直接导致序列化失败、ORM 映射报错、JSON 传输异常——这不是配置问题，而是设计层面的硬性限制。
实体字段千万别声明为 Optional 类型
Optional 没实现 Serializable 接口，任何含 Optional 字段的类都无法被 ObjectOutputStream 序列化，JPA/Hibernate 也完全不识别 Optional<String> 这类类型，会抛 MappingException。更麻烦的是，Jackson 默认不处理它，Gson 可能输出空对象 {} 或直接崩溃。
- ❌ 错误写法：
private Optional<String> name; - ✅ 正确做法：字段保持原始类型，用
null表达缺失，getter 返回Optional
private String name;<br>public Optional<String> getName() { return Optional.ofNullable(name); }
集合里禁止嵌套 Optional
List<Optional<User>> 或 Map<String, Optional<Order>> 这类结构，本质是数据源混乱的信号。它既无法被 Jackson/Gson 合理序列化，又让调用方陷入双重判空（集合本身非空 + 每个元素是否 isPresent()），还破坏了集合语义——集合本就该表达“零到多个值”，再套一层 Optional 属于语义冗余。
- ❌ 错误写法：
List<Optional<Product>> products = ...; - ✅ 正确做法：用普通集合，空值用
null或过滤掉；需要区分“无数据”和“数据为空”，靠业务逻辑或额外标志位，而不是靠包装
JSON API 返回值也不要用 Optional
REST 接口返回 Optional<User>，Spring MVC 默认会把它序列化成 {"present":true,"value":{"id":1,"name":"Alice"}} 这种前端根本没法解析的结构。前端只认 {"id":1,"name":"Alice"} 或 null，不是 Optional 的内部格式。
立即学习“Java免费学习笔记（深入）”；
- ❌ 错误写法：
@GetMapping("/user/{id}") public Optional<User> getUser(@PathVariable Long id) - ✅ 正确做法：方法返回
User，由 Spring 处理404（如抛ResponseStatusException），或统一包装为Result<User>类型
替代方案比强行包装更可靠
想表达“可能为空”，优先用明确语义的手段：字段用 null、集合用空集合、接口用状态码（如 204 No Content）、DTO 用可选字段注解（如 @JsonInclude(JsonInclude.Include.NON_NULL)）。这些方式天然兼容序列化、ORM 和前端消费，不需要额外绕路。
- 数据库映射：JPA 支持
@Column(nullable = true)，对应字段自然可为null - JSON 输出：Jackson 默认跳过
null字段，配合@JsonInclude控制更灵活 - 业务判断：用
Objects.nonNull(x)或StringUtils.hasText(s)比opt.isPresent()更直白
