types_hash_max_size 是 nginx 优化 mime 类型哈希查找的参数，需设为不小于实际扩展名数的最小 2 的幂（如176个则设256），且≥types_hash_bucket_size，默认64，仅当启动报错时才需调整后者。

types_hash_max_size 是 Nginx 用来加速文件扩展名到 MIME 类型映射的关键参数，它不改变功能，只优化底层哈希查找速度。合理配置能避免启动警告、减少哈希冲突，在高并发静态资源请求中带来可测的响应头生成效率提升。

先搞清你实际用了多少扩展名

这个值不是凭感觉设的，必须基于真实配置统计：

• 打开你 include 的 mime.types 文件（如 /etc/nginx/mime.types）或自定义 types 块
• 剔除注释行、空行、重复扩展名（例如 .js 和 .mjs 算两个，同一行多个扩展名如 text/css css css3 中的 css 和 css3 要分别计数）
• 只统计真正生效的唯一扩展名总数（比如你加了 176 个，就记作 176）

选一个合适的 2 的幂数值

Nginx 强制要求 types_hash_max_size 必须是 2 的整数次幂（128、256、512、1024…），且不能小于 types_hash_bucket_size（默认 64）：

• 若统计结果 ≤ 128 → 设为 128
• 若在 129–256 之间 → 设为 256
• 若在 257–512 之间 → 设为 512
• 若超过 512 → 优先选 1024；除非你明确添加了 800+ 个扩展名，否则不必更大

配合检查 types\_hash\_bucket\_size

这个参数决定每个哈希桶占用内存大小，默认值通常为 64，多数场景无需改动：

• 只有当 Nginx 启动时日志报出 “could not build the types_hash” 或 “could not build optimal types_hash” 时，才需要同步调整
• 此时优先尝试增大 types_hash_max_size；若仍失败，再微调 types_hash_bucket_size（如设为 128），但不宜过大，否则单桶浪费内存
• 两者需满足：types_hash_max_size ≥ types_hash_bucket_size

验证是否生效

改完配置别急着上线，按顺序确认：

• 运行 nginx -t 检查语法，非法值（如非 2 的幂、太小）会直接报错
• 重启 Nginx，查看 error.log：无 “could not build…” 类警告即表示哈希构建成功
• 不需要压测也能感知效果——worker 进程内存占用会有轻微但稳定的上升（几十 KB 级别），说明哈希表已按新尺寸分配