结构型模式总览

结构型模式调整对象之间的关系：怎样接入旧接口、怎样包装已有对象、怎样组织树、怎样共享状态。先识别发生变化的边界，再决定是否需要一个模式；同一段委托代码可能服务于不同目的，不能只凭“包了一层”命名。

从订单导出识别结构问题

一个导出服务需要读取订单、选择输出形式、写入文件，并通知用户。接入不同厂商的通知 SDK 时，内部的“提交通知”与厂商的方法、状态码不一致，这是适配器的边界。如果摘要通知和完整通知都要支持邮件、站内信，通知形式与发送渠道是两个变化维度，可以用桥接组织。

文件输出需要按顺序增加缓冲、压缩等能力时，可以组合装饰器。下载导出文件前要确认当前用户仍有权限，属于代理控制的访问边界。两者都可能持有另一个同接口对象，但意图不同：一个增加处理能力，一个控制目标访问。

导出目录包含文件与子目录，统一统计大小时适合组合。若成千上万条记录共享同一份不可变列定义，可以评估享元；每条订单的金额、用户与权限状态不能因此共享。外观则给使用方提供“创建导出任务”的简化入口，内部仍由各组件维护自己的规则。

这些关系可以同时存在，但每增加一个包装对象，都应能说明它隔离了哪类变化。没有变化压力时，直接调用一个清楚的接口通常更容易维护。

按边界选择详细页

当前问题	模式与阅读入口	需要先确定的合同
厂商参数、返回状态与内部接口不同	适配器	哪些状态可以转换，哪些必须报错
通知形式与发送渠道分别扩展	桥接	两个维度是否确实独立，哪些组合合法
文件与目录使用同一种统计操作	组合	叶子和容器支持的共同操作
对输出按顺序叠加处理	装饰器	包装顺序、异常传播和关闭责任
常用流程需要稳定入口	外观	结果状态，以及各步骤的事务边界
大量对象包含相同的稳定信息	享元	可共享状态与每次调用的外部状态
访问对象前要鉴权、延迟加载或缓存	代理	谁能访问，缓存是否仍满足权限与新鲜度要求

适配器适合消化已经存在的接口差异；桥接从结构上分离变化维度。策略主要替换算法，不能因为一个类注入两个接口就认定它使用了桥接。更完整的算法替换例见策略模式。

包装之后仍要守住语义

缓存用户资料时，即使命中缓存，也必须先完成当前请求的权限判断。缓存键要涵盖影响数据可见性的租户、对象及必要的身份或授权版本；权限变化后的失效和数据更新后的过期规则需要单独设计。代理只把这些控制集中起来，不会自动解决越权与脏数据。

“创建导出任务”的外观可以返回任务编号和“待处理”，由后续查询得到成功或失败。对包含支付的下单流程，也不能在“支付请求已提交”后立即记为已支付、发放积分。外观统一调用入口，异步状态、幂等和补偿仍需要业务协议与持久化机制，相关边界见事件驱动架构。

评估设计时，可以沿一次调用追踪：入口依赖哪个接口、实际访问哪个对象、状态在哪里保存、失败由谁处理。若必须穿透多层包装才能确认行为，应减少层数或明确每层的职责，而不是继续叠加模式。