PHP高并发崩溃主因是资源耗尽，需通过FPM限流、数据库连接管理、Session优化、文件操作规范及代码效率提升来防控。
PHP 应用在高并发下崩溃，通常不是因为代码写错了，而是资源没管住——CPU、内存、数据库连接、文件句柄、PHP-FPM 子进程全被耗尽。避免崩溃的关键，是提前设限、分层拦截、快速失败。
PHP-FPM 配置必须调紧：防止子进程雪崩
默认的 pm.max_children 常设为 50 或更高，但没结合服务器内存和单请求内存占用评估，极易导致 OOM Kill。一个 128MB 内存的 PHP 请求，开 50 个子进程就吃掉 6.4GB 物理内存。
-
pm = static或pm = dynamic要按实际负载选；静态模式更可控，动态模式需严控pm.start_servers、pm.min_spare_servers、pm.max_spare_servers - 务必设置
pm.max_requests = 500（或 100–1000 区间），防止长时间运行积累内存泄漏 - 开启
pm.status_path = /status，配合curl http://127.0.0.1/status?full实时看活跃进程数和请求数，别等报警才查 - 加
request_terminate_timeout = 30s和request_slowlog_timeout = 10s，超时强杀 + 记慢日志，防个别请求卡死整个 worker
数据库连接池不够用？先砍连接、再缓存、最后降级
每个 PHP-FPM 进程默认会独占一个 MySQL 连接，max_children=30 就可能打满 MySQL 的 max_connections。崩溃常始于 “Too many connections” 错误。
- PHP 侧用
mysqli::close()或$pdo = null显式释放连接，别依赖脚本结束自动回收 - 读多写少场景，强制走
Redis或APCu缓存，加cache-control: public, max-age=60减少重复请求穿透 - 写操作加
try/catch捕获PDOException，遇到SQLSTATE[HY000] [2002]（连接拒绝）或SQLSTATE[08004]（连接数超限）立即返回 503 +Retry-After: 1 - 关键接口（如下单）前置 Redis 分布式锁 + 计数器限流，例如
INCR order_limit:20240520+EXPIRE，超阈值直接拒单
文件操作和 session 是隐藏瓶颈
默认文件型 session（session.save_handler = files）在高并发下会产生大量磁盘 I/O 和文件锁争用，session_start() 可能阻塞数秒，连带拖垮整个请求链路。
立即学习“PHP免费学习笔记（深入）”；
- 切到
redis或memcached存 session：session.save_handler = redis，session.save_path = "tcp://127.0.0.1:6379?database=1" - 非必要不开启 session：登录页、API 接口若无需登录态，加
if (!session_status() == PHP_SESSION_ACTIVE) { session_write_close(); }提前关闭写锁 - 上传临时文件目录（
upload_tmp_dir）必须指向高速 SSD 分区，且open_basedir不要限制过死，否则move_uploaded_file()失败静默卡住 - 避免在循环里反复
fopen()日志文件，改用error_log()或 Monolog 的 stream handler + buffer
别信“加机器就能扛”，先看 PHP 自身是否在浪费资源
很多崩溃其实源于低效代码：未关闭的 GD 图像资源、递归无终止、file_get_contents() 读大文件、json_decode($huge_json, true) 解析百 MB JSON——这些不会报错，但会让单个请求吃光内存然后被 FPM 杀掉。
- 上线前用
xdebug.profiler_enable_trigger抽样分析慢请求，重点关注memory_get_peak_usage()和函数调用深度 - 对大数组处理，用
yield改写为生成器，比如分批导出 CSV 时不要array_map()全加载进内存 - 禁用
allow_url_fopen和危险函数（exec,system,shell_exec），防止被注入后 fork 出一堆僵尸进程 - Web 服务器层加简单限流：Nginx 用
limit_req zone=api burst=10 nodelay，Apache 用mod_evasive，比 PHP 层拦截更早生效
真正难防的不是流量峰值，而是那些没设 timeout 的外部 HTTP 调用、没配 connect_timeout 的 cURL、没加 SET LOCK_TIMEOUT 的 PostgreSQL 查询——它们会让 PHP 进程挂着不动，悄无声息吃光所有 worker。
