LocMemCache 是 Django 基于内存和线程本地存储的缓存后端，适合开发调试、单进程部署及短生命周期数据缓存；不适用于多进程部署或需跨实例共享的场景。
LocMemCache 是什么，适合哪些场景
Django 的 LocMemCache 是基于 Python dict 和线程本地存储实现的内存缓存后端，所有数据只存在当前进程内存里，不跨进程、不持久、不共享。它适合开发调试、单进程部署（如 runserver）、或缓存生命周期极短（秒级）、且无需多实例一致性的数据，比如模板片段、视图中间计算结果、临时 token 校验状态。
不适用于：多 worker 部署（如 Gunicorn 多进程）、需要跨请求共享缓存、或要求高命中率和长期稳定的场景——因为每个进程都有独立缓存副本，更新不同步，且重启即丢。
怎么在 settings.py 里正确配置 LocMemCache
Django 默认不启用任何缓存，必须显式配置 CACHES。LocMemCache 不依赖外部服务，但有几个关键参数容易被忽略：
-
BACKEND必须设为'django.core.cache.backends.locmem.LocMemCache' -
LOCATION可选，用于区分多个缓存实例（如'default'或'session_cache'），同一LOCATION下的缓存键才共享 -
OPTIONS中的'MAX_ENTRIES'默认是 300，超限后会触发 LRU 清理；如果缓存大量小对象，建议调大（如 1000） - 不支持
TIMEOUT全局默认值设为None（永不过期），但实际仍受内存回收和 MAX_ENTRIES 影响
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'default',
'OPTIONS': {
'MAX_ENTRIES': 1000,
}
}
}
用 cache.set / cache.get 时要注意什么
LocMemCache 行为和 Redis 缓存看似一致，但有几处关键差异：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 缓存键必须是字符串；传入
int、list、dict会静默失败或报TypeError（Django 会尝试序列化，但 LocMem 不强制要求可序列化，某些复杂对象可能出错） -
timeout参数为0表示“不过期”，但实际仍受MAX_ENTRIES限制，不是真正永久 - 多线程下安全，但多进程间完全隔离——你在 Gunicorn 启 4 个 worker，就有 4 份互不通信的缓存
- 使用
cache.add()时，如果键已存在，返回False且不覆盖；而cache.set()总是写入，这点和其他后端一致
常见错误现象：cache.get('user_123') 总是返回 None，但确认代码执行了 set——大概率是进程不一致（比如用 runserver 测试正常，上线后换 Gunicorn 就失效）。
怎么验证 LocMemCache 是否生效
别只看逻辑是否跑通，要确认缓存真被用了：
- 开启 Django 日志，把
django.core.cache设为DEBUG级别，能看到每次get/set的 key 和结果 - 在视图中加简单计数器：
cache.incr('hit_count', 1, default=0)，然后访问两次，看是否从 1 变成 2（注意：LocMemCache 支持incr，但仅限整数，且只在当前进程有效） - 直接打印
cache._cache（不推荐生产用，但调试时很直观）：print(len(cache._cache))
能看到当前缓存条目数
最容易被忽略的一点：LocMemCache 的 _cache 是线程局部的，如果你在异步任务（如 Celery）或后台线程里操作它，那个线程拥有自己独立的 _cache 实例——和主线程完全无关。所以不要指望在 Celery 任务里 set 一个 key，然后 Web 请求里 get 到。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
