必须在location块中显式配置client_max_body_size才能生效，因Nginx按“就近原则”匹配，不继承父级配置；仅设在http或server块会导致上传路径仍用默认1MB，且需同步调优buffer、timeout、temp_path权限及后端限制。
直接在 server 块中设置 client_max_body_size，它不会被子块“覆盖”，而是会被子块“继承并可能被重新定义”——关键不是避免覆盖，而是理解 Nginx 的配置生效规则：更具体的作用域优先级更高。也就是说，location 块里的值会覆盖 server 块里的同名设置，这是设计行为，不是意外。
client_max_body_size 的继承与覆盖逻辑
Nginx 配置采用“就近原则”：指令在哪个作用域里定义，就对那个作用域及其内部生效；子作用域若未显式重写，就沿用父级值；一旦重写，就以子级为准。
-
http块设为10M→ 所有未声明的server和location都继承这个值 -
server块设为100M→ 该虚拟主机下所有请求默认按此限制，除非某个location显式改成2G或1M -
location /api/upload设为500M→ 仅该路径生效，其他路径仍用server级的100M
想让 server 级设置“始终有效”，就别在 location 里重写
如果你希望整个域名统一按一个上限运行，最稳妥的做法是：不在任何 location 块中设置 client_max_body_size。只要 server 块里写了，且所有 location 都不干预，那就自然全局生效。
- 删掉所有
location中的client_max_body_size行 - 确认没有通过
include引入的子配置悄悄覆盖了它 - 用
nginx -t检查语法，并查看实际生效值（可通过curl -I -X POST触发 413 错误来反推当前限制）
需要差异化但又不想失控？用最小必要覆盖
如果某些路径确实需要更大限制（比如上传接口），那就只在对应 location 中精准设置，其余保持空白。这样既满足业务需求，又避免意外覆盖。
- 例如：
location /upload/ { client_max_body_size 2G; } - 其余路径（如
/api/、/static/）不设该指令，自动继承server级的100M - 不要在
location /这种通配路径里设，否则等于全量覆盖server设置
注意单位写法和语法陷阱
写错单位或格式会导致配置不生效，看似“被覆盖”，实则是解析失败后回退到默认值（1MB）。
- 只支持小写单位：
100m✅，100M❌（Nginx 会报错或忽略） - 数值后必须紧跟单位，不能有空格：
100 m无效 - 设为
0表示不限制（仅限可信内网环境）
