用Optional封装HTTP Header可选字段，从编译和逻辑层杜绝NullPointerException，使字段存在性成为类型系统一部分；需规范定义、反序列化、校验、解包及API契约，避免滥用与误用。
直接用Optional封装HTTP Header中可能缺失的字段，能从编译和逻辑两层杜绝NullPointerException，让“这个头是否存在”成为类型系统的一部分，而不是靠文档或经验去猜。
明确声明Header字段的可选性
把传统用String接收的Header字段，改为Optional。比如Authorization、X-Request-ID、Accept-Language这些非必传头：
- 定义DTO时写
private Optional，而非authorization; private String authorization; - 反序列化时用Jackson或Gson配合
@JsonDeserialize自定义反序列化器，将null或缺失字段转为Optional.empty() - Spring MVC中可通过
@RequestHeader(required = false)接收，再手动包装成Optional.ofNullable(value)
统一校验与安全解包
不再散落各处写if (header != null && !header.trim().isEmpty())，而是集中用Optional语义处理：
- 用
authorization.filter(s -> !s.isBlank()).map(JwtUtil::parseToken)链式过滤空串并转换 - 用
requestId.orElseGet(() -> UUID.randomUUID().toString())提供默认ID，避免生成null字符串 - 用
acceptLanguage.ifPresent(lang -> response.setHeader("Vary", "Accept-Language"))只在存在时操作响应头
暴露清晰的API契约
Controller或Service方法返回值、内部方法参数都使用Optional，让调用方无法忽略缺失场景：
- 例如
public Optional，比返回extractTenantIdFromHeader(HttpServletRequest req) String更诚实 - 下游服务调用时，若Header未提供租户标识，直接返回
Optional.empty()，而不是抛异常或返回占位符如"unknown" - 配合Lombok的
@Builder.Default或Record构造器，默认设为Optional.empty()，避免意外null
避免常见误用陷阱
Optional不是万能胶，用错反而增加复杂度：
- 不要在实体类字段上滥用Optional——JPA/Hibernate不支持持久化Optional，会报错或静默失效
- 不要用
optional.get()强行解包，必须配合isPresent()、orElse或ifPresent - 不要把Optional作为方法参数传递（除非是函数式接口），它本意是返回值容器，不是输入契约
- Header解析失败时，优先返回
Optional.empty()；只有真正属于业务错误（如token格式非法）才抛异常
