max_size 是 fastcgi_cache_path 中唯一实现磁盘配额控制的参数，设定缓存目录最大磁盘空间上限，超限时触发 LRU 清理；需小写单位，建议设为分区可用空间的 10%～20%。
fastcgi_cache_path 本身不直接管理“存储配额”，它定义的是缓存的物理位置、内存元数据区、清理策略和写入方式。真正起配额控制作用的是其中的 max_size 参数——它限制磁盘上缓存文件的总占用空间上限，是唯一具备硬性容量约束能力的配置项。
max_size 是实际的磁盘配额开关
这个参数设定了缓存目录允许使用的最大磁盘空间，超出后 Nginx 会自动触发 LRU 清理机制，逐出最久未访问（inactive 时间内）的缓存项，直到总大小回落到 max_size 以内。
- 它只约束磁盘用量，不影响
keys_zone内存分配（后者纯驻留内存，不占磁盘） - 值必须带单位：
1g、512m、2048k，不能写成2G或2000MB（Nginx 仅识别小写单位） - 推荐设为所在分区可用空间的 10%～20%，避免填满根分区导致系统异常
inactive 配合 max_size 实现动态配额平衡
inactive=1h 这类设置不是配额，而是“存活期”规则：一个缓存项若在 1 小时内没被再次命中，就标记为可清理。但它是否真被删掉，取决于 max_size 是否已满。
- 若磁盘远未满，即使过期也不会立即删除
- 若
max_size已触顶，Nginx 优先清掉inactive最早的条目，不管是否过期
其他参数不构成配额，但影响配额实效性
-
levels=1:2：决定目录结构，避免单目录 inode 爆满，间接保障大缓存场景下的max_size可稳定生效 -
use_temp_path=off：绕过临时目录中转，防止因/tmp满或权限问题导致写入失败——否则max_size再大也无用 -
keys_zone大小不足会导致 key 映射表满，新请求无法建立缓存索引，看起来像配额满了，实则是内存瓶颈
实操建议：配额配置要协同验证
fastcgi_cache_path /www/server/nginx/cache/fastcgi levels=1:2 keys_zone=fcgi:256m inactive=1d max_size=2g use_temp_path=off;
- 创建目录后执行
sudo -u www du -sh /www/server/nginx/cache/fastcgi监控实际用量 - 查看
nginx -T | grep cache确认配置加载无误 - 观察
X-Cache: HIT比率 + error.log 中cache file.*is too large类报错，判断配额是否成为瓶颈
配额不是孤立参数，而是 max_size、磁盘空间、keys_zone 和写入可靠性共同作用的结果。
