Swoole Worker进程不响应ini_set('memory_limit')，因其常驻内存导致PHP内存管理模型已固化，该调用静默失败；真实内存限制源于操作系统RLIMIT_AS/RLIMIT_DATA，而非PHP配置。
为什么Swoole Worker进程不响应ini_set('memory_limit')？
因为Swoole的Worker进程是常驻内存的，启动后PHP的内存管理模型（包括memory_limit）已固化。ini_set('memory_limit', '1G')在FPM或CLI中有效，但在Swoole Worker里调用会静默失败——它既不报错，也不生效。你可以在onRequest里打印ini_get('memory_limit')验证，值始终是启动时php.ini设定的那个。
Swoole中真正的内存限制来自哪里？
不是PHP配置项，而是操作系统对单个进程的RLIMIT_AS（虚拟内存上限）和RLIMIT_DATA（数据段大小）。Swoole Worker作为长期运行的PHP进程，其总内存占用 = PHP堆内存 + 共享内存（Swoole\Table、Swoole\Memory\Map）+ 协程栈 + 扩展私有内存（如Redis扩展的连接缓冲区）。
常见误判点：
- 把
Allowed memory size of X bytes exhausted错误归因于Swoole，实际是PHP脚本在Worker内反复执行导致内存累积泄漏 - 调高php.ini里的
memory_limit却没重启Swoole服务，新配置根本没加载 - 用
memory_get_usage(true)测的是当前PHP堆使用量，但Swoole\Table分配的共享内存不计入其中
如何监控Swoole Worker的真实内存压力？
必须组合多个指标，不能只看memory_get_usage()：
立即学习“PHP免费学习笔记（深入）”；
- 用
memory_get_usage(true)和memory_get_peak_usage(true)跟踪PHP堆变化（true参数才统计真实系统分配） - 定期调用
swoole_memory_dump()（需启用--enable-swoole-memory-dump编译选项）查看共享内存块分布 - 检查
/proc/<pid>/status</pid>里的VmRSS（物理内存占用）和VmSize（虚拟内存总量） - 配合
Coroutine::count()和gc_collect_cycles()观察协程数与GC回收率是否异常
一个Worker进程持续增长到超过512MB且不回落，基本可判定存在缓存未清理、静态变量堆积或闭包捕获大对象等问题——这时加memory_limit只是拖延崩溃时间。
