Spring 基础设施协作：事件、资源、类型转换与校验如何守住边界
Spring 应用里有一组容易被称为“工具类”的基础设施：发布事件、读取资源、把字符串转成领域类型、校验输入、执行表达式。它们看起来彼此独立，事故形态却高度一致——边界被隐藏。同步事件被误认为异步消息；一次性输入流被重复读取；全局转换器改变所有绑定结果；校验器在远程 I/O 中阻塞；表达式把不可信文本变成了方法调用入口。
这些组件的价值不是减少几行代码，而是把上下文、类型和失败语义集中到可治理的协议。Spring Framework 核心基础设施只负责进程内协作；完整 MVC、消息中间件和配置框架拥有各自的运行链。官方 Core Technologies 参考 是接口语义入口，工程设计还需要为每个边界补上生命周期、并发与安全约束。
应用事件默认是当前进程内的同步方法分派
ApplicationEventPublisher.publishEvent 把事件交给 context 的 multicaster。默认配置下，匹配的监听器在发布线程中依次执行；发布方法只有在监听器返回后才返回。它不是持久队列，没有跨进程投递、消费确认、重放或天然幂等。监听器异常也可能沿调用栈返回发布者，改变原业务结果。
examples/backend-development/spring-framework/events-resources-conversion/EventDispatchDemo.java 让默认时序可运行：
javac --release 17 -Xlint:all -Werror examples/backend-development/spring-framework/events-resources-conversion/EventDispatchDemo.java examples/backend-development/spring-framework/events-resources-conversion/ConversionValidationDemo.java
java -cp examples/backend-development/spring-framework/events-resources-conversion EventDispatchDemosynchronous=true trace=[publisher:start, listener-a, listener-b, publisher:return]因此同步事件适合进程内解耦、希望监听失败能阻止当前操作、且监听耗时受控的场景。它不能用来掩盖核心业务步骤：若订单完成必须扣减库存，仅发布一个没有完成证明的事件，会让关键不变量依赖监听器是否注册。核心一致性应由明确应用服务或可靠状态机表达，事件负责扩展性副作用。
为 multicaster 配置线程池，或使用异步监听器，会让发布者提前返回。此时监听异常不能再直接通知发布者，需要 ErrorHandler、失败指标和重试/补偿策略；线程池饱和策略决定事件是阻塞、拒绝、丢弃还是由发布线程执行。安全身份、MDC、请求属性和命令式事务资源默认不随线程迁移，必须只复制必要且可清理的上下文。
监听顺序可通过 @Order 等机制影响，但业务正确性不应建立在一串隐式监听顺序上。若 B 必须看到 A 的持久化结果，应把依赖变成显式流程或新的事实事件。监听器还可能在 context 层级中被父子容器重复发现；诊断需记录发布 context、监听器 bean name、是否异步、线程和执行结果。
事务事件改变触发阶段，却不创造可靠消息
事务事件监听可以绑定到提交前、提交后、回滚后或完成后阶段。它解决“只有事务达到某状态才触发进程内回调”的时序问题，不解决提交后进程崩溃的丢失窗口。AFTER_COMMIT 执行时数据库已经提交，监听器失败无法把原事务回滚；若它继续使用仍可见的资源上下文，也不能假定新写入会被原事务再次提交。
没有活动事务时是否执行取决于配置，必须通过测试固定。事件对象也应保存已确定的不可变事实，而不是持有延迟读取的 JPA 实体；提交后再访问懒加载关联可能因会话关闭失败，或读到与发布时不同的状态。跨进程可靠投递仍需 outbox/CDC/消息系统、幂等消费者和可观测积压。
事件类型是公共契约。不要把巨大的可变聚合直接交给多个监听器，也不要让监听器相互修改同一事件对象。稳定做法是包含事件 id、发生时间、聚合 id、版本和最小事实载荷，并在同一进程内同样考虑重复处理——重试、context 刷新和人工补偿都可能造成重复。
Resource 统一定位方式，不保证内容可重复读取
Resource 把 classpath、文件、URL、ServletContext 等位置统一为描述、存在性、输入流和相对资源操作。ResourceLoader 根据位置字符串和当前 context 选择实现；classpath: 找一个资源，classpath*: 可扫描多个 classpath 位置，普通相对路径的解释则与 loader 类型有关。相同字符串在不同运行容器中可能落到不同位置，因此生产配置应使用明确协议并记录归一化描述。
Resource 是句柄，不等于永远存在的 File。应用打成 jar 后，classpath 资源可能位于压缩包中，getFile() 没有操作系统文件可返回；应通过 getInputStream() 读取，除非契约明确要求外部文件。反过来，确实需要文件监听、原子替换或随机访问时，应把外部文件路径作为部署契约，而不是藏在 classpath 抽象后面。
InputStreamResource 通常封装已经打开的一次性流；某些实现调用 contentLength() 可能消费流。ByteArrayResource 可重复打开，适合已受大小限制的内存内容。网络 URL 的 exists()、长度和最后修改时间都可能产生远程 I/O，不能在热点路径中把元数据探测当成本地字段访问。
资源读取必须设置大小上限、连接/读取超时、字符集和关闭责任。将任意用户 URL 交给 ResourceLoader 会引入 SSRF、本地文件读取和协议滥用；允许列表应限制 scheme、host、端口、重定向和解析后的地址，并阻止访问环回、链路本地和云元数据地址。压缩资源还要限制解压后大小与条目数量，避免 zip bomb。
通配扫描成本与 classpath 大小、jar 数量和类加载器层级有关。启动时扫描一万个资源应缓存结果并输出耗时，不要在每个请求中重复 getResources("classpath*:...")。插件或多 ClassLoader 场景还要把 loader identity 纳入缓存键，否则同名路径会串用内容。
ConversionService 负责类型语义，格式化负责人与文本交互
类型转换发生在配置绑定、数据绑定、表达式求值和业务入口等多处。Converter<S,T> 表达单向、强类型转换；ConverterFactory 为一组相关目标类型提供转换器；GenericConverter 可依据源/目标 TypeDescriptor 和注解处理更复杂情况。全局注册意味着所有使用该 ConversionService 的边界都可能改变，转换器不是某个 Controller 的私有小函数。
Formatter 面向本地化文本的 parse/print，日期、货币和展示格式通常需要 Locale；PropertyEditor 有可变状态和历史 JavaBeans 模型，常按线程/绑定过程创建，不应作为全局共享实例。领域标识如订单号、金额、时区应优先转换成不可变值对象，避免整个业务层继续传裸字符串。
ConversionValidationDemo.java 演示先转换，再执行范围校验：
java -cp examples/backend-development/spring-framework/events-resources-conversion ConversionValidationDemoconvertedPort=8080 invalidRejected=true转换器应保持确定、无阻塞 I/O、错误信息可定位。转换字符串到用户对象时远程查库，会把一个看似纯函数的操作变成隐蔽网络边界，还可能在错误回显中泄露存在性。更合理的是先转换成 UserId，再由应用服务显式加载用户。失败要区分“格式非法”“范围非法”“目标不存在”，不要全部包装成没有字段信息的 IllegalArgumentException。
集合转换依赖元素 TypeDescriptor。只判断原始 List.class 会丢失元素类型，导致转换器选择错误；反射泛型、注解限定和空元素策略都要纳入测试。注册 String -> Object 这种过宽转换器会吞掉更具体规则并扩大攻击面，应优先使用窄源/目标对。
Validator 报告约束，不应偷偷执行工作流
Spring Validator 通过 supports 声明目标类型，通过 Errors/BindingResult 收集字段错误和对象级错误。字段错误适合单字段格式、范围；对象错误适合开始时间早于结束时间等跨字段不变量。错误 code 应稳定、可国际化，拒绝值要避免在日志和响应中回显密码、令牌或超长恶意文本。
校验和转换的顺序很重要：原始文本无法转换时，不应继续执行需要目标类型的范围校验；基础字段通过后，才执行跨字段和业务规则。校验分组或分阶段可以表达创建、更新、发布等不同状态，但组数量失控会让同一对象在不同入口拥有难以追踪的合法性。
校验器最好是纯计算。调用远程服务检查库存、向数据库写审计或发送事件，会让失败、超时和事务边界藏在“validate”里。需要查询的业务不变量应由应用服务显式完成，并处理校验后到提交前状态变化的竞态；数据库唯一约束、版本条件和锁仍是最终防线。
绑定不是领域对象构造的唯一安全线。允许客户端绑定任意可写属性会产生 over-posting，例如修改管理员标志、价格或状态。入口 DTO 应只暴露允许字段，再转换成命令；设置允许字段列表与嵌套深度/集合大小上限。未知字段是拒绝还是忽略必须统一，否则客户端拼写错误可能静默丢数据。
SpEL 是求值引擎，不是无害字符串插值
Spring Expression Language 能访问属性、集合、方法、类型、Bean 和运算符，并通过 EvaluationContext 决定可见能力。它为缓存键、安全规则和配置条件提供表达力，也意味着把不可信输入直接作为表达式解析会形成代码能力入口。攻击者可能读取对象图、调用方法或触达类型系统。
安全使用要区分“表达式由开发者配置，数据来自用户”和“表达式本身来自用户”。后者若确有业务需求，应使用受限 EvaluationContext，只开放必要属性和函数，禁止类型引用、构造器、Bean 解析和任意方法调用，并限制表达式长度、复杂度与执行时间。不要依赖字符串黑名单寻找 T( 或 getClass，语法存在多种等价路径。
解析后的 Expression 可以按表达式文本、期望类型和配置版本缓存，但 EvaluationContext 若包含每请求变量，不应被错误全局共享。缓存必须有容量限制，防止用户制造无限不同表达式耗尽内存。编译模式可以提高热点表达式性能，也会带来类型变化和类加载考虑，应基于测量启用。
SpEL 经 ConversionService 把求值结果转换为目标类型，因此一个过宽转换器也会扩大表达式行为。诊断时记录表达式用途、脱敏后的模板标识、期望/实际类型、解析还是求值失败、耗时和所用上下文策略；不要把包含秘密的原始表达式全文写日志。
把四类基础设施放进同一条治理链
一次可靠的入口处理可以明确分层：Resource 只负责取得受限字节并关闭；解析器构造原始 DTO；ConversionService 生成领域值；Validator 报告结构与不变量错误；应用服务在事务内改变状态；提交后产生不可变事件；需要跨进程时转入可靠消息状态机。每一层都输入明确类型、输出明确结果，不用异常和 ThreadLocal 偷偷传递业务控制。
生产指标也应对应边界：事件记录监听器数量、同步/异步耗时、拒绝与失败；资源记录协议、字节数、读取耗时、超时和关闭失败；转换记录源/目标类型、失败 code 和热点转换器；校验记录字段/对象错误分布但不记录敏感拒绝值；SpEL 记录缓存命中、解析/求值耗时和拒绝策略。
测试要覆盖反例，而不只验证 happy path：监听器抛异常、线程池饱和、事务不存在；jar 内资源、一次性流、超大和超时资源；空值、泛型集合、Locale、转换歧义；嵌套绑定、未知字段、跨字段错误；恶意表达式和缓存洪泛。基础设施的成熟度，体现在这些失败都停在预定边界，而不是功能演示能跑通一次。