swoole

Swoole中无open_cpu_affinity配置，实际生效的是process_cpu_affinity。开启后，每个Worker进程被绑定到独立CPU核心，但仅对Worker有效，且worker_num超过逻辑CPU数时失效。手动绑定更灵活，但在容器环境下需谨慎。可用ps命令检查绑定状态，避免配置未生效。

Swoole常驻内存模式下，全局变量、静态属性和容器实例因Worker进程持久化而跨请求残留，导致数据污染与内存泄漏。需手动重置或利用协程本地存储`Co::getContext()`隔离请求上下文，避免依赖`global`、`static`等进程级状态。

排查Swoole启动失败需按执行路径逐层排查：先确认CLI环境是否加载扩展，再检查端口占用和监听地址合法性，新版Swoole需强制指定SWOOLE_BASE模式，最后验证task_worker_num与onTask回调匹配，每一步都可能成为阻断点。

$server->setting是Swoole启动时的只读快照，用于查询实际生效的配置值，不可运行时修改，静默忽略赋值操作。Swoole会对worker_num、max_conn、log_level等参数自动修正。调试时应通过该属性定位配置差异，但需注意其反映的是启动瞬间状态，不保证生命周期一致性。

SwooleUDP服务器须显式指定SWOOLE_SOCK_UDP，否则默认为TCP。无onConnect/onClose事件，仅用onPacket接收。heartbeat、open_tcp_nodelay及粘包处理等配置无效。客户端无需connect，直接sendto发送。UDP无连接，可靠性需应用层自行保障。

Swoole协程上下文管理需使用Co::getContext()隔离数据，避免全局变量导致数据错乱。集成ThinkPHP时应通过Context类或手动绑定Request到协程上下文。多实例类可用spl_object_id构建嵌套结构，配合Trait封装。资源清理通过Co::defer注册回调，确保协程退出时释放文件句柄等外部资源。

max_wait_time是Swoole平滑重启的安全兜底阈值，仅在reload_async=true时生效。它并非等待时长，而是最多等待后强制终止旧Worker，导致未完成协程和异步I/O丢失。设置必须大于最长请求耗时，并匹配Nginx超时，建议HTTP场景10~30秒，长任务场景相应增大。

Swoole异步客户端并发基于事件循环、非阻塞I/O和回调调度，底层复用swoole_event机制。创建实例仅分配内存，需调用execute或connect触发网络行为。回调由内核驱动，并发受系统资源限制，如临时端口不足。通过复用连接及合理管理连接池可避免问题。

Swoole协程需手动进入上下文，采用协作式调度，IO操作让出，纯CPU循环会阻塞，单线程多进程模型天然无锁；Go协程默认在上下文中，抢占式调度，10ms超时强制切换，多线程调度需显式加锁，两者本质差异在于调度机制和上下文管理。

Swoole默认屏蔽所有信号，需在事件循环启动前通过SwooleProcess::signal在主线程注册信号回调，禁止在协程中使用。pcntl_signal在Worker进程无效。信号处理需注意Docker、systemd及OOMKiller等系统干扰，优雅退出应分阶段清理连接和协程。

Swoole通过epoll_create1创建epoll实例防泄漏，swoole_event_add用epoll_ctl注册fd并维护回调映射。epoll_wait阻塞让出CPU，零开销支撑高并发。默认水平触发，避免协程边缘触发数据残留卡死。

Swoole在task-ipc-mode=1模式下，投递数据序列化后超8KB会在/tmp创建临时文件且不自动清理，导致磁盘空间持续上涨。建议改用task-ipc-mode=2或3规避，或配置定时清理任务以释放空间。

Swoole的Task进程是内建异步任务工具，自动完成任务调度、负载均衡、超时控制及失败重启，并可触发onFinish回调。自定义进程需手动处理进程通信、崩溃恢复和负载均衡，无法触发onFinish，仅适用于与主循环完全解耦的长期驻留服务。多数场景应优先使用Task进程。

Swoole常驻内存环境下，数据库连接复用需配置连接池。要求Swoole≥4.8.0且think-swoole≥3.1.0，database.php中type设为mysql、deploy为0，禁用预处理模拟并删除持久连接配置。在provider.php绑定DatabasePool实例，大小按max_request×2估算。必须使用Db::pool()调用，以

Swoole的max_connection是进程级连接数上限，控制预分配内存和内部管理；系统ulimit-n是单进程文件描述符硬限制，决定连接物理天花板。两者不匹配时，Swoole启动会强制重置为ulimit-n值或有限制。调高ulimit需同步检查内核net.core.somaxconn等，否则仍可能连接受限。

Swoole的enable_preemptive_scheduler是协程抢占式调度开关，每约10毫秒强制中断CPU密集型协程，避免其他协程被饿死。开启后自动分配时间片，保证单线程下公平调度，虽有小额CPU开销，但显著降低P99延迟和超时率。需在启动前设置并先调用SwooleRuntime::enableCoroutine()，但无法解决未被hook的阻塞调

Swoole中协程异常需在协程内部捕获，跨协程try-catch无效。Worker进程崩溃时，需在workerStart中注册register_shutdown_function，结合error_get_last()获取致命错误。set_error_handler与set_exception_handler也需在Worker启动时重新注册，配合shutdow

Swoole协程调度机制性能更高的原因在于跳过了传统PHP-FPM的进程创建、脚本加载和内核态切换等三重开销。协程切换在用户态完成仅需50–200纳秒，共享内存免序列化，连接池复用TCP连接。实测QPS从1200提升至9800，延迟从186ms降至23ms。

SwooleBuffer专为TCP粘包、协议帧构造及二进制流暂存设计，非替代字符串的通用工具。适用于数据不完整接收、精确字节操作和高并发私有缓存场景。大量拼接时性能优于字符串，但不宜用于流式输出缓冲。

Swoole默认不拆包，TCP字节流需通过open_length_check（按长度）或open_eof_check（按结束符）配置边界。推荐固定包头协议，正确设置package_length_type、offset等参数，并注意避免长度类型与偏移量不匹配等错误。UDP和WebSocket不适用此拆包机制。

利用Swoole搭建高并发数据采集服务：协程TCP服务器降低延迟，onReceive仅收包并投递至Channel实现解耦。多分片并行io_uring落盘，按设备或时间切片，写入前计算BLAKE2b指纹。哈希链校验确保每记录不可篡改，段文件尾哈希比对实现全程可追溯。

Server->stats()返回分层、分角色、有时效性的快照值，字段对应Reactor/Worker/Task不同层级及进程级/全局级生命周期，混用易致监控失真。连接数、请求数、任务队列等统计口径各异，返回值无时间戳且不能跨进程聚合，需注意字段依赖编译配置。

Swoole的HTTP或WebSocket服务器默认不记录慢日志，需显式开启协程模式并配置slowlog和slowlog_file参数，阈值单位为毫秒（建议从100开始）。慢日志记录时间戳、协程ID、耗时、文件行号及顶层函数，不包含请求头或数据；缺失堆栈信息可能因debug_backtrace被禁用。