keys_zone大小需按唯一请求key数量合理设置，1mb约存8000–12000个key；应分业务类型（如api、静态资源、后台）独立配置并确保名称与proxy_cache指令严格一致；需协同inactive和max_size参数实现缓存稳定。
keys_zone 大小直接影响缓存元数据的存储容量和查询性能，设太小会频繁淘汰 key 导致缓存命中率下降，设太大则浪费内存。关键看预计要缓存多少个唯一请求 key。
根据客户端规模估算 keys_zone 容量
1MB 共享内存约可存 8000–12000 个 key（取决于 key 长度）。例如：
- 若业务有约 10 万个唯一 URL 或用户标识需缓存，建议 keys_zone=xxx:12m 起步；
- 静态资源路径较短、key 简洁（如
/logo.png），可按 12000 key/MB 估算； - 带复杂参数的 API 请求（如
/api/user?id=123&v=2&ts=1726419240），key 较长，宜按 8000 key/MB 保守估算。
按业务类型分区域设置更合理
不同路径对缓存粒度、存活时间、key 数量差异大，不建议全站共用一个 keys_zone。推荐为每类流量单独定义：
-
API 接口：高频更新、key 多但生命周期短 →
keys_zone=api_cache:30m； -
静态资源：key 少而稳定、长期有效 →
keys_zone=static_cache:10m； -
后台管理页：key 少、更新频繁、需快速失效 →
keys_zone=admin_cache:5m。
必须确保名称严格匹配
proxy_cache 指令中写的名称，必须与 proxy_cache_path 的 keys_zone 名称**完全一致**，包括大小写和下划线：
- ✅ 正确：
proxy_cache_path ... keys_zone=my_api:20m;+proxy_cache my_api;； - ❌ 错误：
proxy_cache myapi;或proxy_cache MY_API;→ 缓存完全不生效。
配合 inactive 和 max_size 综合调优
keys_zone 只管内存里存多少个 key，实际磁盘缓存行为还要靠其他参数协同：
-
inactive=30m：该 key 对应的缓存内容 30 分钟没被访问就清理（不影响 keys_zone 中的 key 计数）； -
max_size=5g：磁盘空间上限，超限后按 LRU 清理最久未用的文件； - 二者共同作用，才能让 keys_zone 内存中的 key 数量趋于稳定，避免持续增长撑爆内存。
