Web 实时通信技术深度解析：SSE 与 WebSocket 学习笔记

一、 核心概念概述与技术选型

1.1 传统 HTTP 的局限性

传统的 HTTP 请求是“一问一答”的形式（客户端请求，服务器响应后断开）。为了实现服务器向客户端的主动数据推送，打破单向被动响应的限制，诞生了 SSE 和 WebSocket 两种实时通信技术。

1.2 核心概念对比

• SSE (Server-Sent Events) - “广播电台”模型：基于标准 HTTP 协议的单向通信。连接建立后，服务器源源不断地向客户端推送数据流，但客户端不能通过此通道向服务器发送新数据。
• WebSocket - “打电话”模型：基于 TCP 的双向全双工通信协议。连接建立后，客户端和服务器随时可以互相发送数据，地位平等。

💡 用户观点与场景决策：

在探讨“系统通知小红点”或“实时图文直播”的场景选型时，用户准确指出：“SSE 单向接受，因为用户不需要通过这个通道回复。” 这精准命中了 SSE 的核心优势——针对轻量级、被动接收的场景，使用原生自带断线重连且无惧防火墙拦截的 SSE 是最佳选择。

二、 SSE (单向数据流) 的深层原理与实战

2.1 原理阐述：如何建立持续的数据流

SSE 100% 纯正基于 HTTP 协议。其原理相当于一次“无限期延长”的 HTTP 下载。通过设置特殊的 HTTP 响应头，服务器指示浏览器不要关闭连接，并将接收到的特定格式文本解析为事件流。

PHP 服务端代码示例：

PHP

<?php
// 1. 设置头部，开启事件流
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache'); // 禁用缓存
header('Connection: keep-alive');  // 保持连接

// 2. 发送数据 (格式必须严格遵循 "data: 内容 \n\n")
$messageId = 101; 
echo "id: {$messageId}\n";
echo "data: 这是第101条消息\n\n";

// 3. 清空输出缓存，立即推送
ob_flush(); flush(); 
?>

JavaScript 客户端代码示例：

JavaScript

const eventSource = new EventSource('server.php');
eventSource.onmessage = function(event) {
    console.log("收到服务器推送的数据:", event.data);
};

2.2 原理阐述：自动重连与断点续传机制

• 自动重连概念： 浏览器 EventSource 原生支持网络闪断后的后台静默重连，无需手动编写重连逻辑。
• 断点续传原理： 服务器在下发数据时携带 id: 字段（相当于书签）。当浏览器断线重连时，会在新的 HTTP 请求头中自动添加 Last-Event-ID 字段。PHP 后端通过读取 $_SERVER['HTTP_LAST_EVENT_ID'] 即可得知客户端错过的消息，实现无缝补发。

2.3 深度探讨：LLM 大模型场景与消息持久化

❓ 用户提问整合：

1. SSE 是通过纯 HTTP 请求发送的吗？大语言模型平台如何处理？
2. messageId 真的需要存储到数据库吗？
3. 大模型输出完毕时，服务器如何通知前端关闭连接？

• 大语言模型应用原理： AI 打字机效果底层多采用 SSE。模型每生成一个 Token，后端即刻将其包装为 SSE JSON 格式推给前端追加显示。
• 持久化策略 (是否存储 messageId)：
  • 需要严格送达 (系统通知/交易状态)： 必须持久化，通常存入 Redis Stream/List 或 Kafka 以应对高并发补发。
  • 时效性至上 (AI打字机/股票大盘)： 无需入库。用户断线重连只需获取“此刻最新状态”，断网期间的历史数据作废，PHP 端可忽略 Last-Event-ID。
• 结束信号机制： SSE 协议未规定强制结束语法，通常由业务层约定。
  • 方法1 (主流)： 发送特定文本暗号（如 OpenAI 的 data: [DONE]\n\n），前端拦截到该文本时执行 eventSource.close() 主动掐断连接。
  • 方法2： 自定义事件名，如 event: end，前端专门监听该事件。

三、 WebSocket (双向通道) 的深层原理与实战

3.1 概念与原理：协议升级与握手 (Handshake)

WebSocket 底层基于 TCP，但其首次建立连接是借用标准 HTTP 请求完成的。

原理在于 HTTP 请求头中的 Upgrade: websocket 和 Connection: Upgrade 字段，向服务器申请“升级协议”。同时附带 Sec-WebSocket-Key 验证服务器支持该协议。服务器验证后返回 101 Switching Protocols 状态码，HTTP 历史使命结束，正式切换为 TCP 双向长连接。

3.2 原理阐述：服务端架构转变与事件驱动

传统的 PHP-FPM 为“短连接”设计（运行完毕立即销毁）。而 WebSocket 必须要求进程常驻内存。因此需借助 CLI 命令行模式下的工具（如 Workerman / Swoole）。

PHP WebSocket 服务端核心骨架 (Workerman 风格)：

PHP

<?php
$server = new WebSocketServer("0.0.0.0:8080");

// 建立连接事件
$server->on('Connect', function($connection) { ... });

// 收到消息事件
$server->on('Message', function($connection, $data) {
    $connection->send("服务器收到: " . $data);
});

$server->start();
?>

3.3 深度探讨：群聊广播与私聊的身份映射

💡 用户观点提取：

关于如何实现消息广播，用户指出需要“保存发给谁也就是群聊中的人”。关于私聊，用户指出在连接时需要“记录 userid 方便私聊发送”。

• 群聊广播原理： 服务器在内存中维护一个全局“花名册”（关联数组 $roster = []）。新用户连接时存入该数组，发消息时 foreach 遍历该数组进行 $connection->send()。
• 私聊身份映射原理： 默认连接仅包含无意义的网络 ID。前端在连接建立时（通过 URL 参数或首条鉴权 JSON 消息）传递真实身份标识。后端将花名册的键名替换为真实的 UserId，实现精准寻址：$roster[$userId] = $connection。

四、 生产环境部署原理与 Nginx 避坑指南

4.1 Nginx 代理机制与协议识别

💻 用户提供的核心配置记录：

proxy_pass http://backend;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

原理剖析： 这段配置使得 Nginx 能够识别 HTTP 握手请求中的升级意图。Nginx 作为公网大门（通常监听 80/443），作为透明管道将握手请求及后续 TCP 数据流转发至内网 PHP 独立进程监听的端口（如 8080）。

4.2 核心避坑：两大隐形陷阱与原理

1. SSE 陷阱：打字卡顿现象
   • 原理： Nginx 默认开启代理缓冲 (Proxy Buffering)，为节约网络资源会截留数据直至凑够一定体积（如 4KB）才下发，破坏了实时字符流输出。
   • 解决： PHP 下发头部 header('X-Accel-Buffering: no'); 或 Nginx 配置 proxy_buffering off;。
2. WebSocket 陷阱：离奇失联 (60秒魔咒)
   • 原理： Nginx 的 proxy_read_timeout 默认为 60 秒，无数据流动会被判定为死连接并强制斩断。
   • 解决： 心跳机制 (Heartbeat)。用户指出这是“发送活动报文”。前端通过 setInterval 定期发送极小体积的 JSON (Ping)，后端回复 (Pong)，以保持通道活跃，重置 Nginx 倒计时。

4.3 安全加密策略 (WSS 与 混合内容拦截)

❓ 用户提问与思考：

为什么必须用 Nginx 而不直接连后端 8080 端口？用户准确回答出浏览器安全机制：“拦截 CORS (准确讲为混合内容 Mixed Content拦截)”。

• 加密原理： 现代网站均使用 https://。如果在安全环境下发起明文的 ws:// 请求，会被浏览器以安全策略强行拦截。必须升级为 wss:// (WebSocket Secure)。
• 架构分工： Nginx 负责持有 SSL 证书并进行“SSL 卸载”，解密外网的 wss:// 数据，然后通过内网以明文 ws:// 转发给后端的 PHP 进程，实现安全与性能的解耦。

五、 分布式架构进阶：高并发集群与 Redis 通信

随着在线人数激增，单台 PHP 服务器遭遇内存与连接数瓶颈，必须扩展为多台服务器集群（Server A, B, C）。

5.1 核心痛点：内存孤岛效应

每台服务器只维护连接到自己机器上的本地“花名册”。Server A 无法直接将消息发送给连接在 Server B 上的用户。

5.2 解决方案原理：Redis Pub/Sub (发布/订阅)

引入 Redis 作为中央通信枢纽：

1. 订阅 (Subscribe)： 所有 Server 启动时订阅 Redis 的同一全局频道。
2. 发布 (Publish)： Server A 收到用户消息后，不再直接处理，而是打包推送给 Redis 频道。
3. 广播与分发： Redis 瞬间将消息同步给所有 Server，每台 Server 监听到消息后，再遍历本地“花名册”下发给用户。

5.3 深度机制：防回音 (Echo Prevention)

💡 用户架构设计思路：

“利用哈希表存储连接 id 确保不会发送回去”

防回音处理原理： 当 Server A 将消息推给 Redis 后，Redis 会广播给所有节点（包含 Server A 自身）。为了防止发送者收到自己发出的重复消息：

1. 数据包封装： Server A 推送到 Redis 的 Payload 必须包含发送者的身份标识 (sender_id)。
2. 分发过滤： Server A 从 Redis 监听到广播，在遍历本地 $roster 下发时，执行比对：如果遍历到的 $userId === $sender_id，则 continue 跳过，实现精准去重。

六、 综合回顾与技术选型总结表

七、 SSE 的并发机制与数据安全隔离

7.1 用户疑问与场景破除

❓ 用户提问： “Sse技术当有两个用户访问时，那默认不是返回一样的内容？”
❓ 延伸提问（LLM场景）： “那如果我要是通过sse转发大模型stream呢？用户一的问题用户二不会访问到吗？”

7.2 核心原理阐述：每次连接都是“专属热线”

虽然 SSE 被比喻为“广播电台”，但在 Web 通信底层，每一次 EventSource 的实例化，都会向服务器发起一次完全独立的 HTTP 请求。
在传统的 PHP 运行环境中，服务器会为每个请求分配独立的执行环境，这意味着用户之间是100% 物理隔离的。默认情况下不仅不会返回一样的内容，开发者还可以根据用户的身份下发完全个性化的数据流。
示例代码：PHP 识别用户身份并进行定向推送

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('Connection: keep-alive');

// 1. 通过 URL 或 Session 识别独立用户
$currentUser = $_GET['username'] ?? '匿名访客';

// 2. 下发专属于该用户的数据
if ($currentUser === '张三') {
    echo "data: 张三，你的专属数据流启动。\n\n";
} elseif ($currentUser === '李四') {
    echo "data: 李四，这是你的定制通知。\n\n";
}

ob_flush(); flush();
?>

7.3 深层原理：PHP 转发大模型流的内存隔离策略

当 PHP 作为中间层转发 LLM 流（如 OpenAI）时，采用了类似“客服中心”的隔离模式。Nginx 为张三和李四分别唤醒不同的 PHP 进程。无论是接收到的 prompt 还是发起网络请求的 cURL 句柄，全部作为局部变量存在于该进程的内存中。随着请求结束，进程重置，数据瞬间销毁，绝不会发生“串线”。
示例代码：PHP 配合 cURL 安全转发 LLM SSE 流

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('Connection: keep-alive');

// 绝对隔离的局部变量
$userPrompt = $_POST['prompt'] ?? '';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://api.openai.com/v1/chat/completions");
// ... 设置 API Key 及包含 $userPrompt 的请求体 ...

// 拦截底层流并实时吐给当前连接的专属用户
curl_setopt($ch, CURLOPT_WRITEFUNCTION, function($curl, $data) {
    echo $data; 
    ob_flush(); flush();
    return strlen($data);
});

curl_exec($ch);
curl_close($ch);
?>

八、 宿主环境底层逻辑：Nginx 与 PHP-FPM 的分工

❓ 用户提问： “这个自动创建进程是 nginx 的特性还是 PHP 的特性？”

8.1 核心概念拆解：调度者 vs 执行者

为每个请求分配独立执行环境，是 PHP-FPM (FastCGI Process Manager) 的特性，而非 Nginx 的特性。

• Nginx（极速的单播前台）： 采用**异步非阻塞（事件驱动）**架构。它通常只开启极少量的 Worker 进程，不负责具体的业务逻辑执行，只负责维持海量的网络连接，并将需要处理的任务打包传递给后端。
• PHP-FPM（严谨的进程池管理器）： 采用多进程/进程池机制。它提前创建好一批 PHP Worker 进程。当 Nginx 移交请求时，FPM 分配一个空闲进程执行。执行完毕后，进程清空当前的内存状态并返回进程池，以此实现 HTTP 请求级别的绝对沙箱隔离。

九、 跨语言并发模型对比：PHP vs Java

❓ 用户提问： “那如果我的语言是 JAVA 呢？”
❓ 延伸提问： “那为啥 PHP 是进程而不是线程，而 JAVA 是线程？”

9.1 原理阐述：单进程多线程模型 (Java) 与数据串线风险

Java（如基于 Tomcat 的 Spring Boot 环境）采用的是单进程、多线程模型。所有的用户请求都在同一个 JVM 进程中由不同的线程处理，共享同一块堆内存 (Heap)。

• 危险点（数据串线）： 如果将用户特定的数据（如 prompt）定义在类级别（成员变量），由于 Spring 默认控制器是单例的，后一个用户的请求会直接覆盖前一个用户的数据。
• 安全做法： 必须将数据定义在方法内部（局部变量），利用 Java 线程私有的栈内存 (Stack) 来保证数据安全。
  示例代码：Java (Spring Boot) 实现安全的 SSE 数据流

@RestController
public class ChatController {

    // ❌ 绝对禁止：定义在这里会导致并发下的用户数据互相覆盖
    // private String dangerousPrompt; 

    @GetMapping(value = "/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter streamAiResponse(@RequestParam String prompt) {
        // ✅ 局部变量：存储在当前线程的私有栈中，绝对安全
        String safePrompt = prompt; 
  
        SseEmitter emitter = new SseEmitter(600000L); // 10分钟超时

        // 开启异步线程处理，防止阻塞 Tomcat 核心工作线程
        new Thread(() -> {
            try {
                // 模拟业务处理与推送
                emitter.send("针对问题 [" + safePrompt + "] 的回复...");
                emitter.send("[DONE]");
                emitter.complete();
            } catch (Exception e) {
                emitter.completeWithError(e);
            }
        }).start();

        return emitter;
    }
}

9.2 深层原理：架构基因与历史演进

• PHP (Share-Nothing 架构)： 追求极致稳定性。早期 C 扩展缺乏线程安全机制，采用多进程物理隔离能确保单一请求崩溃不影响全局。开发者无需关注锁、死锁和内存泄漏问题。
• Java (企业级资源共享)： 追求极高运行效率。JVM 启动成本昂贵（需加载海量类库），因此必须以常驻内存的形式运行，通过轻量级的线程复用底层资源（如数据库连接池），代价是开发者必须具备极强的并发控制能力。

十、 异步底层哲学：从 Nginx 到协程 (Coroutine)

💡 用户观点提取与洞察：
用户指出 Nginx 作为调度者的角色，“这里貌似有点像协程”。

10.1 原理阐述：I/O 多路复用与事件驱动

用户的洞察极其精准。Nginx 与现代编程语言中的“协程”在底层哲学上高度一致，它们都依赖于操作系统的 I/O 多路复用机制（如 Linux 的 epoll）。

• 阻塞等待的痛点： 传统的同步线程/进程在遇到 I/O 操作（网络请求、数据库查询）时，会处于死等状态，浪费 CPU 资源。
• Nginx 的系统级抽象： 遇到 I/O 阻塞时绝不等待，立刻挂起当前事件，切换去处理其他用户的连接，待 I/O 就绪后通过系统中断回调继续处理。
• 协程的语言级抽象： 协程（如 Go 语言的 goroutine，PHP 的 Swoole）本质上就是在编程语言层面实现了 Nginx 的调度机制。开发者用同步的代码逻辑编写程序，当遇到 I/O 耗时操作时，底层的协程引擎会自动将当前代码块“挂起”，让出执行权，等待 I/O 完成后再无缝恢复执行，从而用极少的系统开销扛住海量的高并发。

深度解析学习笔记：框架核心机制、前后端分离鉴权与 SSE 流式输出

本笔记基于开发实践中的核心问题探讨，系统梳理了面向对象编程底层的内存布局、前后端分离架构下的鉴权选型、PHP框架中 Server-Sent Events (SSE) 的标准流式输出规范，以及基于 AOP 思想的钩子与行为设计模式。

模块一：面向对象编程 (OOP) 核心机制

1. 核心概念探讨：类的继承与 protected 属性

• 用户视角与疑问：子类继承父类的 protected 属性后，实例化时是共享父类的属性，还是创建了全新的副本？
• 概念解释：
  • 继承的本质：继承是子类获取父类“可被继承的方法和属性”的过程。父类如同“基础设计图”，子类是基于此扩展的“新设计图”。
  • protected 访问控制：表示该属性对外界封闭，但对子类公开，子类可将其视为自身属性直接访问。

2. 深层原理：实例化后的内存布局

• 非共享原则：除了使用 static 关键字声明的静态属性外，普通属性在实例化后绝不共享。
• 内存分配：当实例化一个子类对象时，内存中会为其分配一块独立空间。这块空间不仅包含子类自身定义的属性，还完整包含了从父类继承过来的所有属性副本。修改实例 A 的继承属性，不会影响实例 B 或父类本身。

3. 补充机制：parent:: 关键字与上下文

• 用户视角与疑问：parent::_initialize(); 中 parent:: 似乎是静态调用语法，为何能调用非静态属性/方法？
• 原理机制：parent:: 并非仅限静态调用，它是 PHP 提供的一种跨越重写（Override）屏障的特殊语法。它指示程序“执行父类中被当前子类覆盖的方法”。此时方法的执行上下文（$this）依然绑定在当前的子类实例上，确保了对象状态的一致性。

模块二：PHP 闭包与作用域隔离

1. 核心概念：匿名函数与 use 关键字

• 用户视角与疑问：在 Hook 注册中，function ($user) use ($auth) 这种语法的作用是什么？
• 概念解释：这在 PHP 中被称为**闭包（Closure）**或匿名函数。
  • ($user)：函数的形参，即函数执行时被动接收的外部数据。
  • use ($auth)：闭包特有语法，用于主动将函数外部的变量状态“捕获”到函数内部使用。

2. 深层原理：作用域隔离

• 原理机制：PHP 的函数作用域默认是严格隔离的。内部无法直接访问外部变量。use 关键字打破了这一隔离，通过值传递（默认）或引用传递（&$var），将定义闭包时的环境状态封存进函数体，确保回调函数在未来任意时刻执行时，都能拥有所需的上下文环境。

模块三：前后端分离架构下的鉴权机制

1. 核心概念：有状态 Token 与无状态 JWT

• 用户视角与疑问：FastAdmin 框架中的 Token 与 JWT 有何区别？前后端分离时如何处理表单验证 Token？
• 概念解释与对比：
  • FastAdmin Token (Opaque Token)：一种有状态鉴权。Token 本身仅是一串无意义的随机字符，必须将其存入服务器（如数据库或 Redis）。验证时需查表比对，支持随时强制注销。
  • JWT (JSON Web Token)：一种无状态鉴权。数据（如 UserID、过期时间）加密并签名后直接存储在 Token 字符串内，服务器无需查表，通过秘钥校验签名即可，但在过期前较难强制作废。

2. 核心区分：表单令牌 (__token__) vs 身份令牌 (Auth Token)

在传统框架转向前后端分离时，极易混淆两种 Token：

• __token__ (CSRF Token)：存在于 Session 中，主要用于防重放攻击和跨站请求伪造。在前后端分离的 API 设计中，建议移除此验证，改用限流（Rate Limiting）替代。
• Auth Token：用于用户身份标识。

3. 前后端分离实践规范

前后端分离时，抛弃传统的 Cookie 自动传递模式，转而采用 Header 显式传递：

1. 后端响应：登录成功后，不再执行 Cookie::set，而是将 $auth->getToken() 的结果通过 JSON 数据载体返回。
2. 前端存储与发送：前端提取 Token 存入 localStorage，并在后续请求的 HTTP Headers 中附带该 Token（如 token: xxxx）。
3. 后端校验：框架 API 基层拦截器通过 $this->request->header('token') 获取并查表校验身份。

模块四：Server-Sent Events (SSE) 在框架中的标准实现

1. 核心概念探讨：原生做法 vs 框架规范

• 用户视角与疑问：原生 PHP 的 SSE 实现（header() 配合 echo 与 flush）在 ThinkPHP 中是否适用？能否使用 response() 助手函数？
• 概念解释：SSE 是一种基于 HTTP 的单向长连接机制。原生 header() 输出会绕过框架的 Response 生命周期管理器，容易导致中间件失效或格式冲突。

2. 深层原理：输出缓冲 (Output Buffering) 的阻塞陷阱

SSE 要求数据“细水长流”，而现代 Web 架构存在多层缓冲机制：

• Nginx 代理缓存：Nginx 默认会积攒 PHP 的输出直到一定体积才发送给客户端。
• 解决机制：必须在响应头声明 X-Accel-Buffering: no 以强制 Nginx 放弃缓存，配合 PHP 的 ob_flush(); flush(); 机制，实现数据的即时穿透。
• Session 锁机制：PHP 会在脚本执行期锁定 Session 文件。由于 SSE 是长连接，不手动释放会导致同一用户的其他并发请求卡死。原理应用：在开启 SSE 循环前，必须调用 session_write_close() 释放文件锁。

3. 代码示例：ThinkPHP 中的 SSE 最佳实践

PHP

namespace app\index\controller;

use think\Response;

class Sse
{
    public function push()
    {
        // 1. 关闭 Session 锁，防止阻塞当前用户的其他请求
        session_write_close();

        // 2. 清理 PHP 缓冲区
        if (ob_get_level() > 0) {
            ob_end_clean();
        }

        // 3. 使用闭包接管 Response 流输出
        return Response::create()->header([
            'Content-Type'      => 'text/event-stream',
            'Cache-Control'     => 'no-cache',
            'Connection'        => 'keep-alive',
            'X-Accel-Buffering' => 'no', // 关键原理突破：禁用 Nginx 缓存拦截
        ])->code(200)->withStrings(function () {
        
            for ($i = 0; $i < 10; $i++) {
                $data = ['id' => time(), 'msg' => "Message {$i}"];
                // 严格遵循 SSE 数据格式
                echo "id: " . $data['id'] . "\n";
                echo "data: " . json_encode($data) . "\n\n";

                // 强制推入底层网络协议栈
                if (ob_get_level() > 0) { ob_flush(); }
                flush();
                sleep(1);
            }
        });
    }
}

模块五：AOP 思想与钩子 (Hook) / 行为 (Behavior) 机制

1. 核心概念：解耦业务的“切面”

• 用户视角与疑问：如何理解 TP 官方文档中关于 Hook 和 Behavior 的抽象描述？
• 概念解释：这是 AOP（面向切面编程）与观察者模式的应用。
  • 流程（传送带）：应用程序的执行生命周期（如请求解析、创建订单）。
  • 钩子 (Hook)：预埋在核心流程中的“广播节点”（如 after_order_created）。
  • 行为 (Behavior)：独立封装的业务插件（如“发短信”、“加积分”）。

2. 深层原理：低耦合、高内聚的实现机制

• 痛点：传统线性编程中，核心业务函数内会不断堆砌边缘业务代码，导致逻辑臃肿、极易出错。
• AOP 原理：通过 Hook::listen() 向外部抛出包含当前状态参数的事件信号。核心业务只需完成自身职责，无需关心谁去处理信号。独立的 Behavior 类通过配置文件或 Hook::add() 订阅该信号。系统运行时会自动路由执行关联的行为，实现业务逻辑的物理隔离。

3. 代码示例：重构订单业务流水线

A. 核心业务抛出钩子 (OrderController)

PHP

public function createOrder()
{
    $orderId = Order::insertGetId(['user_id' => 1, 'amount' => 100]);
    if ($orderId) {
        $params = ['user_id' => 1, 'order_id' => $orderId];
        // 原理运用：不关心后续操作，只广播“订单创建完毕”信号
        \think\facade\Hook::listen('after_order_created', $params);
        return json(['msg' => '下单成功']);
    }
}

B. 独立封装边缘业务 (Behavior)

PHP

namespace app\common\behavior;

class SendSmsBehavior
{
    public function run($params)
    {
        // 接收钩子抛出的上下文数据
        $order_id = $params['order_id'];
        // 执行独立短信发送逻辑...
    }
}

C. 建立映射关系 (tags.php 配置文件)

PHP

return [
    // 将行为挂载到特定的钩子节点上
    'after_order_created' => [
        'app\\common\\behavior\\SendSmsBehavior',
        'app\\common\\behavior\\AddScoreBehavior',
    ],
];

模块六：多层继承链与范围解析机制

1. 核心概念探讨：多层继承中的 parent:: 寻址规则

• 用户视角与疑问：在 祖父类 -> 父类 -> 子孙类 的多层继承结构（如 anm -> cat -> maomao）中，子孙类使用 parent:: 能否同时访问父类和祖父类的方法？
• 概念解释：
  • 严格单级指向：parent:: 严格且仅指向当前类的直接父类。它不具备直接越级指代祖父类的能力。
  • 方法重写（Override）的阻断效应：
    • 未重写（顺藤摸瓜）：如果直接父类没有定义同名方法，使用 parent:: 时，PHP 会沿着继承链自动向上回溯，直到在祖父类中找到该方法并执行。表面上找的是父类，实际执行的是祖父类的代码。
    • 已重写（规则阻断）：一旦直接父类重写了祖父类的方法，parent:: 的寻址就会在直接父类处强行终止。祖父类的原始方法被彻底“屏蔽”。

2. 深层原理：跨代强制调用与 $this 上下文传递

• 用户视角与疑问：为了打破父类的阻断，使用 祖父类名::方法名() 进行跨代强制调用时，如果该方法不是静态方法（static），是否必须先实例化祖父类？
• 深层机制剖析：在继承链内部，绝对不需要重新实例化！
  • 范围解析操作符 (::) 的双重面孔：在类外部使用 ClassName::method() 调用非静态方法会引发致命错误（Fatal Error），因为缺失对象上下文。但在继承链内部，这被称为范围指定调用。
  • $this 的“幽灵传递”：由于执行环境已经处于子孙类的实例（$this）中，当调用 祖父类名::方法名() 时，PHP 底层引擎会将当前子孙类的 $this 指针（即包含当前所有属性和状态的内存快照）原封不动地传递给祖父类的方法。这意味着，祖父类的方法是以当前子孙类对象的身份在运行。

3. 示例代码：跨代调用与实例状态验证

以下代码验证了如何越过父类，以及跨代调用时实例状态（$this）如何被完美继承和读取：

class Anm {
    public $name = "未知动物";
  
    public function cry() {
        // 原理验证：这里的 $this 并非指向 Anm 的新实例，而是直接复用调用者的实例
        echo $this->name . "：嗷呜~\n"; 
    }
}

class Cat extends Anm {
    public function cry() {
        echo $this->name . "：喵喵喵~\n"; // 重写了方法，形成了阻断
    }
}

class Maomao extends Cat {
    public function __construct() {
        // 实例化时，改变当前对象的数据状态
        $this->name = "小毛毛"; 
    }

    public function test() {
        // 核心运用：不使用 parent::，直接指定调用爷爷类的方法。
        // 此时绝不能写 new Anm()，底层自动将当前 Maomao 实例的 $this 传入。
        Anm::cry(); 
    }
}

$m = new Maomao();
$m->test(); 

// 最终输出：小毛毛：嗷呜~ 
// 深度解析：输出了"嗷呜"（证明跳过了 Cat 运行了 Anm 的逻辑），同时输出了"小毛毛"（证明操作的依然是 Maomao 实例化后的内存数据）。