ThinkPHP6稳定扛住1万QPS需四层协同调优：PHP层启用OPcache（512MB）、调大realpath缓存；Nginx层设worker_connections=20480、keepalive_timeout=65；数据库层配置pool_size=200或读写分离；缓存层采用本地+Redis多级，定时预热热点数据并防护穿透。
ThinkPHP6 要稳定扛住 1 万并发请求，单靠框架默认配置远远不够。核心不在“加多少服务器”，而在于 PHP 层、Nginx 层、数据库层和缓存层的协同调优。实测从每秒 100 请求提升到 10000 QPS，关键参数必须精准设置，漏掉任意一环都可能卡在 2000 或卡死在 5000。
PHP 运行时关键参数（php.ini）
这些不是“建议开启”，而是高并发下必须调整的硬性配置：
- OPcache 必须启用且足够大：opcache.enable=1、opcache.memory_consumption=512（单位 MB）、opcache.max_accelerated_files=20000、opcache.revalidate_freq=60；禁用 opcache.validate_timestamps 在生产环境（设为 0），否则每次请求都检查文件修改时间，直接拖垮性能
- realpath 缓存要拉满：realpath_cache_size=8192K、realpath_cache_ttl=7200；TP6 路由和自动加载频繁查路径，小缓存会导致大量系统调用
- 禁用调试与错误报告：display_errors=Off、log_errors=On、error_log=/www/wwwlogs/php_error.log；APP_DEBUG=false 必须写在 .env 中，否则框架会加载大量调试类并记录日志
- 内存与执行限制放宽：memory_limit=512M（非无限，避免 OOM 杀进程）、max_execution_time=30（接口超时由 Nginx 控制，PHP 层不宜过长）、post_max_size=32M、upload_max_filesize=32M（按业务需要）
Nginx 高并发连接配置
PHP 能撑住不代表 Nginx 能转发过去。Nginx 是第一道闸口，配置不当会直接丢包或排队：
- worker 进程与连接数匹配：worker_processes auto;（推荐值 = CPU 核心数）；worker_connections 20480；总并发能力 ≈ worker_processes × worker_connections
- 保持连接与超时控制：keepalive_timeout 65；keepalive_requests 10000；client_header_timeout 15；client_body_timeout 15；避免连接频繁建连断连
- 启用 Gzip 但不过度压缩：gzip on; gzip_types application/json text/plain text/css application/javascript; gzip_min_length 1024; gzip_comp_level 4；压缩等级超过 6 会明显增加 CPU 消耗
- 反向代理缓冲区加大：proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k；防止大响应体阻塞 worker
数据库连接与读写分离配置
1 万并发下，MySQL 单点连接池极易打满。TP6 的读写分离不是开关，是结构化配置：
立即学习“PHP免费学习笔记（深入）”；
- 连接池 size 必须显式设大：在 config/database.php 的 mysql 连接中，'pool_size'=>200（Swoole 环境）或 'deploy'=>1 + 'rw_separate'=>true + 'read'=>[...] + 'write'=>[...]；注意 write 必须是单层数组，read 必须是二维数组
- 主从延迟容忍策略：对一致性要求不高的列表页，用 Db::connect('slave_db')->table(...)；对强一致操作（如支付、库存），强制走 write 连接，避免跨库事务
- 预编译与连接复用：PDO 默认开启 prepare，但需确认 'params'=>[\PDO::ATTR_PERSISTENT => true] 已配置（仅限 MySQL 连接池场景，慎用于短连接）
- 慢查询与连接监控：开启 slow_query_log，long_query_time=0.2；配合 pt-query-digest 分析高频低效 SQL，重点优化带 JOIN 和子查询的接口
多级缓存与热点预热机制
10000 QPS 下，95% 的请求不该触达数据库。缓存不是“加 Redis 就行”，而是分层兜底：
- 本地缓存 + 分布式缓存组合：Cache::store('file')->get($key) 先查本地（毫秒级），未命中再查 Cache::store('redis')->get($key)；避免所有请求都打 Redis 网络层
- 缓存键设计带业务维度：不要用简单 md5(serialize($params))，改用 user_id:profile:20260817、article:12345:summary 等可读+可清理格式
- 定时预热核心数据：在 command/schedule.php 中添加 hourly() 任务，预加载首页 Banner、热门标签、用户基础信息等，用 Cache::remember('hot_user_list', 3600, fn()=>Db::name('user')->where('status',1)->limit(100)->select())
- 缓存穿透防护：对空结果也缓存（如 Cache::set('user:999999', null, 60)），配合布隆过滤器拦截非法 ID 查询（可选增强）
