㈠ Spring Boot 第二彈，配置文件詳解-史上最全
Spring Boot 官方 提供了兩種常用的配置文件格式，分別是 properties 、 YML 格式。相比於 properties 來說， YML 更加年輕，層級也是更加分明。 強烈推薦使用 YML 格式
Spring Boot項目 啟動會掃描以下位置的 application.properties 或者 application.yml 作為默認的配置文件.
徒手撕源碼
內部類Loader的load方法
getSearchLocations()方法
asResolvedSet()
下面給出優先順序 從高到低 的配置文件排列順序：
以設置應用埠為例 初體驗Spring Boot配置文件
properties後綴結尾(application.properties)
yml/yaml後綴結尾(application.yml/application.yaml)
數字，字元串，布爾，日期
對象、Map
數組
數字，字元串，布爾，日期
對象、Map
數組
@ConfigurationProperties(prefix = "person")詳解
標注在類上
標注在方法上
綜上所述
@ConfigurationProperties 註解能夠輕松的讓配置文件跟實體類綁定在一起。
值得關注的是： @ConfigurationProperties 這個註解僅僅是支持從 Spring Boot的默認配置文件 中取值，也就是 application.properties 、 application.yml 、 application.yaml ，那我們如何從自定義配置文件取值呢？？？
別著急，有解決辦法，那就是再加一個註解： @PropertySource(value = "classpath:custom-profile.properties") ,下面會有對 @PropertySource 註解的介紹。請耐心往下面看。
使用@PropertySource註解
對應配置文件
創建兩個配置文件 custom-profile.yml、custom-profile1.yml ，如下去引入。
我們可以通過控制變數法進行測試，具體過程我這里就不贅述了。
直接說 結論 吧： Spring載入順序 為 從左到右順序載入 ，後載入的會 覆蓋 先載入的屬性值。
另外需要注意的是 ： @PropertySource 默認載入 xxx.properties類型 的配置文件，不能載入 YML格式 的配置文件。如何解決呢？下面來解決這一問題
對應配置文件：
編寫PropertiesController
擴展功能
application.yml 主配置文件
application-dev.yml 開發配置文件
application-prod.yml 生產配置文件
application-test.yml 測試配置文件
（1）主配置文件：配置激活選項
（2）其他配置文件：指定屬於哪個環境（同yml，只不過表現形式是 key=value 的,三個配置文件分別是： application-dev.properties , application-prod.properties , application-test.properties ）
無論是使用上述 多文檔塊 的方式，還是新建 application-test.yml 文件，都可以在配置文件中指定 spring.profiles.active=test 激活指定的profile。
感謝閱讀小生文章。祝大家早日富可敵國，實現財富自由。
寫文不易 ,一定要 點贊、評論、收藏哦 , 感謝感謝感謝!!!
㈡ nginx配置文件中怎麼把hostname的值賦給其它變數
Nginx 的配置文件使用的就是一門微型的編程語言，許多真實世界裡的 Nginx 配置文件其實就是一個一個的小程序。當然，是不是「圖靈完全的」暫且不論，至少據我觀察，它在設計上受 Perl 和 Bourne Shell 這兩種語言的影響很大。在這一點上，相比 Apache 和 Lighttpd 等其他 Web 伺服器的配置記法，不能不說算是 Nginx 的一大特色了。既然是編程語言，一般也就少不了「變數」這種東西（當然，Haskell 這樣奇怪的函數式語言除外了）。
熟悉 Perl、Bourne Shell、C/C++ 等命令式編程語言的朋友肯定知道，變數說白了就是存放「值」的容器。而所謂「值」，在許多編程語言里，既可以是 3.14 這樣的數值，也可以是 hello world 這樣的字元串，甚至可以是像數組、哈希表這樣的復雜數據結構。然而，在 Nginx 配置中，變數只能存放一種類型的值，因為也只存在一種類型的值，那就是字元串。
比如我們的 nginx.conf 文件中有下面這一行配置：
set $a "hello world";
我們使用了標准 ngx_rewrite 模塊的 set 配置指令對變數 $a 進行了賦值操作。特別地，我們把字元串 hello world 賦給了它。
我們看到，Nginx 變數名前面有一個 $ 符號，這是記法上的要求。所有的 Nginx 變數在 Nginx 配置文件中引用時都須帶上 $ 前綴。這種表示方法和 Perl、PHP 這些語言是相似的。
雖然 $ 這樣的變數前綴修飾會讓正統的 java 和 C# 程序員不舒服，但這種表示方法的好處也是顯而易見的，那就是可以直接把變數嵌入到字元串常量中以構造出新的字元串：
set $a hello;
set $b "$a, $a";
這里我們通過已有的 Nginx 變數 $a 的值，來構造變數 $b 的值，於是這兩條指令順序執行完之後，$a 的值是 hello，而 $b 的值則是 hello, hello. 這種技術在 Perl 世界裡被稱為「變數插值」（variable interpolation），它讓專門的字元串拼接運算符變得不再那麼必要。我們在這里也不妨採用此術語。
我們來看一個比較完整的配置示例：
server {
listen 8080;
location /test {
set $foo hello;
echo "foo: $foo";
}
}
這個例子省略了 nginx.conf 配置文件中最外圍的 http 配置塊以及 events 配置塊。使用 curl 這個 HTTP 客戶端在命令行上請求這個 /test 介面，我們可以得到
$ curl 'http://localhost:8080/test'
foo: hello
這里我們使用第三方 ngx_echo 模塊的 echo 配置指令將 $foo 變數的值作為當前請求的響應體輸出。
我們看到，echo 配置指令的參數也支持「變數插值」。不過，需要說明的是，並非所有的配置指令都支持「變數插值」。事實上，指令參數是否允許「變數插值」，取決於該指令的實現模塊。
如果我們想通過 echo 指令直接輸出含有「美元符」（$）的字元串，那麼有沒有辦法把特殊的 $ 字元給轉義掉呢？答案是否定的（至少到目前最新的 Nginx 穩定版 1.0.10）。不過幸運的是，我們可以繞過這個限制，比如通過不支持「變數插值」的模塊配置指令專門構造出取值為 $ 的 Nginx 變數，然後再在 echo 中使用這個變數。看下面這個例子：
geo $dollar {
default "$";
}
server {
listen 8080;
location /test {
echo "This is a dollar sign: $dollar";
}
}
測試結果如下：
$ curl 'http://localhost:8080/test'
This is a dollar sign: $
這里用到了標准模塊 ngx_geo 提供的配置指令 geo 來為變數 $dollar 賦予字元串 "$"，這樣我們在下面需要使用美元符的地方，就直接引用我們的 $dollar 變數就可以了。其實 ngx_geo 模塊最常規的用法是根據客戶端的 IP 地址對指定的 Nginx 變數進行賦值，這里只是借用它以便「無條件地」對我們的 $dollar 變數賦予「美元符」這個值。
在「變數插值」的上下文中，還有一種特殊情況，即當引用的變數名之後緊跟著變數名的構成字元時（比如後跟字母、數字以及下劃線），我們就需要使用特別的記法來消除歧義，例如：
server {
listen 8080;
location /test {
set $first "hello ";
echo "${first}world";
}
}
這里，我們在 echo 配置指令的參數值中引用變數 $first 的時候，後面緊跟著 world 這個單詞，所以如果直接寫作 "$firstworld" 則 Nginx 「變數插值」計算引擎會將之識別為引用了變數 $firstworld. 為了解決這個難題，Nginx 的字元串記法支持使用花括弧在 $ 之後把變數名圍起來，比如這里的 ${first}. 上面這個例子的輸出是：
$ curl 'http://localhost:8080/test
hello world
set 指令（以及前面提到的 geo 指令）不僅有賦值的功能，它還有創建 Nginx 變數的副作用，即當作為賦值對象的變數尚不存在時，它會自動創建該變數。比如在上面這個例子中，如果 $a 這個變數尚未創建，則 set 指令會自動創建 $a 這個用戶變數。如果我們不創建就直接使用它的值，則會報錯。例如
1
2
3
4
5
6
server {
listen 8080;
location /bad {
echo $foo;
}
}
此時 Nginx 伺服器會拒絕載入配置:
1
[emerg] unknown "foo" variable
是的，我們甚至都無法啟動服務！
有趣的是，Nginx 變數的創建和賦值操作發生在全然不同的時間階段。Nginx 變數的創建只能發生在 Nginx 配置載入的時候，或者說 Nginx 啟動的時候；而賦值操作則只會發生在請求實際處理的時候。這意味著不創建而直接使用變數會導致啟動失敗，同時也意味著我們無法在請求處理時動態地創建新的 Nginx 變數。
Nginx 變數一旦創建，其變數名的可見范圍就是整個 Nginx 配置，甚至可以跨越不同虛擬主機的 server 配置塊。我們來看一個例子：
server {
listen 8080;
location /foo {
echo "foo = [$foo]";
}
location /bar {
set $foo 32;
echo "foo = [$foo]";
}
}
這里我們在 location /bar 中用 set 指令創建了變數 $foo，於是在整個配置文件中這個變數都是可見的，因此我們可以在 location /foo 中直接引用這個變數而不用擔心 Nginx 會報錯。
下面是在命令行上用 curl 工具訪問這兩個介面的結果：
$ curl 'http://localhost:8080/foo'
foo = []
$ curl 'http://localhost:8080/bar'
foo = [32]
$ curl 'http://localhost:8080/foo'
foo = []
從這個例子我們可以看到，set 指令因為是在 location /bar 中使用的，所以賦值操作只會在訪問 /bar 的請求中執行。而請求 /foo 介面時，我們總是得到空的 $foo 值，因為用戶變數未賦值就輸出的話，得到的便是空字元串。
從這個例子我們可以窺見的另一個重要特性是，Nginx 變數名的可見范圍雖然是整個配置，但每個請求都有所有變數的獨立副本，或者說都有各變數用來存放值的容器的獨立副本，彼此互不幹擾。比如前面我們請求了 /bar 介面後，$foo 變數被賦予了值 32，但它絲毫不會影響後續對 /foo 介面的請求所對應的 $foo 值（它仍然是空的！），因為各個請求都有自己獨立的 $foo 變數的副本。
對於 Nginx 新手來說，最常見的錯誤之一，就是將 Nginx 變數理解成某種在請求之間全局共享的東西，或者說「全局變數」。而事實上，Nginx 變數的生命期是不可能跨越請求邊界的。
㈢ java中怎麼向class外的注釋中傳遞值
@XmlType(namespace = XX) ///////裡面的值，必需是常量。靜態的方法，都不能
public class test{
靜態的變數，要final 修飾