PHP架构本质是围绕运行时、请求生命周期与组件协作的实践模式，需先理解SAPI层触发机制、自动加载原理、会话存储机制及环境链路问题，而非直接学习抽象概念。
PHP 架构不是一门独立语言，而是一套围绕 PHP 运行时、请求生命周期和组件协作方式形成的实践模式。新手直接啃“架构”只会卡在抽象概念里，真正要先搞懂的是：谁在调用 php-fpm？$_GET 从哪来又到哪去？require_once 和自动加载之间差了哪一层？
HTTP 请求进来后，PHP 真正执行的第一行代码在哪？
不是你写的 index.php，而是 Web 服务器（如 Nginx）把请求转给 php-fpm 后，php-fpm worker 进程载入并执行的入口脚本。这个过程没有“全局主函数”，只有「SAPI 层触发」——比如 apache2handler 或 fpm-fcgi SAPI 初始化 PHP 执行环境，然后才轮到你的代码。
-
phpinfo()输出里的Server API行，就是当前实际起作用的 SAPI 类型 - Nginx 配置中
fastcgi_pass 127.0.0.1:9000对应的就是php-fpm的监听地址，断开它，所有 PHP 页面立刻 502 - CLI 模式下运行
php script.php走的是cliSAPI，不经过 Web 服务器，也没有$_SERVER['REQUEST_URI']这类变量
为什么 autoload 不是“自动包含文件”，而是靠 spl_autoload_register() 注册回调？
PHP 解析器本身不识别命名空间与文件路径映射关系。new App\Controllers\UserController 报 Class not found，不是因为没写 require，而是没人告诉 PHP “这个类名应该去哪个路径找”。
- Composer 自动生成的
vendor/autoload.php本质就是一堆spl_autoload_register()回调，每个回调负责一段命名空间前缀 - 手写自动加载时，若在回调里用
include而非require，类文件不存在会导致静默失败，后续报错会更难定位 - PSR-4 标准规定
App\Foo\Bar映射到src/Foo/Bar.php，但这个规则不是 PHP 内置的，是 autoloader 实现者自己解析字符串实现的
$_SESSION 数据到底存在哪？为什么刷新页面有时就丢了？
默认存在服务器本地文件系统（/tmp 下的 sess_* 文件），由 session.save_handler = files 控制。丢失通常不是代码问题，而是环境链路断裂：
立即学习“PHP免费学习笔记（深入）”；
-
浏览器未携带
PHPSESSIDCookie（可能被同站策略拦截，或前端 JS 创建了新上下文） -
session_start()前有输出（哪怕一个空格），导致 HTTP Header 无法写入 Set-Cookie - 开发时多个标签页共用会话，一个调用
session_destroy()，其他页立即失效 - 生产环境改用 Redis 存储时，
session.save_path必须设为tcp://127.0.0.1:6379?database=1这类 DSN 格式，不能只写 IP
ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://127.0.0.1:6379?database=1');
session_start(); // 必须在修改 ini 设置后、任何输出前调用
架构感是在反复调试 502 Bad Gateway、查 php-fpm.log 里 child process exited on signal 11、翻 strace -p 看 PHP 进程卡在哪个系统调用之后，慢慢长出来的。别从“微服务”“DDD 分层”开始，先确认你能用 curl -v 看清一次请求完整流经 Nginx → php-fpm → index.php → PDO → MySQL 的每一步响应头和状态码。
