resource.setrlimit调用后没效果，是因为它仅约束后续mmap/brk系统调用，无法回溯限制已分配内存；cpython的pymalloc预分配内存池、glibc缓存及线程共享地址空间导致限制延迟生效或被掩盖，必须在进程早期、子进程中设置rlimit_as才可靠。
resource.setrlimit 为什么调用后没效果？
因为 resource.setrlimit 只能限制当前进程及其后续 fork 出的子进程，不能 retroactively 限制已存在的线程或已分配的内存；更关键的是，它对 Python 层面的内存分配（如 list、dict）无直接约束——Python 的堆内存由解释器管理，而 RLIMIT_AS 或 RLIMIT_DATA 作用在 mmap/malloc 系统调用层面，实际触发限制往往比预期晚，甚至被 glibc 缓存掩盖。
常见误判场景：你设了 RLIMIT_AS 为 100MB，但 [0] * 100_000_000 仍能成功——这是因为 CPython 先从 glibc 的 arena 分配，未立即触达内核限制。只有当进程尝试映射新虚拟内存页且超出硬限（hard limit）时，malloc 才返回 NULL，进而让 Python 抛出 MemoryError。
- 必须在程序早期调用，最好在导入任何大模块前执行
- 软限（soft limit）可被进程自行提升（只要不超硬限），硬限（hard limit）需 root 权限才能提高
-
RLIMIT_AS（地址空间）比RLIMIT_DATA（数据段）更可靠，后者不包含堆栈和 mmap 区域
RLIMIT_CPU 和 RLIMIT_FSIZE 怎么精准生效？
RLIMIT_CPU 是少数真正“准时”触发的限制：内核每秒检查一次累计用户态 + 内核态 CPU 时间，达到软限时发 SIGXCPU（默认终止进程），再超 1 秒仍未退出则发 SIGKILL；RLIMIT_FSIZE 在 write() 超限时直接返回 EFBIG，Python 的 file.write() 会转为 OSError。
注意：RLIMIT_CPU 不统计 sleep 时间，也不限制子进程 CPU 时间（除非显式继承）；RLIMIT_FSIZE 对已打开的文件句柄有效，但对 /dev/null 或管道无效。
- 捕获
SIGXCPU需用signal.signal(signal.SIGXCPU, handler)，且 handler 应尽量轻量 - 设置
RLIMIT_FSIZE后，用open(..., 'a')追加写入超限时抛OSError: [Errno 27] File too large - 硬限设为 0 表示禁止创建新文件（但已有文件仍可读）
Linux 下哪些 resource 项实际可用？
不是所有 resource.RLIMIT_* 常量在所有系统都有效。例如 RLIMIT_RSS 在现代 Linux 中已被忽略（内核 2.6.32+ 默认禁用），RLIMIT_NPROC 控制的是该 UID 下进程数，不是当前进程的线程数；RLIMIT_NOFILE 限制打开文件描述符总数，包括 socket、pipe、eventfd 等，超限时 open() 或 socket() 直接失败。
-
RLIMIT_NOFILE软限低于 1024 时，Python 的logging模块可能因无法打开日志文件而静默失效 -
RLIMIT_MEMLOCK影响mlock()调用，与mmap(..., MAP_LOCKED)相关，普通应用极少需要调整 - macOS 不支持
RLIMIT_RTPRIO和RLIMIT_SIGPENDING，尝试设置会报ValueError: not supported on this platform
如何验证 resource 限制是否真的起作用？
别只信 resource.getrlimit() 返回值——那只是当前设置，不代表内核已 enforce。最直接的方式是主动触发边界行为：
import resource
resource.setrlimit(resource.RLIMIT_FSIZE, (1024, 1024)) # 1KB 文件大小限制
with open('test.bin', 'wb') as f:
f.write(b'x' * 2000) # 触发 OSError: [Errno 27] File too large
或者用 ps -o pid,vsz,rss,pcpu,comm -p $PID 对比限制前后内存/CPU 增长速率；对 RLIMIT_CPU，可故意跑一个死循环并观察是否在设定秒数后被杀。
-
resource.getrusage(resource.RUSAGE_SELF)能查到当前进程真实消耗（如ru_maxrss单位是 KB），比getrlimit更反映实际 - 容器环境（Docker/K8s）中，cgroup 限制优先级高于
setrlimit，此时setrlimit可能被静默截断 - 多线程程序里，
RLIMIT_STACK限制的是主线程栈，每个新线程栈大小由threading.stack_size()控制，不走 rlimit
真正难控的是 Python 对象生命周期和引用计数延迟释放——setrlimit 是操作系统层的刹车，但你得自己先踩住 Python 层的油门。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
