types_hash_max_size是Nginx HTTP模块控制MIME类型哈希表最大桶数的性能参数，必须为2的幂且不小于types_hash_bucket_size，默认1024/2048，仅影响查找效率而非功能正确性。
types_hash_max_size 是 Nginx HTTP 模块中用于控制 MIME 类型哈希表容量上限的核心参数，它不改变功能，只优化扩展名到 Content-Type 的查找性能。
它决定哈希表最多能有多少个桶（bucket）
Nginx 在启动时，会把 types 块（如 mime.types 文件或自定义配置）中所有扩展名 → MIME 类型的映射关系，一次性构建成一个静态哈希表。这个表不是运行时动态增删的，而是在初始化阶段就固定结构。
types_hash_max_size 就是这个哈希表允许分配的最大桶数量。桶越多，键（扩展名）分布越稀疏，冲突概率越低；桶太少，则多个扩展名可能挤进同一个桶，退化为链表遍历，查找变慢。
- 默认值通常是 1024 或 2048，适合大多数站点
- 它必须是 2 的整数次幂（如 128、256、512、1024…）
- 它的值不能小于
types_hash_bucket_size（默认 64）
它影响的是查找效率，不是功能正确性
无论设成 128 还是 8192，Nginx 都能正确识别 .js 是 application/javascript，不会返回错的 Content-Type。区别在于：在高并发静态资源请求下，小值可能导致更多哈希冲突，worker 进程在生成响应头时多花几纳秒做链表比对；合理设置后可稳定维持接近 O(1) 的平均查找时间。
- 不解决实际业务逻辑问题，但属于底层性能微调的关键一环
- 效果不易肉眼感知，但可通过 error.log 是否报错、worker 内存占用是否微升来间接验证
- 没有“越大越好”的绝对规则——超过实际扩展名数量太多只是预留空间，几乎不额外耗内存
它和 types_hash_bucket_size 是一对协作参数
前者管“桶的数量上限”，后者管“每个桶能装多长的扩展名”。比如 .application/vnd.api+json 这种超长扩展名，若 types_hash_bucket_size 太小（如仍用默认 32），就放不下，导致构建失败。
- 绝大多数场景只需调
types_hash_max_size，types_hash_bucket_size保持默认即可 - 只有启动时报
could not build the types_hash或could not build optimal types_hash时，才需联合检查这两个值 - 调整顺序建议：先增大
max_size；还不行，再谨慎加大bucket_size
它只在 http 块中生效，且仅作用于 types 映射
该指令不能出现在 server 或 location 块中，也不影响其他哈希结构（如变量、upstream 名称等）。它专用于优化 types { ... } 定义的那套静态 MIME 映射体系。
- 统计依据是你当前配置中真正启用的唯一扩展名总数（注意剔除注释、空行、重复项）
- 例如你 include 了标准 mime.types（含 176 个扩展名），又额外加了 30 个自定义类型，总数为 206 → 应设为 256
- 改完必须执行
nginx -t校验，再重启观察 error.log 是否还有哈希构建警告
