最常被忽略的“伪轻量操作”是os.walk()，它实际为每个文件调用stat()加载元数据，导致Windows Server上内存线性上涨；应改用pathlib.Path.rglob('*')或win32api.FindFirstFile。
脚本里用了 os.walk() 遍历大量文件
这是最常被忽略的“伪轻量操作”——os.walk() 看似只读目录结构，实际会为每个文件调用 stat() 系统调用，加载 inode、权限、时间戳等元数据。Windows Server 上若遍历含数万文件的路径（比如 C:\Program Files 或日志归档目录），内存中会堆积大量 stat 结构体缓存，且 Python 不主动释放底层 OS 缓存。
- 现象：内存随遍历深度线性上涨，任务管理器中“提交内存”持续增加，但
gc.collect()无效 - 验证方式：改用
subprocess.run(['dir', '/s'], capture_output=True)对比，发现内存增长明显更平缓（因不加载完整stat） - 替代方案：用
pathlib.Path.rglob('*')+try/except PermissionError跳过权限拒绝目录；或直接调用win32api.FindFirstFile（需安装pywin32），它只返回文件名，不触发stat
定时任务用了 schedule 模块 + while True 循环
schedule 本身不泄漏，但它依赖的 while True: schedule.run_pending(); time.sleep(1) 会在每次循环中累积内部任务队列引用，尤其当任务函数内创建了闭包、lambda 或绑定方法时，Python 会隐式持有对外层作用域对象的强引用。
- 典型症状：内存每小时缓慢爬升 5–10 MB，重启后归零，且
tracemalloc显示增长集中在schedule.py的_run_job调用栈 - 修复动作：把
schedule.every().hour.do(job)改成用threading.Timer或 Windows 原生任务计划程序（schtasks）触发，避免长生命周期的调度器实例 - 若必须用
schedule，在每次run_pending()后手动清空已执行任务：schedule.clear()（仅适用于单次任务）或显式重置schedule.jobs = []
全局变量或模块级缓存没做清理
自动化脚本常把配置、连接池、临时结果存成模块级变量（如 config = load_config() 或 db_conn = create_engine(...)），这些对象在脚本整个生命周期内都不会被 GC 回收，哪怕后续逻辑已不再使用。
- 特别危险的是日志类、数据库连接、HTTP 会话对象：它们内部持有很多缓冲区和回调引用
- 检查点：运行脚本前加
import gc; print(len(gc.get_objects()))，运行几小时后再打印，若数字持续上涨，说明有对象未释放 - 实操建议：把所有非必要全局状态转为函数局部变量；对必须复用的资源（如数据库连接），用
contextlib.closing()或with块包裹；避免在模块顶层执行耗资源初始化
Windows 上的内存回收机制不如 Linux 主动
Windows Server 默认不会像 Linux 那样积极回收用户态进程的空闲内存页，尤其当脚本频繁分配小对象（如字符串、字典）时，Python 的内存池（pymalloc）会保留已分配的 arena，表现为“内存占用高但实际没泄漏”。
立即学习“Python免费学习笔记（深入）”；
- 这不是 bug，是设计：Windows 更倾向保留内存供进程复用，降低系统调用开销
- 判断是否真泄漏：看“工作集（Working Set）”是否持续上涨；若“提交内存（Commit Size）”稳定，只是工作集高，可忽略
- 缓解手段：在循环关键点插入
gc.collect()（注意别太频繁，否则拖慢性能）；或启动时加-X dev参数启用调试模式，观察gc统计输出
tracemalloc 定位前 3 行高分配代码，比盲目加 del 有效得多。 
