導(dǎo)讀Redis可以使用主從同步，從從同步第一次同步時(shí)，主節(jié)點(diǎn)做一次bgsave，并同時(shí)將后續(xù)修改操作記錄到內(nèi)存buffer，待完成后將rdb文件全量同步到復(fù)制節(jié)....

Redis 可以使用主從同步，從從同步第一次同步時(shí)，主節(jié)點(diǎn)做一次 bgsave，并同時(shí)將后續(xù)修改操作記錄到內(nèi)存 buffer，待完成后將 rdb 文件全量同步到復(fù)制節(jié)點(diǎn)，復(fù)制節(jié)點(diǎn)接受完成后將 rdb 鏡像加載到內(nèi)存加載完成后，再通知主節(jié)點(diǎn)將期間修改的操作記錄同步到復(fù)制節(jié)點(diǎn)進(jìn)行重放就完成了同步過程，今天小編就來聊一聊關(guān)于簡單的php面試題?接下來我們就一起去研究一下吧!

簡單的php面試題

「PHP面試題」跳槽面試必背-自己最近5年的整理（一）30G-PHP進(jìn)階資料，助力大家達(dá)到30K101.Redis 的同步機(jī)制了解么？

Redis 可以使用主從同步，從從同步。第一次同步時(shí)，主節(jié)點(diǎn)做一次 bgsave，并同時(shí)將后續(xù)修改操作記錄到內(nèi)存 buffer，待完成后將 rdb 文件全量同步到復(fù)制節(jié)點(diǎn)，復(fù)制節(jié)點(diǎn)接受完成后將 rdb 鏡像加載到內(nèi)存。加載完成后，再通知主節(jié)點(diǎn)將期間修改的操作記錄同步到復(fù)制節(jié)點(diǎn)進(jìn)行重放就完成了同步過程。

102. 是否使用過 Redis 集群，集群的原理是什么？

Redis Sentinal 著眼于高可用，在 master 宕機(jī)時(shí)會自動(dòng)將 slave 提升為 master，繼續(xù)提供服務(wù)。

Redis Cluster 著眼于擴(kuò)展性，在單個(gè) redis 內(nèi)存不足時(shí)，使用 Cluster 進(jìn)行分片存儲。

103.phpautoload 實(shí)現(xiàn)機(jī)制

第一步是將PHP文件編譯成普通稱之為OPCODE的字節(jié)碼序列（實(shí)際上是編譯成一個(gè)叫做zend_op_array的字節(jié)數(shù)組），第二步是由一個(gè)虛擬機(jī)來執(zhí)行這些OPCODE。PHP的所有行為都是由這些OPCODE來實(shí)現(xiàn)的。PHP在實(shí)例化一個(gè)對象時(shí)（實(shí)際上在實(shí)現(xiàn)接口，使用類常數(shù)或類中的靜態(tài)變量，調(diào)用類中的靜態(tài)方法時(shí)都會如此），首先會在系統(tǒng)中查找該類（或接口）是否存在，如果不存在的話就嘗試使用autoload機(jī)制來加載該類。而autoload機(jī)制的主要執(zhí)行過程為：(1) 檢查執(zhí)行器全局變量函數(shù)指針autoload_func是否為NULL。(2) 如果autoload_func==NULL, 則查找系統(tǒng)中是否定義有__autoload()函數(shù)，如果沒有，則報(bào)告錯(cuò)誤并退出。(3) 如果定義了__autoload()函數(shù)，則執(zhí)行__autoload()嘗試加載類，并返回加載結(jié)果。(4) 如果autoload_func不為NULL，則直接執(zhí)行autoload_func指針指向的函數(shù)用來加載類。注意此時(shí)并不檢查__autoload()函數(shù)是否定義。真相終于大白，PHP提供了兩種方法來實(shí)現(xiàn)自動(dòng)裝載機(jī)制，一種我們前面已經(jīng)提到過，是使用用戶定義的__autoload()函數(shù)，這通常在PHP源程序中來實(shí)現(xiàn)；另外一種就是設(shè)計(jì)一個(gè)函數(shù)，將autoload_func指針指向它，這通常使用C語言在PHP擴(kuò)展中實(shí)現(xiàn)。如果既實(shí)現(xiàn)了__autoload()函數(shù)，又實(shí)現(xiàn)了autoload_func(將autoload_func指向某一PHP函數(shù))，那么只執(zhí)行autoload_func函數(shù)。

104.REST 接口規(guī)范

GET （SELECT）：從服務(wù)器檢索特定資源，或資源列表。POST （CREATE）：在服務(wù)器上創(chuàng)建一個(gè)新的資源。PUT （UPDATE）：更新服務(wù)器上的資源，提供整個(gè)資源。PATCH （UPDATE）：更新服務(wù)器上的資源，僅提供更改的屬性。DELETE （DELETE）：從服務(wù)器刪除資源。www.ruanyifeng.com/blog/2014/05/res...

105.Swoole

Swoole是一個(gè)PHP擴(kuò)展，擴(kuò)展不是為了提升網(wǎng)站的性能，是為了提升網(wǎng)站的開發(fā)效率。最少的性能損耗，換取最大的開發(fā)效率。利用Swoole擴(kuò)展，開發(fā)一個(gè)復(fù)雜的Web功能，可以在很短的時(shí)間內(nèi)完成了。php的高級web開發(fā)框架swoole/swoole-src

106.php5 中魔術(shù)方法有哪幾個(gè)？請舉例說明各自的用法。

1、__construct() ：實(shí)例化對象時(shí)自動(dòng)調(diào)用。2、__destruct() ：銷毀對象或腳本執(zhí)行結(jié)束時(shí)自動(dòng)調(diào)用。3、__call() ：調(diào)用對象不存在得方法時(shí)執(zhí)行此函數(shù)。4、__get() ：獲取對象不存在的屬性時(shí)執(zhí)行此函數(shù)。5、__set() ：設(shè)置對象不存在的屬性時(shí)執(zhí)行此函數(shù)。6、__isset() : 檢測對象的某個(gè)屬性是否存在時(shí)執(zhí)行此函數(shù)。7、__unset() ：銷毀對象的某個(gè)屬性時(shí)執(zhí)行此函數(shù)。8、__toString() ：將對象當(dāng)作字符串輸出時(shí)執(zhí)行此函數(shù)。9、__clone() ：克隆對象時(shí)執(zhí)行此函數(shù)。10、__autoload() ：實(shí)例化對象時(shí)，當(dāng)類不存在時(shí)，執(zhí)行此函數(shù)自動(dòng)加載類。11、__sleep() ：serialize之前被調(diào)用，可以指定要序列化的對象屬性。12、__wakeup ：unserialize之前被調(diào)用，可以執(zhí)行對象的初始化工作。13、set_state() ：調(diào)用var_export時(shí)，被調(diào)用。用set_state的返回值做為var_export的返回值。14、__invoke() ：將對象當(dāng)作函數(shù)來使用時(shí)執(zhí)行此方法，通常不推薦這樣做。

107. 簡述 php 的垃圾收集機(jī)制。

php中的變量存儲在變量容器zval中，zval中除了存儲變量類型和值外，還有is_ref和refcount字段。refcount表示指向變量的元素個(gè)數(shù)，is_ref表示變量是否有別名。如果refcount為0時(shí)，就回收該變量容器。如果一個(gè)zval的refcount減1之后大于0，它就會進(jìn)入垃圾緩沖區(qū)。當(dāng)緩沖區(qū)達(dá)到最大值后，回收算法會循環(huán)遍歷zval，判斷其是否為垃圾，并進(jìn)行釋放處理。

我的官方群點(diǎn)擊進(jìn)入

108. 一個(gè)文件的路徑為 /wwwroot/include/page.class.php，寫出獲得該文件擴(kuò)展名的方法

$arr = pathinfo(“/wwwroot/include/page.class.php”);$str = substr($arr[‘basename’],strrpos($arr[‘basename’],’.’));

109.Yii2 的自動(dòng)加載原理

1、檢查類名是否已緩存在$classMap或$_coreClasses數(shù)組中，如果是則直接require相應(yīng)的文件路徑，$_coreClasses是框架自有類的映射表；否則去第2步；2、檢測YiiBase::$enableIncludePath是否為false，如果是則去第3步，否則直接include($className . .php)3、遍歷$includePaths數(shù)組，將目錄名拼接上類名，檢查是否為合法的php文件，如果是則include，然后跳出循環(huán)4、結(jié)束。www.php.cn/php-weizijiaocheng-39315...

110. 進(jìn)程和線程的關(guān)系

進(jìn)程就像地主，有土地（系統(tǒng)資源），線程就像佃戶（線程，執(zhí)行種地流程）。每個(gè)地主（進(jìn)程）只要有一個(gè)干活的佃戶（線程）。

進(jìn)程-資源分配的最小單位，相對健壯，崩潰一般不影響其他進(jìn)程，但是切換進(jìn)程時(shí)耗費(fèi)資源，效率差些。

線程-程序執(zhí)行的最小單位，沒有獨(dú)立的地址空間，一個(gè)線程死掉可能整個(gè)進(jìn)程就死掉，但是節(jié)省資源，切換效率高。

111.php 編程常見的進(jìn)程和線程

1、在web應(yīng)用中，我們每次訪問php，就建立一個(gè)PHP進(jìn)程，當(dāng)然也會建立至少一個(gè)PHP線程。2、PHP使用pcntl來進(jìn)行多進(jìn)程編程3、PHP中使用pthreads來進(jìn)行多線程編程4、nginx的每個(gè)進(jìn)程只有一個(gè)線程，每個(gè)線程可以處理多個(gè)客戶端的訪問5、php-fpm使用多進(jìn)程模型，每個(gè)進(jìn)程只有一個(gè)線程，每個(gè)線程只能處理一個(gè)客戶端訪問。6、apache可能使用多進(jìn)程模型，也可能使用多線程模型，取決于使用哪種SAPI.7、進(jìn)程是cpu資源分配的最小單位，線程是cpu調(diào)度的最小單位

112. 打印前一天的時(shí)間

方式一：echo date(Y-m-d H:i:s,-1 day);方式二：echo date("Y-m-d H:i:s",time()-24*3600);

113. 能夠使 HTML 和 PHP 分離開使用的模板是什么

Smarty

我們用過的~

114. 什么是 smarty,smarty 有什么優(yōu)點(diǎn)

Smarty是一個(gè)使用PHP寫出來的PHP模板引擎，目的是要使用PHP程序同美工分離,使的程序員改變程序的邏輯內(nèi)容時(shí)不會影響到美工的頁面設(shè)計(jì)，美工重新修改頁面時(shí)不會影響到程序的程序邏輯，這在多人合作的項(xiàng)目中顯的尤為重要。Smarty優(yōu)點(diǎn)1. 速度快：相對其他模板引擎。2. 編譯型：采用smarty編寫的程序在運(yùn)行時(shí)要編譯成一個(gè)非模板技術(shù)的PHP文件3. 緩存技術(shù)：它可以將用戶最終看到的HTML文件緩存成一個(gè)靜態(tài)的HTML頁4. 插件技術(shù)：smarty可以自定義插件。不適合使用smarty的地方1. 需要實(shí)時(shí)更新的內(nèi)容。例如像股票顯示，它需要經(jīng)常對數(shù)據(jù)進(jìn)行更新2. 小項(xiàng)目。小項(xiàng)目因?yàn)轫?xiàng)目簡單而美工與程序員兼于一人的項(xiàng)目

115.lnmp 怎么開啟 https

第一步、部署SSL加密服務(wù)準(zhǔn)備工作1.申請SSL證書（百度免費(fèi)SSL證書），我以阿里云提過的賽門鐵克證書為例。第二步、上傳證書將申請證書里的key文件和pem文件上傳到/usr/local/nginx/conf/ssl/ 文件夾下，如果沒有ssl文件夾，可以自己新建。第三步、nginx里部署SSL，并301重定向http跳轉(zhuǎn)至https我們需要在站點(diǎn)對應(yīng)的CONF文件設(shè)置。修改設(shè)置如下

server{listen 80;listen 443 ssl;#listen [::]:80;ssl on;ssl_certificate /usr/local/nginx/conf/ssl/214346445970119.pem;ssl_certificate_key /usr/local/nginx/conf/ssl/214346445970119.key;server_name 酒鋼數(shù)字報(bào) | 打造酒鋼全媒體時(shí)代！ ;if ($server_port !~ 443){rewrite ^(.*)$ https://$host$1 permanent;}

第四步、登錄后臺的強(qiáng)制開啟SSL修改的文件是 config.php，直接在這個(gè)文件的末尾添加兩行代碼：/* 強(qiáng)制后臺和登錄使用 SSL */define(FORCE_SSL_LOGIN, true);define(FORCE_SSL_ADMIN, true);第五步、注意以下需要修改的修改“菜單”當(dāng)中的所有“自定義鏈接”為相對路徑；修改“設(shè)置”→“常規(guī)”里的“站點(diǎn)地址”和“WordPress 地址”為 HTTPS；修改其他自己手賤寫入的絕對鏈接地址……第六步、記得在服務(wù)器上開啟443端口。

116. 什么是 csrf 和 xss

CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險(xiǎn)性。攻擊通過在授權(quán)用戶訪問的頁面中包含鏈接或者腳本的方式工作。例如：一個(gè)網(wǎng)站用戶Bob可能正在瀏覽聊天論壇，而同時(shí)另一個(gè)用戶Alice也在此論壇中，并且后者剛剛發(fā)布了一個(gè)具有Bob銀行鏈接的圖片消息。設(shè)想一下，Alice編寫了一個(gè)在Bob的銀行站點(diǎn)上進(jìn)行取款的form提交的鏈接，并將此鏈接作為圖片src。如果Bob的銀行在cookie中保存他的授權(quán)信息，并且此cookie沒有過期，那么當(dāng)Bob的瀏覽器嘗試裝載圖片時(shí)將提交這個(gè)取款form和他的cookie，這樣在沒經(jīng)Bob同意的情況下便授權(quán)了這次事務(wù)。跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。惡意攻擊者往Web頁面里插入惡意Script代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中Web里面的Script代碼會被執(zhí)行，從而達(dá)到惡意攻擊用戶的目的。XSS攻擊分成兩類，一類是來自內(nèi)部的攻擊，主要指的是利用程序自身的漏洞，構(gòu)造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。另一類則是來自外部的攻擊，主要指的自己構(gòu)造XSS跨站漏洞網(wǎng)頁或者尋找非目標(biāo)機(jī)以外的有跨站漏洞的網(wǎng)頁。如當(dāng)我們要滲透一個(gè)站點(diǎn)，我們自己構(gòu)造一個(gè)有跨站漏洞的網(wǎng)頁，然后構(gòu)造跨站語句，通過結(jié)合其它技術(shù)，如社會工程學(xué)等，欺騙目標(biāo)服務(wù)器的管理員打開。

117. 如何解決 xss 和 csrf 攻擊

xss把傳入字符串的特殊字符進(jìn)行html轉(zhuǎn)碼，例如> < ) ( " % ; & ，這些特殊字符很有可能就是被注入的代碼。csrf2.1 首先項(xiàng)目里面引入事先寫好的代碼文件，這個(gè)里面主要是產(chǎn)生一個(gè)csrftoken session的代碼。2.2 在用戶進(jìn)入項(xiàng)目，還沒有跳轉(zhuǎn)到登錄頁面之前，我們通過代碼文件產(chǎn)生一個(gè)token，然后把它傳入登錄頁面，給它定義成csrf。2.3 在登錄頁面里面，通過隱藏域來獲取剛剛傳入的csrf，這樣當(dāng)用戶提交form表單的時(shí)候，這里的csrf就會一起被提交到后臺的代碼。2.4 在后臺代碼里面，我們通過頁面?zhèn)魅氲膖oken和已經(jīng)產(chǎn)生的token session進(jìn)行對比，如果兩個(gè)相同，那么這些操作就認(rèn)為是用戶自己在操作，如果頁面?zhèn)魅氲暮彤a(chǎn)生的token不相同那么這就是其他人員通過模擬用戶進(jìn)行了這樣的操作，那么我們就要對它進(jìn)行處理，讓它跳轉(zhuǎn)到登錄頁面。

118.sql 注入的思路及攻擊實(shí)例

SQL注入攻擊的總體思路1.尋找到SQL注入的位置2.判斷服務(wù)器類型和后臺數(shù)據(jù)庫類型3.針對不通的服務(wù)器和數(shù)據(jù)庫特點(diǎn)進(jìn)行SQL注入攻擊SQL注入攻擊實(shí)例比如在一個(gè)登錄界面，要求輸入用戶名和密碼：可以這樣輸入實(shí)現(xiàn)免帳號登錄：用戶名： ‘or 1 = 1 –密 碼：點(diǎn)登陸,如若沒有做特殊處理,那么這個(gè)非法用戶就很得意的登陸進(jìn)去了.(當(dāng)然現(xiàn)在的有些語言的數(shù)據(jù)庫API已經(jīng)處理了這些問題)這是為什么呢? 下面我們分析一下：從理論上說，后臺認(rèn)證程序中會有如下的SQL語句：String sql = "select * from user_table where username= " userName " and password= " password " ";當(dāng)輸入了上面的用戶名和密碼，上面的SQL語句變成：SELECT * FROM user_table WHERE username=’or 1 = 1 -- and password=’分析SQL語句：條件后面username=”or 1=1 用戶名等于 ” 或1=1 那么這個(gè)條件一定會成功；然后后面加兩個(gè)-，這意味著注釋，它將后面的語句注釋，讓他們不起作用，這樣語句永遠(yuǎn)都能正確執(zhí)行，用戶輕易騙過系統(tǒng)，獲取合法身份。這還是比較溫柔的，如果是執(zhí)行SELECT * FROM user_table WHEREusername= ;DROP DATABASE (DB Name) -- and password=

119. 防止 sql 注入

1.（簡單又有效的方法）PreparedStatement采用預(yù)編譯語句集，它內(nèi)置了處理SQL注入的能力，只要使用它的setXXX方法傳值即可。使用好處：(1).代碼的可讀性和可維護(hù)性.(2).PreparedStatement盡最大可能提高性能.(3).最重要的一點(diǎn)是極大地提高了安全性.原理：sql注入只對sql語句的準(zhǔn)備(編譯)過程有破壞作用而PreparedStatement已經(jīng)準(zhǔn)備好了,執(zhí)行階段只是把輸入串作為數(shù)據(jù)處理,而不再對sql語句進(jìn)行解析,準(zhǔn)備,因此也就避免了sql注入問題.2.使用正則表達(dá)式過濾傳入的參數(shù)要引入的包：import java.util.regex.*;正則表達(dá)式：private String CHECKSQL = “^(. )\sand\s(. )|(. )\sor(. )\s$”;判斷是否匹配：Pattern.matches(CHECKSQL,targerStr);下面是具體的正則表達(dá)式：檢測SQL meta-characters的正則表達(dá)式 ：/()|(’)|(--)|(#)|(#)/ix修正檢測SQL meta-characters的正則表達(dá)式 ：/((=)|(=))[^ ]*(()|(’)|(--)|(;)|(:))/i典型的SQL 注入攻擊的正則表達(dá)式 ：/w*(()|(’))((o)|o|(O))(( )|r|(R))/ix檢測SQL注入，UNION查詢關(guān)鍵字的正則表達(dá)式 ：/(()|(’))union/ix()|(’)檢測MS SQL Server SQL注入攻擊的正則表達(dá)式：/exec(s| ) (s|x)pw /ix3.字符串過濾

120. 第三方支付常見幾種支付方式的流程設(shè)計(jì)121. 如何設(shè)計(jì)支付接口

1.接口規(guī)則傳輸方式 為保證交易安全性，采用HTTPS傳輸提交方式 采用POST方法提交數(shù)據(jù)格式 提交和返回?cái)?shù)據(jù)都為XML格式，根節(jié)點(diǎn)名為xml字符編碼 統(tǒng)一采用UTF-8字符編碼簽名算法 MD5，后續(xù)會兼容SHA1、SHA256、HMAC等。簽名要求 請求和接收數(shù)據(jù)均需要校驗(yàn)簽名，詳細(xì)方法請參考安全規(guī)范-簽名算法證書要求 調(diào)用申請退款、撤銷訂單接口需要商戶證書判斷邏輯 先判斷協(xié)議字段返回，再判斷業(yè)務(wù)返回，最后判斷交易狀態(tài)2.參數(shù)規(guī)定1、交易金額交易金額默認(rèn)為人民幣交易，接口中參數(shù)支付金額單位為【分】，參數(shù)值不能帶小數(shù)。對賬單中的交易金額單位為【元】。外幣交易的支付金額精確到幣種的最小單位，參數(shù)值不能帶小數(shù)點(diǎn)。2、交易類型JSAPI--JSAPI支付（或小程序支付）、NATIVE--Native支付、APP--app支付，MWEB--H5支付，不同trade_type決定了調(diào)起支付的方式，請根據(jù)支付產(chǎn)品正確上傳MICROPAY--付款碼支付，付款碼支付有單獨(dú)的支付接口，所以接口不需要上傳，該字段在對賬單中會出現(xiàn)3、貨幣類型貨幣類型的取值列表：CNY：人民幣4、時(shí)間標(biāo)準(zhǔn)北京時(shí)間，時(shí)區(qū)為東八區(qū)；如果商戶的系統(tǒng)時(shí)間為非標(biāo)準(zhǔn)北京時(shí)間。參數(shù)值必須根據(jù)商戶系統(tǒng)所在時(shí)區(qū)先換算成標(biāo)準(zhǔn)北京時(shí)間， 例如商戶所在地為0時(shí)區(qū)的倫敦，當(dāng)?shù)貢r(shí)間為2014年11月11日0時(shí)0分0秒，換算成北京時(shí)間為2014年11月11日8時(shí)0分0秒。5、時(shí)間戳標(biāo)準(zhǔn)北京時(shí)間，時(shí)區(qū)為東八區(qū)，自1970年1月1日 0點(diǎn)0分0秒以來的秒數(shù)。注意：部分系統(tǒng)取到的值為毫秒級，需要轉(zhuǎn)換成秒(10位數(shù)字)。6、商戶訂單號商戶支付的訂單號由商戶自定義生成，僅支持使用字母、數(shù)字、中劃線-、下劃線_、豎線|、星號*這些英文半角字符的組合，請勿使用漢字或全角等特殊字符。微信支付要求商戶訂單號保持唯一性（建議根據(jù)當(dāng)前系統(tǒng)時(shí)間加隨機(jī)序列來生成訂單號）。重新發(fā)起一筆支付要使用原訂單號，避免重復(fù)支付；已支付過或已調(diào)用關(guān)單、撤銷（請見后文的API列表）的訂單號不能重新發(fā)起支付。7、body字段格式使用場景 支付模式 商品字段規(guī)則 樣例 備注PC網(wǎng)站 掃碼支付 瀏覽器打開的網(wǎng)站主頁title名 -商品概述 騰訊充值中心-QQ會員充值微信瀏覽器 公眾號支付 商家名稱-銷售商品類目 騰訊-游戲 線上電商，商家名稱必須為實(shí)際銷售商品的商家門店掃碼 公眾號支付 店名-銷售商品類目 小張南山店-超市 線下門店支付門店掃碼 掃碼支付 店名-銷售商品類目 小張南山店-超市 線下門店支付門店刷卡 刷卡支付 店名-銷售商品類目 小張南山店-超市 線下門店支付第三方手機(jī)瀏覽器 H5支付 瀏覽器打開的移動(dòng)網(wǎng)頁的主頁title名-商品概述 騰訊充值中心-QQ會員充值第三方APP APP支付 應(yīng)用市場上的APP名字-商品概述 天天愛消除-游戲充值8、銀行類型3.安全規(guī)范1、簽名算法（簽名校驗(yàn)工具）簽名生成的通用步驟如下：第一步，設(shè)所有發(fā)送或者接收到的數(shù)據(jù)為集合M，將集合M內(nèi)非空參數(shù)值的參數(shù)按照參數(shù)名ASCII碼從小到大排序（字典序），使用URL鍵值對的格式（即key1=value1&key2=value2…）拼接成字符串stringA。特別注意以下重要規(guī)則：◆ 參數(shù)名ASCII碼從小到大排序（字典序）；◆ 如果參數(shù)的值為空不參與簽名；◆ 參數(shù)名區(qū)分大小寫；◆ 驗(yàn)證調(diào)用返回或微信主動(dòng)通知簽名時(shí)，傳送的sign參數(shù)不參與簽名，將生成的簽名與該sign值作校驗(yàn)。◆ 微信接口可能增加字段，驗(yàn)證簽名時(shí)必須支持增加的擴(kuò)展字段第二步，在stringA最后拼接上key得到stringSignTemp字符串，并對stringSignTemp進(jìn)行MD5運(yùn)算，再將得到的字符串所有字符轉(zhuǎn)換為大寫，得到sign值signValue。◆ key設(shè)置路徑：微信商戶平臺(微信支付 - 中國領(lǐng)先的第三方支付平臺 ｜ 微信支付提供安全快捷的支付方式)-->賬戶設(shè)置-->API安全-->密鑰設(shè)置第一步：對參數(shù)按照key=value的格式，并按照參數(shù)名ASCII字典序排序如下：第二步：拼接API密鑰：2、生成隨機(jī)數(shù)算法微信支付API接口協(xié)議中包含字段nonce_str，主要保證簽名不可預(yù)測。我們推薦生成隨機(jī)數(shù)算法如下：調(diào)用隨機(jī)數(shù)函數(shù)生成，將得到的值轉(zhuǎn)換為字符串。3、API證書（1）獲取API證書（什么是api證書？如何升級？）微信支付接口中，涉及資金回滾的接口會使用到API證書，包括退款、撤銷接口。商家在申請微信支付成功后，收到的相應(yīng)郵件后，可以按照指引下載API證書，也可以按照以下路徑下載：微信商戶平臺(微信支付 - 中國領(lǐng)先的第三方支付平臺 ｜ 微信支付提供安全快捷的支付方式)-->賬戶中心-->賬戶設(shè)置-->API安全 。證書文件說明如下：證書附件 描述 使用場景 備注pkcs12格式(apiclient_cert.p12、 包含了私鑰信息的證書文件，為p12(pfx)格式，由微信支付簽發(fā)給您用來標(biāo)識和界定您的身份 撤銷、退款申請API中調(diào)用 windows上可以直接雙擊導(dǎo)入系統(tǒng)，導(dǎo)入過程中會提示輸入證書密碼，證書密碼默認(rèn)為您的商戶ID（如：10010000）以下兩個(gè)證書在PHP環(huán)境中使用：證書附件 描述 使用場景 備注證書pem格式（apiclient_cert.pem） 從apiclient_cert.p12中導(dǎo)出證書部分的文件，為pem格式，請妥善保管不要泄漏和被他人復(fù)制 PHP等不能直接使用p12文件，而需要使用pem，為了方便您使用，已為您直接提供 您也可以使用openssl命令來自己導(dǎo)出：openssl pkcs12 -clcerts -nokeys -in apiclient_cert.p12 -out apiclient_cert.pem證書密鑰pem格式（apiclient_key.pem） 從apiclient_key.pem中導(dǎo)出密鑰部分的文件，為pem格式，請妥善保管不要泄漏和被他人復(fù)制 PHP等不能直接使用p12文件，而需要使用pem，為了方便您使用，已為您直接提供 您也可以使用openssl命令來自己導(dǎo)出：openssl pkcs12 -nocerts -in apiclient_cert.p12 -out apiclient_key.pem（2）使用API證書◆ apiclient_cert.p12是商戶證書文件，除PHP外的開發(fā)均使用此證書文件。◆ 商戶如果使用.NET環(huán)境開發(fā)，請確認(rèn)Framework版本大于2.0，必須在操作系統(tǒng)上雙擊安裝證書apiclient_cert.p12后才能被正常調(diào)用。◆ API證書調(diào)用或安裝需要使用到密碼，該密碼的值為微信商戶號（mch_id）（3）API證書安全1.證書文件不能放在web服務(wù)器虛擬目錄，應(yīng)放在有訪問權(quán)限控制的目錄中，防止被他人下載；2.建議將證書文件名改為復(fù)雜且不容易猜測的文件名；3.商戶服務(wù)器要做好病毒和木馬防護(hù)工作，不被非法侵入者竊取證書文件。4、商戶回調(diào)API安全在普通的網(wǎng)絡(luò)環(huán)境下，HTTP請求存在DNS劫持、運(yùn)營商插入廣告、數(shù)據(jù)被竊取，正常數(shù)據(jù)被修改等安全風(fēng)險(xiǎn)。商戶回調(diào)接口使用HTTPS協(xié)議可以保證數(shù)據(jù)傳輸?shù)陌踩浴Ｋ晕⑿胖Ц督ㄗh商戶提供給微信支付的各種回調(diào)采用HTTPS協(xié)議。pay.weixin.qq.com/wiki/doc/api/app...

122. 狀態(tài)碼

1 消息? 100 Continue? 101 Switching Protocols? 102 Processing2 成功? 200 OK? 201 Created? 202 Accepted? 203 Non-Authoritative Information? 204 No Content? 205 Reset Content? 206 Partial Content? 207 Multi-Status3 重定向? 300 Multiple Choices? 301 Moved Permanently? 302 Move temporarily? 303 See Other? 304 Not Modified? 305 Use Proxy? 306 Switch Proxy? 307 Temporary Redirect4 請求錯(cuò)誤? 400 Bad Request? 401 Unauthorized? 402 Payment Required? 403 Forbidden? 404 Not Found? 405 Method Not Allowed? 406 Not Acceptable? 407 Proxy Authentication Required? 408 Request Timeout? 409 Conflict? 410 Gone? 411 Length Required? 412 Precondition Failed? 413 Request Entity Too Large? 414 Request-URI Too Long? 415 Unsupported Media Type? 416 Requested Range Not Satisfiable? 417 Expectation Failed? 421 too many connections? 422 Unprocessable Entity? 423 Locked? 424 Failed Dependency? 425 Unordered Collection? 426 Upgrade Required? 449 Retry With? 451Unavailable For Legal Reasons5 服務(wù)器錯(cuò)誤? 500 Internal Server Error? 501 Not Implemented? 502 Bad Gateway? 503 Service Unavailable? 504 Gateway Timeout? 505 HTTP Version Not Supported? 506 Variant Also Negotiates? 507 Insufficient Storage? 509 Bandwidth Limit Exceeded? 510 Not Extended? 600 Unparseable Response Headers

100 客戶端應(yīng)當(dāng)繼續(xù)發(fā)送請求。這個(gè)臨時(shí)響應(yīng)是用來通知客戶端它的部分請求已經(jīng)被服務(wù)器接收，且仍未被拒絕。客戶端應(yīng)當(dāng)繼續(xù)發(fā)送請求的剩余部分，或者如果請求已經(jīng)完成，忽略這個(gè)響應(yīng)。服務(wù)器必須在請求完成后向客戶端發(fā)送一個(gè)最終響應(yīng)。101 服務(wù)器已經(jīng)理解了客戶端的請求，并將通過Upgrade 消息頭通知客戶端采用不同的協(xié)議來完成這個(gè)請求。在發(fā)送完這個(gè)響應(yīng)最后的空行后，服務(wù)器將會切換到在Upgrade 消息頭中定義的那些協(xié)議。 　　只有在切換新的協(xié)議更有好處的時(shí)候才應(yīng)該采取類似措施。例如，切換到新的HTTP 版本比舊版本更有優(yōu)勢，或者切換到一個(gè)實(shí)時(shí)且同步的協(xié)議以傳送利用此類特性的資源。102 由WebDAV（RFC 2518）擴(kuò)展的狀態(tài)碼，代表處理將被繼續(xù)執(zhí)行。200 請求已成功，請求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回。201 請求已經(jīng)被實(shí)現(xiàn)，而且有一個(gè)新的資源已經(jīng)依據(jù)請求的需要而建立，且其 URI 已經(jīng)隨Location 頭信息返回。假如需要的資源無法及時(shí)建立的話，應(yīng)當(dāng)返回 202 Accepted。202 服務(wù)器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執(zhí)行。在異步操作的場合下，沒有比發(fā)送這個(gè)狀態(tài)碼更方便的做法了。 　　返回202狀態(tài)碼的響應(yīng)的目的是允許服務(wù)器接受其他過程的請求（例如某個(gè)每天只執(zhí)行一次的基于批處理的操作），而不必讓客戶端一直保持與服務(wù)器的連接直到批處理操作全部完成。在接受請求處理并返回202狀態(tài)碼的響應(yīng)應(yīng)當(dāng)在返回的實(shí)體中包含一些指示處理當(dāng)前狀態(tài)的信息，以及指向處理狀態(tài)監(jiān)視器或狀態(tài)預(yù)測的指針，以便用戶能夠估計(jì)操作是否已經(jīng)完成。203 服務(wù)器已成功處理了請求，但返回的實(shí)體頭部元信息不是在原始服務(wù)器上有效的確定集合，而是來自本地或者第三方的拷貝。當(dāng)前的信息可能是原始版本的子集或者超集。例如，包含資源的元數(shù)據(jù)可能導(dǎo)致原始服務(wù)器知道元信息的超級。使用此狀態(tài)碼不是必須的，而且只有在響應(yīng)不使用此狀態(tài)碼便會返回200 OK的情況下才是合適的。204 服務(wù)器成功處理了請求，但不需要返回任何實(shí)體內(nèi)容，并且希望返回更新了的元信息。響應(yīng)可能通過實(shí)體頭部的形式，返回新的或更新后的元信息。如果存在這些頭部信息，則應(yīng)當(dāng)與所請求的變量相呼應(yīng)。 　　如果客戶端是瀏覽器的話，那么用戶瀏覽器應(yīng)保留發(fā)送了該請求的頁面，而不產(chǎn)生任何文檔視圖上的變化，即使按照規(guī)范新的或更新后的元信息應(yīng)當(dāng)被應(yīng)用到用戶瀏覽器活動(dòng)視圖中的文檔。 　　由于204響應(yīng)被禁止包含任何消息體，因此它始終以消息頭后的第一個(gè)空行結(jié)尾。205 服務(wù)器成功處理了請求，且沒有返回任何內(nèi)容。但是與204響應(yīng)不同，返回此狀態(tài)碼的響應(yīng)要求請求者重置文檔視圖。該響應(yīng)主要是被用于接受用戶輸入后，立即重置表單，以便用戶能夠輕松地開始另一次輸入。 　　與204響應(yīng)一樣，該響應(yīng)也被禁止包含任何消息體，且以消息頭后的第一個(gè)空行結(jié)束。206 服務(wù)器已經(jīng)成功處理了部分 GET 請求。類似于 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應(yīng)實(shí)現(xiàn)斷點(diǎn)續(xù)傳或者將一個(gè)大文檔分解為多個(gè)下載段同時(shí)下載。 　　該請求必須包含 Range 頭信息來指示客戶端希望得到的內(nèi)容范圍，并且可能包含 If-Range 來作為請求條件。 　　響應(yīng)必須包含如下的頭部域： 　　Content-Range 用以指示本次響應(yīng)中返回的內(nèi)容的范圍；如果是 Content-Type 為 multipart/byteranges 的多段下載，則每一 multipart 段中都應(yīng)包含 Content-Range 域用以指示本段的內(nèi)容范圍。假如響應(yīng)中包含 Content-Length，那么它的數(shù)值必須匹配它返回的內(nèi)容范圍的真實(shí)字節(jié)數(shù)。 　　Date 　　ETag 和/或 Content-Location，假如同樣的請求本應(yīng)該返回200響應(yīng)。 　　Expires, Cache-Control，和/或 Vary，假如其值可能與之前相同變量的其他響應(yīng)對應(yīng)的值不同的話。 　　假如本響應(yīng)請求使用了 If-Range 強(qiáng)緩存驗(yàn)證，那么本次響應(yīng)不應(yīng)該包含其他實(shí)體頭；假如本響應(yīng)的請求使用了 If-Range 弱緩存驗(yàn)證，那么本次響應(yīng)禁止包含其他實(shí)體頭；這避免了緩存的實(shí)體內(nèi)容和更新了的實(shí)體頭信息之間的不一致。否則，本響應(yīng)就應(yīng)當(dāng)包含所有本應(yīng)該返回200響應(yīng)中應(yīng)當(dāng)返回的所有實(shí)體頭部域。 　　假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則客戶端緩存應(yīng)禁止將206響應(yīng)返回的內(nèi)容與之前任何緩存過的內(nèi)容組合在一起。 　　任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應(yīng)返回的內(nèi)容。207 由WebDAV(RFC 2518)擴(kuò)展的狀態(tài)碼，代表之后的消息體將是一個(gè)XML消息，并且可能依照之前子請求數(shù)量的不同，包含一系列獨(dú)立的響應(yīng)代碼。300 被請求的資源有一系列可供選擇的回饋信息，每個(gè)都有自己特定的地址和瀏覽器驅(qū)動(dòng)的商議信息。用戶或?yàn)g覽器能夠自行選擇一個(gè)首選的地址進(jìn)行重定向。 　　除非這是一個(gè) HEAD 請求，否則該響應(yīng)應(yīng)當(dāng)包括一個(gè)資源特性及地址的列表的實(shí)體，以便用戶或?yàn)g覽器從中選擇最合適的重定向地址。這個(gè)實(shí)體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據(jù)響應(yīng)的格式以及瀏覽器自身能力，自動(dòng)作出最合適的選擇。當(dāng)然，RFC 2616規(guī)范并沒有規(guī)定這樣的自動(dòng)選擇該如何進(jìn)行。 　　如果服務(wù)器本身已經(jīng)有了首選的回饋選擇，那么在 Location 中應(yīng)當(dāng)指明這個(gè)回饋的 URI；瀏覽器可能會將這個(gè) Location 值作為自動(dòng)重定向的地址。此外，除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。301 被請求的資源已永久移動(dòng)到新位置，并且將來任何對此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個(gè) URI 之一。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動(dòng)把請求的地址修改為從服務(wù)器反饋回來的地址。除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。 　　新的永久性的 URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡短說明。 　　如果這不是一個(gè) GET 或者 HEAD 請求，因此瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎埱蟮臈l件可能因此發(fā)生變化。 　　注意：對于某些使用 HTTP/1.0 協(xié)議的瀏覽器，當(dāng)它們發(fā)送的 POST 請求得到了一個(gè)301響應(yīng)的話，接下來的重定向請求將會變成 GET 方式。302 請求的資源現(xiàn)在臨時(shí)從不同的 URI 響應(yīng)請求。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。 　　新的臨時(shí)性的 URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡短說明。 　　如果這不是一個(gè) GET 或者 HEAD 請求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎埱蟮臈l件可能因此發(fā)生變化。 　　注意：雖然RFC 1945和RFC 2068規(guī)范不允許客戶端在重定向時(shí)改變請求的方法，但是很多現(xiàn)存的瀏覽器將302響應(yīng)視作為303響應(yīng)，并且使用 GET 方式訪問在 Location 中規(guī)定的 URI，而無視原先請求的方法。狀態(tài)碼303和307被添加了進(jìn)來，用以明確服務(wù)器期待客戶端進(jìn)行何種反應(yīng)。303 對應(yīng)當(dāng)前請求的響應(yīng)可以在另一個(gè) URI 上被找到，而且客戶端應(yīng)當(dāng)采用 GET 的方式訪問那個(gè)資源。這個(gè)方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個(gè)新的資源。這個(gè)新的 URI 不是原始資源的替代引用。同時(shí)，303響應(yīng)禁止被緩存。當(dāng)然，第二個(gè)請求（重定向）可能被緩存。 　　新的 URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡短說明。 　　注意：許多 HTTP/1.1 版以前的 瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互動(dòng)，302狀態(tài)碼應(yīng)該可以勝任，因?yàn)榇蠖鄶?shù)的瀏覽器處理302響應(yīng)時(shí)的方式恰恰就是上述規(guī)范要求客戶端處理303響應(yīng)時(shí)應(yīng)當(dāng)做的。304 如果客戶端發(fā)送了一個(gè)帶條件的 GET 請求且該請求已被允許，而文檔的內(nèi)容（自上次訪問以來或者根據(jù)請求的條件）并沒有改變，則服務(wù)器應(yīng)當(dāng)返回這個(gè)狀態(tài)碼。304響應(yīng)禁止包含消息體，因此始終以消息頭后的第一個(gè)空行結(jié)尾。 　　該響應(yīng)必須包含以下的頭信息： 　　Date，除非這個(gè)服務(wù)器沒有時(shí)鐘。假如沒有時(shí)鐘的服務(wù)器也遵守這些規(guī)則，那么代理服務(wù)器以及客戶端可以自行將 Date 字段添加到接收到的響應(yīng)頭中去（正如RFC 2068中規(guī)定的一樣），緩存機(jī)制將會正常工作。 　　ETag 和/或 Content-Location，假如同樣的請求本應(yīng)返回200響應(yīng)。 　　Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應(yīng)對應(yīng)的值不同的話。 　　假如本響應(yīng)請求使用了強(qiáng)緩存驗(yàn)證，那么本次響應(yīng)不應(yīng)該包含其他實(shí)體頭；否則（例如，某個(gè)帶條件的 GET 請求使用了弱緩存驗(yàn)證），本次響應(yīng)禁止包含其他實(shí)體頭；這避免了緩存了的實(shí)體內(nèi)容和更新了的實(shí)體頭信息之間的不一致。 　　假如某個(gè)304響應(yīng)指明了當(dāng)前某個(gè)實(shí)體沒有緩存，那么緩存系統(tǒng)必須忽視這個(gè)響應(yīng)，并且重復(fù)發(fā)送不包含限制條件的請求。 　　假如接收到一個(gè)要求更新某個(gè)緩存條目的304響應(yīng)，那么緩存系統(tǒng)必須更新整個(gè)條目以反映所有在響應(yīng)中被更新的字段的值。305 被請求的資源必須通過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者需要重復(fù)發(fā)送一個(gè)單獨(dú)的請求，通過這個(gè)代理才能訪問相應(yīng)資源。只有原始服務(wù)器才能建立305響應(yīng)。 　　注意：RFC 2068中沒有明確305響應(yīng)是為了重定向一個(gè)單獨(dú)的請求，而且只能被原始服務(wù)器建立。忽視這些限制可能導(dǎo)致嚴(yán)重的安全后果。306 在最新版的規(guī)范中，306狀態(tài)碼已經(jīng)不再被使用。307 請求的資源現(xiàn)在臨時(shí)從不同的URI 響應(yīng)請求。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。 　　新的臨時(shí)性的URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè)HEAD 請求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的URI 的超鏈接及簡短說明。因?yàn)椴糠譃g覽器不能識別307響應(yīng)，因此需要添加上述必要信息以便用戶能夠理解并向新的 URI 發(fā)出訪問請求。 　　如果這不是一個(gè)GET 或者 HEAD 請求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎埱蟮臈l件可能因此發(fā)生變化。400 1、語義有誤，當(dāng)前請求無法被服務(wù)器理解。除非進(jìn)行修改，否則客戶端不應(yīng)該重復(fù)提交這個(gè)請求。 　　2、請求參數(shù)有誤。401 當(dāng)前請求需要用戶驗(yàn)證。該響應(yīng)必須包含一個(gè)適用于被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端可以重復(fù)提交一個(gè)包含恰當(dāng)?shù)?Authorization 頭信息的請求。如果當(dāng)前請求已經(jīng)包含了 Authorization 證書，那么401響應(yīng)代表著服務(wù)器驗(yàn)證已經(jīng)拒絕了那些證書。如果401響應(yīng)包含了與前一個(gè)響應(yīng)相同的身份驗(yàn)證詢問，且瀏覽器已經(jīng)至少嘗試了一次驗(yàn)證，那么瀏覽器應(yīng)當(dāng)向用戶展示響應(yīng)中包含的實(shí)體信息，因?yàn)檫@個(gè)實(shí)體信息中可能包含了相關(guān)診斷信息。參見RFC 2617。402 該狀態(tài)碼是為了將來可能的需求而預(yù)留的。403 服務(wù)器已經(jīng)理解請求，但是拒絕執(zhí)行它。與401響應(yīng)不同的是，身份驗(yàn)證并不能提供任何幫助，而且這個(gè)請求也不應(yīng)該被重復(fù)提交。如果這不是一個(gè) HEAD 請求，而且服務(wù)器希望能夠講清楚為何請求不能被執(zhí)行，那么就應(yīng)該在實(shí)體內(nèi)描述拒絕的原因。當(dāng)然服務(wù)器也可以返回一個(gè)404響應(yīng)，假如它不希望讓客戶端獲得任何信息。404 請求失敗，請求所希望得到的資源未被在服務(wù)器上發(fā)現(xiàn)。沒有信息能夠告訴用戶這個(gè)狀況到底是暫時(shí)的還是永久的。假如服務(wù)器知道情況的話，應(yīng)當(dāng)使用410狀態(tài)碼來告知舊資源因?yàn)槟承﹥?nèi)部的配置機(jī)制問題，已經(jīng)永久的不可用，而且沒有任何可以跳轉(zhuǎn)的地址。404這個(gè)狀態(tài)碼被廣泛應(yīng)用于當(dāng)服務(wù)器不想揭示到底為何請求被拒絕或者沒有其他適合的響應(yīng)可用的情況下。405 請求行中指定的請求方法不能被用于請求相應(yīng)的資源。該響應(yīng)必須返回一個(gè)Allow 頭信息用以表示出當(dāng)前資源能夠接受的請求方法的列表。鑒于 PUT，DELETE 方法會對服務(wù)器上的資源進(jìn)行寫操作，因而絕大部分的網(wǎng)頁服務(wù)器都不支持或者在默認(rèn)配置下不允許上述請求方法，對于此類請求均會返回405錯(cuò)誤。406 請求的資源的內(nèi)容特性無法滿足請求頭中的條件，因而無法生成響應(yīng)實(shí)體。 　　除非這是一個(gè) HEAD 請求，否則該響應(yīng)就應(yīng)當(dāng)返回一個(gè)包含可以讓用戶或者瀏覽器從中選擇最合適的實(shí)體特性以及地址列表的實(shí)體。實(shí)體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器可以根據(jù)格式及自身能力自行作出最佳選擇。但是，規(guī)范中并沒有定義任何作出此類自動(dòng)選擇的標(biāo)準(zhǔn)。407 　與401響應(yīng)類似，只不過客戶端必須在代理服務(wù)器上進(jìn)行身份驗(yàn)證。代理服務(wù)器必須返回一個(gè) Proxy-Authenticate 用以進(jìn)行身份詢問。客戶端可以返回一個(gè) Proxy-Authorization 信息頭用以驗(yàn)證。參見RFC 2617。408 請求超時(shí)。客戶端沒有在服務(wù)器預(yù)備等待的時(shí)間內(nèi)完成一個(gè)請求的發(fā)送。客戶端可以隨時(shí)再次提交這一請求而無需進(jìn)行任何更改。409 由于和被請求的資源的當(dāng)前狀態(tài)之間存在沖突，請求無法完成。這個(gè)代碼只允許用在這樣的情況下才能被使用：用戶被認(rèn)為能夠解決沖突，并且會重新提交新的請求。該響應(yīng)應(yīng)當(dāng)包含足夠的信息以便用戶發(fā)現(xiàn)沖突的源頭。沖突通常發(fā)生于對 PUT 請求的處理中。例如，在采用版本檢查的環(huán)境下，某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與之前的某個(gè)（第三方）請求向沖突，那么此時(shí)服務(wù)器就應(yīng)該返回一個(gè)409錯(cuò)誤，告知用戶請求無法完成。此時(shí)，響應(yīng)實(shí)體中很可能會包含兩個(gè)沖突版本之間的差異比較，以便用戶重新提交歸并以后的新版本。410 被請求的資源在服務(wù)器上已經(jīng)不再可用，而且沒有任何已知的轉(zhuǎn)發(fā)地址。這樣的狀況應(yīng)當(dāng)被認(rèn)為是永久性的。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)在獲得用戶許可后刪除所有指向這個(gè)地址的引用。如果服務(wù)器不知道或者無法確定這個(gè)狀況是否是永久的，那么就應(yīng)該使用404狀態(tài)碼。除非額外說明，否則這個(gè)響應(yīng)是可緩存的。 　　410響應(yīng)的目的主要是幫助網(wǎng)站管理員維護(hù)網(wǎng)站，通知用戶該資源已經(jīng)不再可用，并且服務(wù)器擁有者希望所有指向這個(gè)資源的遠(yuǎn)端連接也被刪除。這類事件在限時(shí)、增值服務(wù)中很普遍。同樣，410響應(yīng)也被用于通知客戶端在當(dāng)前服務(wù)器站點(diǎn)上，原本屬于某個(gè)個(gè)人的資源已經(jīng)不再可用。當(dāng)然，是否需要把所有永久不可用的資源標(biāo)記為410 Gone，以及是否需要保持此標(biāo)記多長時(shí)間，完全取決于服務(wù)器擁有者。411 服務(wù)器拒絕在沒有定義 Content-Length 頭的情況下接受請求。在添加了表明請求消息體長度的有效 Content-Length 頭之后，客戶端可以再次提交該請求。412 服務(wù)器在驗(yàn)證在請求的頭字段中給出先決條件時(shí)，沒能滿足其中的一個(gè)或多個(gè)。這個(gè)狀態(tài)碼允許客戶端在獲取資源時(shí)在請求的元信息（請求頭字段數(shù)據(jù)）中設(shè)置先決條件，以此避免該請求方法被應(yīng)用到其希望的內(nèi)容以外的資源上。413 服務(wù)器拒絕處理當(dāng)前請求，因?yàn)樵撜埱筇峤坏膶?shí)體數(shù)據(jù)大小超過了服務(wù)器愿意或者能夠處理的范圍。此種情況下，服務(wù)器可以關(guān)閉連接以免客戶端繼續(xù)發(fā)送此請求。如果這個(gè)狀況是臨時(shí)的，服務(wù)器應(yīng)當(dāng)返回一個(gè) Retry-After 的響應(yīng)頭，以告知客戶端可以在多少時(shí)間以后重新嘗試。414 請求的URI 長度超過了服務(wù)器能夠解釋的長度，因此服務(wù)器拒絕對該請求提供服務(wù)。這比較少見，通常的情況包括： 　　本應(yīng)使用POST方法的表單提交變成了GET方法，導(dǎo)致查詢字符串（Query String）過長。 　　重定向URI “黑洞”，例如每次重定向把舊的 URI 作為新的 URI 的一部分，導(dǎo)致在若干次重定向后 URI 超長。 　　客戶端正在嘗試?yán)媚承┓?wù)器中存在的安全漏洞攻擊服務(wù)器。這類服務(wù)器使用固定長度的緩沖讀取或操作請求的 URI，當(dāng) GET 后的參數(shù)超過某個(gè)數(shù)值后，可能會產(chǎn)生緩沖區(qū)溢出，導(dǎo)致任意代碼被執(zhí)行[1]。沒有此類漏洞的服務(wù)器，應(yīng)當(dāng)返回414狀態(tài)碼。415 對于當(dāng)前請求的方法和所請求的資源，請求中提交的實(shí)體并不是服務(wù)器中所支持的格式，因此請求被拒絕。416 如果請求中包含了 Range 請求頭，并且 Range 中指定的任何數(shù)據(jù)范圍都與當(dāng)前資源的可用范圍不重合，同時(shí)請求中又沒有定義 If-Range 請求頭，那么服務(wù)器就應(yīng)當(dāng)返回416狀態(tài)碼。 　　假如 Range 使用的是字節(jié)范圍，那么這種情況就是指請求指定的所有數(shù)據(jù)范圍的首字節(jié)位置都超過了當(dāng)前資源的長度。服務(wù)器也應(yīng)當(dāng)在返回416狀態(tài)碼的同時(shí)，包含一個(gè) Content-Range 實(shí)體頭，用以指明當(dāng)前資源的長度。這個(gè)響應(yīng)也被禁止使用 multipart/byteranges 作為其 Content-Type。417 在請求頭 Expect 中指定的預(yù)期內(nèi)容無法被服務(wù)器滿足，或者這個(gè)服務(wù)器是一個(gè)代理服務(wù)器，它有明顯的證據(jù)證明在當(dāng)前路由的下一個(gè)節(jié)點(diǎn)上，Expect 的內(nèi)容無法被滿足。421 從當(dāng)前客戶端所在的IP地址到服務(wù)器的連接數(shù)超過了服務(wù)器許可的最大范圍。通常，這里的IP地址指的是從服務(wù)器上看到的客戶端地址（比如用戶的網(wǎng)關(guān)或者代理服務(wù)器地址）。在這種情況下，連接數(shù)的計(jì)算可能涉及到不止一個(gè)終端用戶。422 從當(dāng)前客戶端所在的IP地址到服務(wù)器的連接數(shù)超過了服務(wù)器許可的最大范圍。通常，這里的IP地址指的是從服務(wù)器上看到的客戶端地址（比如用戶的網(wǎng)關(guān)或者代理服務(wù)器地址）。在這種情況下，連接數(shù)的計(jì)算可能涉及到不止一個(gè)終端用戶。422 請求格式正確，但是由于含有語義錯(cuò)誤，無法響應(yīng)。（RFC 4918 WebDAV）423 Locked 　　當(dāng)前資源被鎖定。（RFC 4918 WebDAV）424 由于之前的某個(gè)請求發(fā)生的錯(cuò)誤，導(dǎo)致當(dāng)前請求失敗，例如 PROPPATCH。（RFC 4918 WebDAV）425 在WebDav Advanced Collections 草案中定義，但是未出現(xiàn)在《WebDAV 順序集協(xié)議》（RFC 3658）中。426 客戶端應(yīng)當(dāng)切換到TLS/1.0。（RFC 2817）449 由微軟擴(kuò)展，代表請求應(yīng)當(dāng)在執(zhí)行完適當(dāng)?shù)牟僮骱筮M(jìn)行重試。500 服務(wù)器遇到了一個(gè)未曾預(yù)料的狀況，導(dǎo)致了它無法完成對請求的處理。一般來說，這個(gè)問題都會在服務(wù)器的程序碼出錯(cuò)時(shí)出現(xiàn)。501 服務(wù)器不支持當(dāng)前請求所需要的某個(gè)功能。當(dāng)服務(wù)器無法識別請求的方法，并且無法支持其對任何資源的請求。502 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時(shí)，從上游服務(wù)器接收到無效的響應(yīng)。503 由于臨時(shí)的服務(wù)器維護(hù)或者過載，服務(wù)器當(dāng)前無法處理請求。這個(gè)狀況是臨時(shí)的，并且將在一段時(shí)間以后恢復(fù)。如果能夠預(yù)計(jì)延遲時(shí)間，那么響應(yīng)中可以包含一個(gè) Retry-After 頭用以標(biāo)明這個(gè)延遲時(shí)間。如果沒有給出這個(gè)Retry-After 信息，那么客戶端應(yīng)當(dāng)以處理500響應(yīng)的方式處理它。 　　注意：503狀態(tài)碼的存在并不意味著服務(wù)器在過載的時(shí)候必須使用它。某些服務(wù)器只不過是希望拒絕客戶端的連接。504 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時(shí)，未能及時(shí)從上游服務(wù)器（URI標(biāo)識出的服務(wù)器，例如HTTP、FTP、LDAP）或者輔助服務(wù)器（例如DNS）收到響應(yīng)。 　　注意：某些代理服務(wù)器在DNS查詢超時(shí)時(shí)會返回400或者500錯(cuò)誤505 服務(wù)器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示著服務(wù)器不能或不愿使用與客戶端相同的版本。響應(yīng)中應(yīng)當(dāng)包含一個(gè)描述了為何版本不被支持以及服務(wù)器支持哪些協(xié)議的實(shí)體。506 由《透明內(nèi)容協(xié)商協(xié)議》（RFC 2295）擴(kuò)展，代表服務(wù)器存在內(nèi)部配置錯(cuò)誤：被請求的協(xié)商變元資源被配置為在透明內(nèi)容協(xié)商中使用自己，因此在一個(gè)協(xié)商處理中不是一個(gè)合適的重點(diǎn)。507 服務(wù)器無法存儲完成請求所必須的內(nèi)容。這個(gè)狀況被認(rèn)為是臨時(shí)的。WebDAV (RFC 4918)509 服務(wù)器達(dá)到帶寬限制。這不是一個(gè)官方的狀態(tài)碼，但是仍被廣泛使用。510 獲取資源所需要的策略并沒有沒滿足。（RFC 2774）

123. 如何使用 git 提交 合并 解決沖突？

124.interface 和 api 接口有什么區(qū)別？

125.access-token 是什么 ？

126. 什么是 curl？

127. 什么是 php curl？

128.json_encode 和 json_decode 區(qū)別？

129. 請講出幾個(gè)你常用的設(shè)計(jì)模式

130. 請寫一個(gè)算法列子 (冒泡等)

131.php 如何實(shí)現(xiàn)多線程 2018 以后版本

第一種:利用舊的 exec 函數(shù)通過異步處理方法實(shí)現(xiàn)多線程的，exec 函數(shù)本身就是一個(gè)執(zhí)行外部程序的 php 函數(shù)。第二:用于多線程的方法 (pthreads)它可以比上面使用 exec 的方法更簡單。詳情看 :http：//php.cn/php-weizijiaocheng-4147132. PHP7 和 PHP5 的區(qū)別，具體多了哪些新特性？性能提升了兩倍結(jié)合比較運(yùn)算符 (<=>)標(biāo)量類型聲明返回類型聲明try…catch 增加多條件判斷，更多 Error 錯(cuò)誤可以進(jìn)行異常處理匿名類，現(xiàn)在支持通過 new class 來實(shí)例化一個(gè)匿名類，這可以用來替代一些 “用后即焚” 的完整類定義…… 了解更多查看文章鏈接 PHP7 新特性

133. 為什么 PHP7 比 PHP5 性能提升了？

變量存儲字節(jié)減小，減少內(nèi)存占用，提升變量操作速度改善數(shù)組結(jié)構(gòu)，數(shù)組元素和 hash 映射表被分配在同一塊內(nèi)存里，降低了內(nèi)存占用、提升了 cpu 緩存命中率改進(jìn)了函數(shù)的調(diào)用機(jī)制，通過優(yōu)化參數(shù)傳遞的環(huán)節(jié)，減少了一些指令，提高執(zhí)行效率

134. laravel, 服務(wù)提供者是什么？

服務(wù)提供者是所有 Laravel 應(yīng)用程序引導(dǎo)啟動(dòng)的中心，Laravel 的核心服務(wù)器、注冊服務(wù)容器綁定、事件監(jiān)聽、中間件、路由注冊以及我們的應(yīng)用程序都是由服務(wù)提供者引導(dǎo)啟動(dòng)的。

135. IoC 容器是什么？

IoC（Inversion of Control）譯為 「控制反轉(zhuǎn)」，也被叫做「依賴注入」(DI)。什么是「控制反轉(zhuǎn)」？對象 A 功能依賴于對象 B，但是控制權(quán)由對象 A 來控制，控制權(quán)被顛倒，所以叫做「控制反轉(zhuǎn)」，而「依賴注入」是實(shí)現(xiàn) IoC 的方法，就是由 IoC 容器在運(yùn)行期間，動(dòng)態(tài)地將某種依賴關(guān)系注入到對象之中。其作用簡單來講就是利用依賴關(guān)系注入的方式，把復(fù)雜的應(yīng)用程序分解為互相合作的對象，從而降低解決問題的復(fù)雜度，實(shí)現(xiàn)應(yīng)用程序代碼的低耦合、高擴(kuò)展。Laravel 中的服務(wù)容器是用于管理類的依賴和執(zhí)行依賴注入的工具。

136. Facades 是什么？

Facades（一種設(shè)計(jì)模式，通常翻譯為外觀模式）提供了一個(gè)”static”（靜態(tài)）接口去訪問注冊到 IoC 容器中的類。提供了簡單、易記的語法，而無需記住必須手動(dòng)注入或配置的長長的類名。此外，由于對 PHP 動(dòng)態(tài)方法的獨(dú)特用法，也使測試起來非常容易。

137. Contract 是什么？

Contract（契約）是 laravel 定義框架提供的核心服務(wù)的接口。Contract 和 Facades 并沒有本質(zhì)意義上的區(qū)別，其作用就是使接口低耦合、更簡單。

138. 依賴注入的原理？

依賴注入 (DI) 和控制反轉(zhuǎn) (IOC) 是從不同的角度的描述的同一件事情，就是指通過引入 IOC 容器，利用依賴關(guān)系注入的方式，實(shí)現(xiàn)對象之間的解耦。我們把依賴注入應(yīng)用到軟件系統(tǒng)中，再來描述一下這個(gè)過程：對象 A 依賴于對象 B, 當(dāng)對象 A 需要用到對象 B 的時(shí)候，IOC 容器就會立即創(chuàng)建一個(gè)對象 B 送給對象 A。IOC 容器就是一個(gè)對象制造工廠，你需要什么，它會給你送去，你直接使用就行了，而再也不用去關(guān)心你所用的東西是如何制成的，也不用關(guān)心最后是怎么被銷毀的，這一切全部由 IOC 容器包辦。在傳統(tǒng)的實(shí)現(xiàn)中，由程序內(nèi)部代碼來控制組件之間的關(guān)系。我們經(jīng)常使用 new 關(guān)鍵字來實(shí)現(xiàn)兩個(gè)組件之間關(guān)系的組合，這種實(shí)現(xiàn)方式會造成組件之間耦合。IOC 很好地解決了該問題，它將實(shí)現(xiàn)組件間關(guān)系從程序內(nèi)部提到外部容器，也就是說由容器在運(yùn)行期將組件間的某種依賴關(guān)系動(dòng)態(tài)注入組件中。

139. 什么是 Composer， 工作原理是什么？

Composer 是 PHP 的一個(gè)依賴管理工具。工作原理就是將已開發(fā)好的擴(kuò)展包從 packagist.org composer 倉庫下載到我們的應(yīng)用程序中，并聲明依賴關(guān)系和版本控制。

140. 什么是索引，作用是什么？常見索引類型有那些？Mysql 建立索引的原則？

索引是一種特殊的文件，它們包含著對數(shù)據(jù)表里所有記錄的引用指針，相當(dāng)于書本的目錄。其作用就是加快數(shù)據(jù)的檢索效率。常見索引類型有主鍵、唯一索引、復(fù)合索引、全文索引。索引創(chuàng)建的原則最左前綴原理選擇區(qū)分度高的列作為索引盡量的擴(kuò)展索引，不要新建索引高并發(fā)如何處理？使用緩存優(yōu)化數(shù)據(jù)庫，提升數(shù)據(jù)庫使用效率負(fù)載均衡

####141. 設(shè)計(jì)模式之 SOLID 原則

php 設(shè)計(jì)模式不多說了，但是記住，要能講出來.SRP 單一責(zé)任原則OCP 開放封閉原則LSP 里氏替換原則ISP 接口隔離原則DIP 依賴倒置原則SOLID 原則原文鏈接####142. 其他 php 問題分庫分表怎么設(shè)計(jì)如何處理 MySQL 死鎖？談?wù)勀銓﹂]包的理解PHP 內(nèi)存回收機(jī)制如何解決 PHP 內(nèi)存溢出問題數(shù)據(jù)庫優(yōu)化的方法簡述 Laravel 的運(yùn)行原理Laravel 路由實(shí)現(xiàn)原理cookie 和 session 區(qū)別，session保存在服務(wù)器的哪里？服務(wù)端是如何獲取客戶端的 cookie？服務(wù)器集群搭建、負(fù)載均衡、反向代理服務(wù)器常用命令

喜歡我的文章就關(guān)注我吧，持續(xù)更新中.....