外观模式重构的核心是收束分散的变量交互逻辑到可控入口，明确变量暴露与封装边界，通过输入收敛、输出净化、副作用隔离实现协作协调，而非堆砌包装或沦为配置集合。
外观模式重构的核心，不是加一层壳，而是把原本散落在各处、彼此牵扯的变量交互逻辑收束到一个可控入口里。重点在于理清哪些变量真正需要暴露，哪些该被封装掉，而不是堆砌包装函数。
识别该重构的信号
当项目中出现以下情况，说明变量交互已失控，适合引入外观模式：
- 多个组件频繁读写同一组状态变量（比如 userAuth、cacheTTL、retryCount），且逻辑分散在不同文件中
- 请求发起前要手动拼接 token + timestamp + signature + version，每次调用都重复类似代码
- 缓存键名由 url + params + userRole + locale 拼接而成，但拼接逻辑在 4 个地方各自实现，稍有改动就漏改
- 错误处理依赖变量组合判断（如 error.code === 401 && isExpired），但 isExpired 的计算逻辑藏在另一个工具函数里，调用方并不清楚依赖关系
重构时变量管理的关键原则
外观类不是变量仓库，而是变量协作的协调者。它不存储业务数据，但明确管理变量间的流转规则：
- 输入收敛：客户端只传必要参数（如 userId、resourceId），其余变量（authToken、region、timeout）由外观内部按策略注入或推导
- 输出净化：返回值只含语义清晰的字段（如 data、isValid、expiresAt），屏蔽原始响应里的中间态字段（rawHeaders、cacheHitFlag）
- 副作用隔离：变量变更（如更新 lastActiveTime、刷新 refreshToken）必须发生在外观内部，禁止客户端直接修改共享状态
典型重构步骤（以 API 请求模块为例）
假设原有代码中，请求逻辑与变量操作混杂：
- 原写法：fetchData(url, { token, timeout, cacheKey }) → 手动检查 localStorage[cacheKey] → 自己 parse/json/try-catch → 自己 setItem
- 重构后：apiFacade.fetch({ resourceId: 'post-123', forceRefresh: false })
外观类内部完成全部变量协同：
- 根据 resourceId 推导出标准 cacheKey 和 apiUrl
- 从统一凭证管理器获取当前 token，自动附加 Authorization 头
- 读取全局 defaultTimeout，若传入 forceRefresh 则跳过缓存并重置 staleThreshold
- 缓存写入时，附带元数据 { fetchedAt, expiresAt, etag }，而非裸数据
避免常见陷阱
外观模式容易沦为“假封装”，尤其在变量处理上：
- 不要把所有配置项都作为外观构造函数参数传入（如 new ApiFacade({ timeout, retry, cache, logger })），这会让外观变成配置集合，失去协调意义
- 不要在外观方法里暴露子系统变量供外部读写（如 facade.cacheService 或 facade.config.timeout），这等于开门放客户端直连子系统
- 不要为每个变量组合写一个方法（如 getDataWithAuth()、getDataWithCache()、getDataWithAuthAndCache()），应通过参数组合控制行为
