用途：在 Spring Boot 3 中实现异常映射与 RFC 9457（Problem Details）错误响应。先检查现有 advice、安全入口点和 API 测试，每个 API 只保留一种错误策略；成功 DTO 或成功信封可与 Problem Details 错误共存，因为 RFC 9457 只规定错误表示。
主要能力：启用 Spring 内置 MVC 异常处理（spring.mvc.problemdetails.enabled: true）；WebFlux 使用 spring.webflux.problemdetails.enabled 与响应式异常处理，servlet 模板不适用于 WebFlux。配合编译好的 DomainException 与 ProblemDetailExceptionHandler，按声明的状态码和稳定错误码映射子类，如 OrderNotFoundException 为 404、InsufficientInventoryException 与 BusinessRuleViolationException 为 422。每个公共类单独文件；面向 API 的异常携带 HTTP 状态元数据，无框架领域可保持领域异常独立并在 Web 适配器映射。不要暴露任意持久化或基础设施异常消息。
用法：advice 继承 ResponseEntityExceptionHandler 以保留框架异常处理；校验返回 400 与字段违规，意外失败返回通用 500 且完整异常仅留在服务端日志，注意可空校验消息安全。过滤器级认证失败需 AuthenticationEntryPoint，授权失败需 AccessDeniedHandler，controller advice 不覆盖安全过滤器链。响应字段示例含 type、title、status、detail、instance、errorCode；自定义问题类型使用项目自有稳定 URI，type 可省略并默认 about:blank，此时 title 应匹配 HTTP 状态短语，HTTP 状态与 body 状态必须一致，JSON 问题使用 application/problem+json，用 errorCode 或 violations 等扩展提供机器可读细节。
验证与限制：测试实际 HTTP 响应的领域 404/422、校验 400、意外 500 及框架错误（如畸形 JSON、不支持方法），断言内容类型、状态、稳定错误码且无堆栈或内部消息；单独测试过滤器 401/403。注意：代理处理与领域抛出不匹配的异常类；不要强行把 Problem Details 塞入旧 API；不要要求每个错误都有显式 type；不要把成功信封与 Problem Details 视为不兼容；不要依赖 advice 处理过滤器异常；不要在 500 中返回内部异常消息。