用途：为在 systemd MemoryMax 约束下长期运行的 Python 脚本提供内存安全实践模式，资料来自 24 工作线程并行修复脚本与每日行情播种脚本，历经 5 轮 OOM 优化。核心观点：Python 垃圾回收释放对象，但 C 分配器（glibc ptmalloc2）不会把空闲页归还操作系统，缺少显式 malloc_trim(0) 时 RSS 只增不减；使用 mimalloc 时 glibc 的 malloc_trim 无效，应改用 mi_collect(True)。
主要能力（7 种模式）：1）缓存分配器回收库句柄，首次调用确定 mimalloc/glibc，避免循环内重复 CDLL 导致 dlopen 分配；2）HTTP 响应提取内容后立即 close 并 del，避免连接池与响应体堆积；3）对大于约 1 MB 的对象（DataFrame、字节串、ZIP、日期列表）显式 del；4）GC 节奏：工作单元内每 50 次迭代调用一次强制 GC，工作单元之间也调用；5）线程池退出后 del 待处理对象并强制 GC，必要时显式关闭线程本地资源；6）用 threading.local() 每工作线程复用数据库连接或 HTTP 会话，避免文件描述符耗尽；7）systemd 配置 MemoryHigh、MemoryMax、MemorySwapMax=0，LD_PRELOAD 指向 libmimalloc.so.2 并设置 MIMALLOC_PURGE_DELAY，配置 OOMScoreAdjust 与 ManagedOOMMemoryPressure。
使用方式：在脚本中按需引入缓存句柄的 _force_allocator_purge 与 _force_gc，按迭代与工作单元两个层级调用；service 文件写入上述内存与预加载环境变量；出现 SIGKILL 时按诊断清单检查 OOM 日志、峰值 RSS、稳态 RSS、fd 数量与分配器。
适用场景：systemd 托管的并行数据修复、行情缓存播种等长时间高并发 Python 任务。限制：示例仅在 Linux 下生效；文中给出的 RSS 数值、50 次迭代等参数为特定工作站实测经验值；其他平台与场景未提供结论。