也有一些內建變量是支持改寫的，其中一個例子是 $args. 這個變量在讀取時返回當前請求的 URL 參數串(即請求 URL 中問號后面的部分，如果有的話 )，而在賦值時可以直接修改參數串。我們來看一個例子：

location /test { set $orig_args $args; set $args "a=3&b=4"; echo "original args: $orig_args"; echo "args: $args"; }

這里我們把原始的 URL 參數串先保存在 $orig_args 變量中，然后通過改寫 $args 變量來修改當前的 URL 參數串，最后我們用 echo 指令分別輸出 $orig_args 和 $args 變量的值。接下來我們這樣來測試這個 /test 接口：

$ curl 'http://localhost:8080/test' original args: args: a=3&b=4 $ curl 'http://localhost:8080/test?a=0&b=1&c=2' original args: a=0&b=1&c=2 args: a=3&b=4

在第一次測試中，我們沒有設置任何 URL 參數串，所以輸出 $orig_args 變量的值時便得到空。而在第一次和第二次測試中，無論我們是否提供 URL 參數串，參數串都會在 location /test 中被強行改寫成 a=3&b=4.

需要特別指出的是，這里的 $args 變量和 $arg_XXX 一樣，也不再使用屬于自己的存放值的容器。當我們讀取 $args 時，Nginx 會執行一小段代碼，從 Nginx 核心中專門存放當前 URL 參數串的位置去讀取數據；而當我們改寫 $args 時，Nginx 會執行另一小段代碼，對相同位置進行改寫。Nginx 的其他部分在需要當前 URL 參數串的時候，都會從那個位置去讀數據，所以我們對 $args 的修改會影響到所有部分的功能。我們來看一個例子：

location /test { set $orig_a $arg_a; set $args "a=5"; echo "original a: $orig_a"; echo "a: $arg_a"; }

這里我們先把內建變量 $arg_a 的值，即原始請求的 URL 參數 a 的值，保存在用戶變量 $orig_a 中，然后通過對內建變量 $args 進行賦值，把當前請求的參數串改寫為 a=5 ，最后再用 echo 指令分別輸出 $orig_a 和 $arg_a 變量的值。因為對內建變量 $args 的修改會直接導致當前請求的 URL 參數串發生變化，因此內建變量 $arg_XXX 自然也會隨之變化。測試的結果證實了這一點：

$ curl 'http://localhost:8080/test?a=3' original a: 3 a: 5

我們看到，因為原始請求的 URL 參數串是 a=3, 所以 $arg_a 最初的值為 3, 但隨后通過改寫 $args 變量，將 URL 參數串又強行修改為 a=5, 所以最終 $arg_a 的值又自動變為了 5.

我們再來看一個通過修改 $args 變量影響標準的 HTTP 代理模塊 ngx_proxy 的例子：

server { listen 8080; location /test { set $args "foo=1&bar=2"; proxy_pass http://127.0.0.1:8081/args; } } server { listen 8081; location /args { echo "args: $args"; } }

這里我們在 http 配置塊中定義了兩個虛擬主機。第一個虛擬主機監聽 8080 端口，其 /test 接口自己通過改寫 $args 變量，將當前請求的 URL 參數串無條件地修改為 foo=1&bar=2. 然后 /test 接口再通過 ngx_proxy 模塊的 proxy_pass 指令配置了一個反向代理，指向本機的 8081 端口上的 HTTP 服務 /args. 默認情況下，ngx_proxy 模塊在轉發 HTTP 請求到遠方 HTTP 服務的時候，會自動把當前請求的 URL 參數串也轉發到遠方。

而本機的 8081 端口上的 HTTP 服務正是由我們定義的第二個虛擬主機來提供的。我們在第二個虛擬主機的 location /args 中利用 echo 指令輸出當前請求的 URL 參數串，以檢查 /test 接口通過 ngx_proxy 模塊實際轉發過來的 URL 請求參數串。

我們來實際訪問一下第一個虛擬主機的 /test 接口：

$ curl 'http://localhost:8080/test?blah=7' args: foo=1&bar=2

我們看到，雖然請求自己提供了 URL 參數串 blah=7，但在 location /test 中，參數串被強行改寫成了 foo=1&bar=2. 接著經由 proxy_pass 指令將我們被改寫掉的參數串轉發給了第二個虛擬主機上配置的 /args 接口，然后再把 /args 接口的 URL 參數串輸出。事實證明，我們對 $args 變量的賦值操作，也成功影響到了 ngx_proxy 模塊的行為。

在讀取變量時執行的這段特殊代碼，在 Nginx 中被稱為“取處理程序”(get handler)；而改寫變量時執行的這段特殊代碼，則被稱為“存處理程序”(set handler)。不同的 Nginx 模塊一般會為它們的變量準備不同的“存取處理程序”，從而讓這些變量的行為充滿魔法。

其實這種技巧在計算世界并不鮮見。比如在面向對象編程中，類的設計者一般不會把類的成員變量直接暴露給類的用戶，而是另行提供兩個方法(method)，分別用于該成員變量的讀操作和寫操作，這兩個方法常常被稱為“存取器”(accessor)。下面是 C++ 語言中的一個例子：

#include using namespace std; class Person { public: const string get_name() { return m_name; } void set_name(const string name) { m_name = name; } private: string m_name; };

在這個名叫 Person 的 C++ 類中，我們提供了 get_name 和 set_name 這兩個公共方法，以作為私有成員變量 m_name 的“存取器”。

這樣設計的好處是顯而易見的。類的設計者可以在“存取器”中執行任意代碼，以實現所需的業務邏輯以及“副作用”，比如自動更新與當前成員變量存在依賴關系的其他成員變量，抑或是直接修改某個與當前對象相關聯的數據庫表中的對應字段。而對于后一種情況，也許“存取器”所對應的成員變量壓根就不存在，或者即使存在，也頂多扮演著數據緩存的角色，以緩解被代理數據庫的訪問壓力。

與面向對象編程中的“存取器”概念相對應，Nginx 變量也是支持綁定“存取處理程序”的。Nginx 模塊在創建變量時，可以選擇是否為變量分配存放值的容器，以及是否自己提供與讀寫操作相對應的“存取處理程序”。

不是所有的 Nginx 變量都擁有存放值的容器。擁有值容器的變量在 Nginx 核心中被稱為“被索引的”(indexed)；反之，則被稱為“未索引的”(non-indexed)。

我們前面在 (二) 中已經知道，像 $arg_XXX 這樣具有無數變種的變量群，是“未索引的”。當讀取這樣的變量時，其實是它的“取處理程序”在起作用，即實時掃描當前請求的 URL 參數串，提取出變量名所指定的 URL 參數的值。很多新手都會對 $arg_XXX 的實現方式產生誤解，以為 Nginx 會事先解析好當前請求的所有 URL 參數，并且把相關的 $arg_XXX 變量的值都事先設置好。然而事實并非如此，Nginx 根本不會事先就解析好 URL 參數串，而是在用戶讀取某個 $arg_XXX 變量時，調用其“取處理程序”，即時去掃描 URL 參數串。類似地，內建變量 $cookie_XXX 也是通過它的“取處理程序”，即時去掃描 Cookie 請求頭中的相關定義的。

總結

以上是生活随笔為你收集整理的yii2通过url访问类中的方法_每日学点---nginx变量使用方法详解(3)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。