Swoole 无隐藏参数，仅存在文档未强调但实际生效的底层配置项，主要分布在 set() 方法中（如 ssl_cert_file），需绝对路径且必须配对设置；worker_num 和 max_coroutine 等参数需根据 CPU、内存及 stack_size 协同调整。
怎么查 Swoole 隐藏配置参数
没有所谓“隐藏参数”，只有未被文档重点标注、但实际生效的底层配置项。Swoole 的配置分三层：PHP INI（swoole. 前缀）、Server/Client 构造参数、运行时 set() 方法。很多“找不到”的参数其实藏在第三层——比如 ssl_cert_file 在 set() 里才有效，INI 里写无效。
实操建议：
- 用
php --ri swoole看当前编译选项和 INI 支持项，注意哪些标了Available却没出现在官方配置表里 - 翻源码时直奔
swoole_server.cc和swoole_http_server.cc中的set_property分支，里面if (strcmp(key, "xxx") == 0)的 key 就是真实可设参数 - 不确定是否生效？启动后调用
$server->getSetting()打印出来看，它返回的是最终合并后的配置，比文档更真实
ssl_* 类参数为什么总不生效
因为 Swoole 的 SSL 配置只在 set() 中起作用，且必须在 start() 前调用；写在 INI 里或构造参数里一律被忽略。更坑的是，部分参数（如 ssl_cert_file）还要求路径必须是绝对路径，相对路径不会报错但静默失败。
常见错误现象：
- HTTPS 服务启动成功，但浏览器提示“证书无效”或直接断连
-
var_dump($server->getSetting())里看不到ssl_*字段 - 用
openssl s_client -connect测试返回SSL handshake failed
实操建议：
- 确保
ssl_cert_file和ssl_key_file是绝对路径，用realpath()处理一下再传 - 必须配对设置：
ssl_cert_file+ssl_key_file，缺一不可；若用双向认证，还得加ssl_ca_file和ssl_verify_peer - PHP 版本低于 7.4 时，
ssl_method只能填TLSv1_2_method，填TLSv1_3_method会静默降级
worker_num / task_worker_num 设多大才不翻车
不是越大越好。Swoole 进程数受系统 ulimit -n、内存、CPU 核心数三重限制。设太高会导致 Fork failed: Resource temporarily unavailable 或启动卡死；设太低又压不住并发。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
性能影响关键点：
-
worker_num每个进程独占约 2–5MB 内存（取决于协程栈大小），100 个 worker 就吃掉近 500MB -
task_worker_num超过 CPU 核心数 2 倍后，上下文切换开销明显上升，吞吐反而下降 - 如果开了
enable_coroutine => true，worker_num推荐设为 CPU 核心数 × 2～4，而非传统 PHP-FPM 的 ×8～16
实操建议：
- 先用
cat /proc/cpuinfo | grep processor | wc -l查核心数，初始值设为cpu_count * 3 - 压测时紧盯
top的 %CPU 和 %MEM，以及swoole_server->stats()中的tasking_num—— 如果长期 >0，说明 task worker 不够用 - 别迷信自动扩容，Swoole 不支持运行时增减 worker 数，改完必须重启
max_coroutine 和 stack_size 容易一起搞崩
这两个参数强耦合：stack_size 越大，单个协程内存占用越高，max_coroutine 就得越小，否则直接 OOM。但设太小又容易触发 coroutine stack overflow 错误，尤其在深度递归或大量嵌套协程调用时。
常见错误现象：
- 请求偶尔 502，日志里出现
Segmentation fault或coroutine#X stack overflow -
swoole_server->stats()中coroutine_num长期接近max_coroutine，但 CPU 利用率很低
实操建议：
- 默认
stack_size = 2M对大多数业务够用；若用到curl_multi或大量 JSON 解析，可降到1M，同时把max_coroutine提到 3000～5000 - 调试阶段加
hook_flags => SWOOLE_HOOK_ALL后，协程栈消耗明显增加，此时务必同步调大stack_size - 上线前用
strace -e trace=brk,mmap,clone跟一次请求，确认没频繁 mmap 新栈空间——那是栈不够的信号
真正难调的不是单个参数，而是它们之间的比例关系。比如改了 stack_size 没动 max_coroutine，或者调高 worker_num 忘了算总内存上限，这种组合问题最耗时间。
