types_hash_max_size 通过限制哈希表最大桶数来优化 MIME 类型匹配效率：设太小则冲突增多、查找变慢，设合理可保持 O(1) 平均性能；默认 2048，超千条自定义扩展名建议调至 4096 或 8192。
Nginx 的 types_hash_max_size 指令本身并不直接“加速” MIME 类型匹配，而是通过控制哈希表的上限大小，间接影响 types 块中 MIME 类型映射的查找效率。合理设置它，可避免哈希冲突过多导致的链表遍历开销，从而提升静态文件响应时的类型判断性能。
types_hash_max_size 的作用机制
在 http 块中，Nginx 将 types 指令定义的扩展名 → MIME 类型映射构建成一个哈希表。该哈希表初始大小由 types_hash_bucket_size 决定，而 types_hash_max_size 是其允许增长的最大桶（bucket）数量上限。
- 当实际需要的哈希桶数超过
max_size，Nginx 启动时会报错：could not build the types_hash, you should increase either types_hash_max_size or types_hash_bucket_size - 若设得过小，哈希表被迫使用更少的桶，冲突增多，查找退化为链表遍历，降低匹配速度
- 若设得过大，只是预留空间，不显著增加内存占用（因哈希表按需分配），但能保障低冲突率和 O(1) 平均查找性能
如何设置合理的 types_hash_max_size
默认值是 2048，适用于大多数站点。是否需要调大，取决于你自定义的 types 条目数量和扩展名长度分布：
- 统计当前
types块中的非重复扩展名个数（如.js、.webp、.mjs算三个） - 若条目数超过 1000，建议将
types_hash_max_size设为 4096 或 8192 - 配合调整
types_hash_bucket_size（默认 32 字节），确保单个桶能容纳最长扩展名（例如.application/vnd.api+json很长，可能需设为 64） - 修改后务必用
nginx -t验证配置，避免启动失败
实际效果与注意事项
该优化对高并发静态资源服务有边际收益，但不是性能瓶颈的万能解：
- 仅影响
Content-Type头生成阶段，不改变文件读取、发送或 gzip 等流程 - 现代 CPU 上单次哈希查找差异微乎其微，通常只有在每秒数万次 MIME 判定（如大量小图、字体、API 文件）时才可观测到延迟下降
- 不要盲目调大——过大的值不会提升性能，且可能让哈希表稀疏，略微浪费少量内存
- 优先确认你确实用了大量自定义
types，而非依赖默认 MIME 表；否则默认配置已足够高效
