直接拼接渠道逻辑导致维护困难，因新增渠道需反复修改业务代码；桥接模式通过分离Message与Notifier，将渠道绑定移至运行时组合，实现高内聚低耦合。
为什么直接拼接渠道逻辑会让通知系统越来越难维护
当你在控制器里写 if ($channel === 'email') { sendEmail(...) }，再加个 elseif ($channel === 'sms') { sendSms(...) }，第三种渠道一来就得改业务代码——这不是扩展，是打补丁。桥接模式的核心不是“多写几个类”，而是把 Message（内容）和 Notifier（渠道）的绑定关系从代码里抽出来，变成运行时组合。
定义抽象层：Notifier 接口与 Message 数据结构
先锁定不变的部分：所有渠道都得有个 send() 方法，且必须接收一个结构化的消息对象。不要用数组传参，避免字段名散落各处。
示例：
interface Notifier
{
public function send(Message $message): bool;
}
class Message
{
public string $title;
public string $body;
public array $metadata = []; // 如 recipient, template_id 等渠道相关字段
}
注意：$metadata 是故意留的灵活字段，但别让它变成“什么都能塞”的黑洞——每个具体渠道实现类只读取自己关心的键，比如 SmsNotifier 只取 $message->metadata['phone']，不碰 'email'。
立即学习“PHP免费学习笔记（深入）”；
实现具体渠道：EmailNotifier 与 WeChatWorkNotifier 的差异点
不同渠道对内容格式、认证方式、限流策略差异极大。桥接的关键在于让这些差异只出现在具体实现里，上层完全无感。
-
EmailNotifier需要 SMTP 配置，依赖PHPMailer或symfony/mailer，$message->metadata至少含'to'、'from' -
WeChatWorkNotifier走企业微信 Webhook，要求 JSON body 包含'msgtype'和'text'字段，认证靠access_token（常需缓存） - 两者都调
$notifier->send($message)，但内部构造请求的方式、错误重试逻辑、日志埋点位置完全不同
错误容易出在：把渠道专属配置（如邮箱密码、企微 secret）硬编码进接口或基类——它们必须由具体实现类自己从环境变量或配置中心加载。
运行时组合：用工厂或 DI 容器解耦创建逻辑
别在业务代码里 new 具体渠道类。通过简单工厂或容器注入，让调用方只关心“我要发什么”，不关心“怎么发”。
例如：
// 根据配置动态选渠道
$notifier = match ($_ENV['NOTIFY_CHANNEL']) {
'email' => new EmailNotifier(...),
'wechat_work' => new WeChatWorkNotifier(...),
default => throw new InvalidArgumentException('Unknown channel'),
};
$notifier->send(new Message([
'title' => '订单已支付',
'body' => '订单 #12345 已完成支付',
'metadata' => ['to' => 'user@example.com'],
]));
真正复杂的是元数据映射：同一份业务事件（如“用户注册成功”）可能需要发给不同人、用不同模板、带不同跳转链接。这时候 Message 构造过程本身就需要封装成 MessageBuilder，而不是让业务代码手动填 $metadata。
跨平台不是指“一次写完所有渠道”，而是确保新增第 N 个渠道时，你只改两处：加一个实现类、在工厂里加一行分支——其余代码全不动。这点最容易被忽略：桥接的价值不在初始结构多优雅，而在第 5 次加渠道时你还能不改核心逻辑。
