以前我們詳細了分析了 nginx 配置解析的各個過程，尤其是各種 conf 結構的建立、初始化、儲存。那麼現在我們要分析下 merge 的過程，一來它確實是配置解析過程的一個部分，二來我們可以檢驗下我們對各種 conf 結構儲存的位置是否真正的清晰明瞭。

首先我們瞭解下 merge 的背景：

1. 所謂 merge 操作，就是合併內外層的配置。大體原則是：如果內層沒有配置，那麼以外層為準，如果都沒有配置，那麼就用預設值；
2. NGX_CORE_MODULE 模組的 ctx（ngx_core_module_t）是沒有 merge 操作的，所以像 http 塊這一層的配置是不需要和上一層去 merge 的，想想也明白為什麼，http 哪來的上一層呢？
3. NGX_HTTP_MODULE 模組的 ctx(ngx_http_module_t）是有 merge 操作的，但是僅僅有 merge_srv_conf 和 merge_loc_conf，同理對 main 層不需要 merge；
4. merge 操作發生的時機是在 ngx_http_block函式中（即 http 塊解析函式），在遞迴呼叫 ngx_conf_parse 之後。這是為了讓 http 塊之內所有的指令都解析結束，然後再去做 merge 操作；
5. 不同層級塊的邏輯關係，基本上都是放在 ngx_http_core_module 這個模組的不同級別的 conf 中，在 merge 中會頻繁用到。

來看看 ngx_http_block 中的一段:

再明顯不過了，init 了 main，merge 了 server。 這裡的處理流程是個 for 迴圈，每次的迭代物件是模組本身，也就是挨個模組的去處理 merge。

在進入 ngx_http_merge_servers 內部分析之前，我們先確認一下這些代入的引數：

1. cf 是代入的引數，但是我們真正關心的還是 cf->ctx，這個時候它其實就是 http 塊的三元組（代入 ngx_http_block 的時候還不是，但是在函式中賦值了）；
2. cmcf 這個 http 塊的 ngx_http_core_module 的 main_conf 結構；
3. module 是個迴圈獲取的，代表當前模組；
4. mi 就是當前模組在 NGX_HTTP_MODULE 模組中的 index；

這裡很奇怪的就是並沒有明確指出 merge loc_conf 的地方，我們推測它是在 ngx_http_merge_servers 中實現的，那麼我們具體的分析下它的程式碼：