nginx 的 master 进程不执行静态资源预加载，仅管理 worker 进程、读取配置及信号处理；预加载由 worker 进程响应请求、外部工具（如 curl）或 internal location 触发，master 仅间接支持，如配置校验、平滑重启和资源调度。
Nginx 的 Master Process 不直接参与静态资源预加载，它只负责管理 Worker 进程、读取配置、平滑重启和信号处理。预加载行为必须由外部主动触发或由 Worker 进程在响应请求时完成，Master 本身不发起 HTTP 请求、不访问文件系统、也不执行缓存填充逻辑。
真正承担预加载任务的是：
-
Worker 进程：当收到一个请求（比如 curl 预热请求），Worker 才会读取文件、触发
open_file_cache缓存元数据、将内容送入proxy_cache（如果启用了反向代理缓存），或通过sendfile加载到内核缓冲区； -
外部工具或脚本：如
curl、wget或定时任务（crontab），它们模拟用户请求，迫使 Worker 执行加载流程； -
Nginx 配置中定义的 internal location（如
/ _preload）：仅允许本机调用，配合proxy_pass和proxy_cache指令，让 Worker 在处理该请求时完成缓存写入。
所以“Master 管理预加载”这个说法存在误解——它只间接支持预加载，方式包括：
- 加载并校验含
proxy_cache、open_file_cache、sendfile等指令的配置； - 接收
nginx -s reload后，优雅启动新 Worker，旧 Worker 继续服务直至连接关闭，确保预热不中断； - 转发
USR1信号触发日志轮转，避免预热期间 I/O 被日志刷盘阻塞（尤其当access_log off未对静态路径启用时）； - 通过
worker_processes auto和worker_cpu_affinity分配计算资源，让 Worker 更快响应预热请求。
关键点在于：
✅ 预加载不是后台常驻服务，而是“按需触发 + 缓存驻留”；
✅ Master 不做 I/O、不发请求、不操作缓存；
✅ 所有预热效果依赖 Worker 的首次响应 + 后续缓存复用。
如果你希望每次发布后自动预热，正确做法是：
- 写一个部署后脚本，用
curl -s http://localhost/_preload?url=/home触发； - 确保 Nginx 配置中已有
location /_preload { internal; proxy_pass ...; proxy_cache my_cache; }； - 不要指望 Master 自己“想起来去预热”。
不复杂但容易忽略。
