变量解耦是切断隐式跨层硬编码依赖，使变量来源、作用域、生命周期和影响清晰可控；通过契约化容器、分层隔离、事件机制实现。

变量解耦不是消除变量，而是切断变量之间隐式的、跨层的、硬编码的依赖链条。核心在于让每个变量的来源、作用域、生命周期和变更影响都清晰可控，避免“改一个值，八方报错”。

识别变量耦合的典型症状

这些信号说明变量已形成脆弱依赖网：

• 某个方法里反复 new 同一个配置类或上下文对象，只为取其中一两个字段
• 业务逻辑中直接引用 Spring 的 Environment 或系统 Properties，且多处用相同 key 读取
• 新增一个业务分支（比如灰度开关），需要在控制器、服务、DTO、甚至前端传参里同步加字段
• 单元测试必须 mock 十几个变量或构造复杂上下文才能跑通一个方法

用契约化变量容器替代散落引用

把零散变量收口为有明确语义的“上下文对象”，不暴露原始来源：

• 定义 OrderContext 类，只包含订单场景真正需要的字段：userId、channel、isVip、promoCode —— 不含 Environment、Request 或数据库连接
• 该类由统一工厂构建，比如 OrderContextFactory.from(Request request) 或 .from(OrderEvent event)，封装解析逻辑
• 所有业务方法签名改为接收 OrderContext，而非 Request、Map 或一堆独立参数
• 测试时只需 new 一个轻量对象，无需启动容器或构造真实请求

分层隔离变量生命周期与来源

不同层级的变量应由对应层负责供给，禁止越级穿透：

• 接入层（如 Controller）负责将 HTTP 参数、Header、Token 解析为上下文对象
• 服务层（如 Service）只操作上下文对象，不反查 Request 或 Environment
• 基础设施层（如 Repository）通过参数传入必要变量（如 tenantId），不从 ThreadLocal 或静态配置里拿
• 全局配置（如超时时间、开关）用 @ConfigurationProperties 绑定为类型安全 Bean，服务层通过依赖注入获取，而非直接读字符串 key

用事件机制解耦变量变更通知

当一个变量变化需触发多方响应时，避免轮询或主动调用，改用发布-订阅：

• 用户等级变更后，积分模块、优惠券模块、消息推送模块都需响应 —— 不要在 UserService 里逐个调用 updateXxx()
• 改为发布 UserLevelChangedEvent，各模块监听并处理自身逻辑
• 事件体只携带最小必要数据（userId、oldLevel、newLevel），不传整个 User 对象或上下文
• 异步消费可天然解耦执行时机，也便于失败重试和日志追踪