Swoole中Server::$setting属性的使用方式

$server->setting 是只读快照，非配置入口；所有超时及运行参数必须在$server->start()前通过set()设置，启动后修改无效，且部分值会被自动修正。

Server::$setting 是只读的运行时配置快照

它不是配置入口，不能通过 $server->setting['xxx'] = ... 修改运行中的参数。Swoole 在启动后会把初始化时传入的 setting 数组深拷贝一份到 $server->setting，仅用于只读查询——比如调试时看实际生效了哪些值、确认是否被自动修正（如 worker_num 被限制为 CPU 核心数上限）。

常见误用是想动态调大 max_connection 或切换 dispatch_mode，这必然失败，且不会报错，只会静默忽略赋值。

• 修改配置必须在 new SwooleServer 或 new SwooleHttpServer 构造时传入 setting 数组
• $server->setting 中的值可能与你传入的不一致：例如设 'log_level' => 0，实际读出来可能是 5（因低于最低允许值被重置）
• 部分键名存在别名或自动映射，比如 daemonize 和 daemonize 都有效，但 $server->setting 中统一为小写 daemonize

哪些 setting 值启动后会被自动修正

Swoole 会对部分配置做合理性校验和强制修正，直接读 $server->setting 是发现这类问题最直接的方式。不检查这个属性，很容易以为配置生效了，结果行为异常却找不到原因。

• worker_num：若设为 0，会被改为 CPU 核心数；若超过 sysctl kern.maxproc（macOS）或 /proc/sys/kernel/pid_max（Linux），会被截断
• max_conn / max_connection：若大于系统 ulimit -n，会被设为 ulimit -n - 1024（预留文件描述符）
• log_level：只接受 0–5，超出范围会被 clamp 到最近合法值（如 6 → 5，-1 → 0）
• heartbeat_idle_time 和 heartbeat_check_interval：若后者大于前者，Swoole 会自动交换二者值，避免逻辑矛盾

用 $server->setting 查看真实生效配置的典型场景

线上服务出现连接拒绝、心跳失效或日志不输出时，第一反应不该是翻代码里写的配置，而是连上服务器，用 var_dump($server->setting) 看实际加载的值。很多问题根源就是配置被“悄悄”改了。

示例：你写了 'open_tcp_nodelay' => true，但抓包发现仍有 Nagle 算法延迟。此时查 $server->setting['open_tcp_nodelay']，如果返回 false，说明该选项仅对 TCP Server 生效，而你用的是 SwooleHttpServer（HTTP Server 默认不启用该选项，需显式设置）。

• HTTP Server 下 open_http2_protocol 默认 false，即使设置了 http2 扩展也无效，必须手动开启
• task_worker_num 若设为 0，$server->setting['task_worker_num'] 会是 0，但后续调用 $server->task() 会直接失败，而非降级到 worker 执行
• 使用 SWOOLE_BASE 模式时，dispatch_mode 固定为 1，无论构造时怎么设，$server->setting['dispatch_mode'] 都是 1

不要依赖 $server->setting 做运行时分支判断

有人会写 if ($server->setting['enable_reuse_port']) { ... } 来条件化逻辑，这是危险的。因为 enable_reuse_port 是否生效取决于内核支持（Linux ≥ 3.9）、端口权限、是否已绑定等，Swoole 只在真正成功启用后才把该字段设为 true，但它不保证之后一直有效（比如被其他进程抢占）。更稳妥的做法是捕获 bind() 失败或监听失败的异常。

• $server->setting 是启动瞬间的快照，不代表整个生命周期的状态一致性
• 像 ssl_cert_file 这类路径配置，即使 $server->setting 里有值，也不代表文件可读或证书格式正确——这些只有在真正 accept SSL 连接时才校验
• 某些配置如 buffer_output_size 在不同版本 Swoole 中含义不同（v4.8+ 改为 per-connection，之前是全局），光看 $server->setting 无法判断行为差异，必须结合版本号

真正需要动态感知的配置变化，应该通过事件回调（如 onStart 中记录初始值，onWorkerStart 中验证资源就绪）或外部信号控制，而不是反复读 $server->setting。