PHP 原理大纲

这份不是“会不会写 PHP”的大纲，而是“PHP 在后端系统里到底是怎么工作的，以及为什么它适合你这类复杂业务系统”。

一、总纲

PHP 原理层最核心的 5 条主线：

  1. 运行模型
  2. 请求生命周期
  3. 进程管理与 PHP-FPM
  4. 代码组织与框架机制
  5. 复杂业务系统里的优势与边界

二、PHP 运行模型

1. PHP 本质是什么

PHP 本质上是解释执行的服务端脚本语言。 在 Web 场景里，通常是每次请求来到时由 PHP-FPM 拉起 worker 执行脚本，请求结束后释放大部分运行态。

2. PHP 的经典模型是什么

经典模型是：

  • 请求进来
  • 初始化运行环境
  • 执行业务逻辑
  • 输出响应
  • 请求结束后释放运行上下文

这种模型的好处是：

  • 简单
  • 稳定
  • 请求之间默认隔离
  • 不容易因为内存状态污染彼此

坏处是：

  • 每个请求都会重复初始化一部分资源
  • 不适合天然长连接场景

3. 为什么这个模型适合复杂业务后台

因为复杂业务系统更看重：

  • 规则实现效率
  • 团队协作效率
  • 请求之间状态隔离
  • 问题容易收敛

你可以把这个挂回自己项目：

像订阅、支付、退款、后台、活动、规则配置这种复杂业务，不一定最追求单请求极限性能，反而更看重落地效率和可维护性。

三、Nginx + PHP-FPM 请求链路

1. 链路是什么

典型链路是：

  1. 客户端请求到 Nginx
  2. Nginx 判断静态资源还是动态请求
  3. 动态请求通过 FastCGI 转给 PHP-FPM
  4. PHP-FPM 选一个 worker 执行脚本
  5. 执行结果返回 Nginx
  6. Nginx 再返回客户端

2. Nginx 和 PHP-FPM 分别干什么

Nginx

  • 连接接入
  • 路由
  • 静态资源处理
  • 反向代理
  • 转发 PHP 动态请求

PHP-FPM

  • 管理 PHP worker 进程
  • 执行 PHP 脚本
  • 控制并发 worker 数量

3. 面试可延伸点

  • 为什么 PHP-FPM 会打满
  • max_children 是什么
  • 慢请求怎么查
  • 为什么不是 Nginx 一层就够了

四、PHP-FPM 原理重点

1. PHP-FPM 是什么

PHP-FPM 是 FastCGI Process Manager。 它的核心价值不是“让 PHP 能跑”，而是：

  • 管理 worker 进程
  • 控制并发
  • 提高稳定性
  • 支持慢日志、平滑重启、池化管理

2. 为什么要用进程池

因为 PHP Web 请求本质上要靠 worker 去执行。 如果每次请求都临时起一个 PHP 进程，成本太高；如果完全没有上限，又容易打爆机器。 所以需要进程池去做平衡。

3. 常见模式

  • static
  • dynamic
  • ondemand

4. 面试时怎么理解“FPM 打满”

本质上是请求执行速度和到达速度失衡。 可能原因是：

  • 慢 SQL
  • 外部依赖超时
  • 代码逻辑太重
  • worker 数不足
  • 突发流量

所以“调大 max_children”只是手段，不是根因修复。

五、PHP 框架机制原理

这一块你不需要背框架源码，但要理解框架在解决什么问题。

1. 路由

把 URL / method 映射到控制器或处理函数。

2. 中间件

在请求真正进入业务逻辑前后做统一处理，比如：

  • 鉴权
  • 日志
  • 限流
  • 参数校验

3. IOC / DI

通过依赖注入把“接口”和“实现”解耦，降低耦合度，方便替换和测试。

4. Service / Repository / Domain 分层

不是为了好看，而是为了：

  • 让业务规则不要散落在 controller
  • 让复杂逻辑更集中
  • 让测试和扩展更容易

5. 配置与容器

框架通过配置文件和容器，把系统中的公共能力组织起来。

六、autoload 与代码组织

1. Composer autoload 在解决什么问题

解决类加载问题，让代码按命名空间和目录规则组织起来，而不是手写 include / require。

2. PSR-4 的意义

核心不是记规范，而是：

  • 目录结构清楚
  • 命名空间统一
  • 代码组织可维护

这对大型项目尤其重要。

七、复杂业务系统里为什么 PHP 仍然合理

核心答案

因为 PHP 在复杂业务后端里，优势不是“语法简单”，而是：

  • 业务落地快
  • 团队协作成熟
  • 请求隔离天然清晰
  • 生态成熟
  • 后台系统和业务系统开发效率高

你的项目里怎么讲

海外业务平台

  • 订阅
  • 支付
  • 退款
  • 权益同步
  • 后台和运营配置

这些都属于规则复杂、协作密集、迭代频繁的系统，PHP 很合适。

核心业务链路

  • 活动
  • 小程序
  • 商家
  • 交易

也都偏复杂业务落地，而不是极致高并发纯计算服务。

八、PHP 的边界

这一段很重要，能体现你不是盲目站队。

PHP 不擅长的典型场景

  • 长连接
  • 极高并发实时处理
  • 大量消费者常驻服务
  • 重 IO 并发协程场景

所以怎么做

你的最佳回答是：

我不会让 PHP 承担所有角色。 复杂业务主链路、后台和规则配置继续放 PHP； 实时链路、高并发消费者、长生命周期服务拆到 Go。 这是我项目里一直在做的分工方式。

九、你最应该能顺着讲出的原理链

你至少要能完整顺着讲出这条链：

请求 -> Nginx -> FastCGI -> PHP-FPM -> worker 执行脚本 -> 框架路由/中间件 -> service 层业务逻辑 -> MySQL/Redis/外部服务 -> 响应返回

只要这条链你讲顺了，PHP 原理层就不会显得空。

十、最适合你的结尾表达

我对 PHP 的理解，不是停留在语法和 CRUD，而是理解它在 Web 后端里的运行模型、进程池方式和框架分层方式，也知道它最适合承接什么类型的业务。对我来说，PHP 不是“落后语言”，而是复杂业务系统里非常高效的一层。