發現httppost請求目標網站會出現405 狀態碼，原因為 Apache、IIS、Nginx等絕大多數web服務器，都不允許靜態文件響應POST請求
所以將post請求改為get請求即可
跨域，請求按要求配置完畢之后，options預請求老是報錯。原因是webapi 默認的web.config有配置
有這么個配置，導致不行。要把他刪掉，還要加上
<!DOCTYPE html>
<html>
<head>
<title>JavaScript實現可視化展示冒泡排序過程</title>
<style>
#boxes{
border:1px solid grey;
width:1320px;
height:300px;
margin-top:10px;
position:relative;
}
.box{
background:red;
width:20px;
line-height:30px;
text-align:center;
font-family:Microsoft Yahei;
font-size:15px;
color:white;
margin:0 1px;
position:absolute;
}
</style>
</head>
<body>
<div id="boxes"></div>
<script>
function random(){
var numbers = [];
for (var i = 0; i < 60; i++) {
var number = Math.floor(Math.random() 90 + 10);
numbers.push(number);
var divElement = document.createElement("div");
var parentElement = document.getElementById("boxes");
divElement.style.left = i 20 + i 2 + "px";
divElement.style.top = 300 - 3 number + "px";
divElement.style.height = 3 number + "px";
divElement.setAttribute("class","box");
parentElement.appendChild(divElement);
}
return numbers;
}
function sort(){
var numbers = random();
var parentElement = document.getElementById("boxes");
var i = 0, j = 0;
var time = setInterval(function() {
if (i < numbers.length) {
if (j < numbers.length - i) {
if (numbers[j] > numbers[j + 1]) {
var temp = numbers[j];
numbers[j] = numbers[j + 1];
numbers[j + 1] = temp;
parentElement.innerHTML = "";
for (var k = 0; k < numbers.length; k++) {
var textNode = document.createTextNode(numbers[k]);
var divElement = document.createElement("div");
divElement.appendChild(textNode);
divElement.style.left = k 20 + k 2 + "px";
divElement.style.top = 300 - 3 numbers[k] + "px";
divElement.style.height = 3 * numbers[k] + "px";
divElement.setAttribute("class","box");
parentElement.appendChild(divElement);
}
}
j++;
}
else{
i++;
j = 0;
}
}
else {
clearInterval(time);
return;
}
}, 100);
}
sort();
</script>
</body>
</html>
————————————————
版權聲明：本文為CSDN博主「筱葭」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zhouziyu2011/java/article/details/53899692
1**：請求收到，繼續處理
2**：操作成功收到，分析、接受
3**：完成此請求必須進一步處理
4**：請求包含一個錯誤語法或不能完成
5**：服務器執行一個完全有效請求失敗
100——客戶必須繼續發出請求
101——客戶要求服務器根據請求轉換HTTP協議版本
200——交易成功
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請求收到，但返回信息為空
205——服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件
206——服務器已經完成了部分用戶的GET請求
300——請求的資源可在多處得到
301——刪除請求數據
302——在其他地址發現了請求數據
303——建議客戶訪問其他URL或訪問方式
304——客戶端已經執行了GET，但文件未變化
305——請求的資源必須從服務器指定的地址得到
306——前一版本HTTP中使用的代碼，現行版本中不再使用
307——申明請求的資源臨時性刪除
400——錯誤請求，如語法錯誤
401——請求授權失敗
402——保留有效ChargeTo頭響應
403——請求不允許
404——沒有發現文件、查詢或URl
405——用戶在Request-Line字段定義的方法不允許
406——根據用戶發送的Accept拖，請求資源不可訪問
407——類似401，用戶必須首先在代理服務器上得到授權
408——客戶端沒有在用戶指定的餓時間內完成請求
409——對當前資源狀態，請求不能完成
410——服務器上不再有此資源且無進一步的參考地址
411——服務器拒絕用戶定義的Content-Length屬性請求
412——一個或多個請求頭字段在當前請求中錯誤
413——請求的資源大于服務器允許的大小
414——請求的資源URL長于服務器允許的長度
415——請求資源不支持請求項目格式
416——請求中包含Range請求頭字段，在當前請求資源范圍內沒有range指示值，請求
也不包含If-Range請求頭字段
417——服務器不滿足請求Expect頭字段指定的期望值，如果是代理服務器，可能是下
一級服務器不能滿足請求
500——服務器產生內部錯誤
501——服務器不支持請求的函數
502——服務器暫時不可用，有時是為了防止發生系統過載
503——服務器過載或暫停維修
504——關口過載，服務器使用另一個關口或服務來響應用戶，等待時間設定值較長
505——服務器不支持或拒絕支請求頭中指定的HTTP版本
==========================================================
英文版：
100：Continue
101：Switching Protocols
102：Processing
200：OK
201：Created
202：Accepted
203：Non-Authoriative Information
204：No Content
205：Reset Content
206：Partial Content
207：Multi-Status
300：Multiple Choices
301：Moved Permanently
302：Found
303：See Other
304：Not Modified
305：Use Proxy
306：(Unused)
307：Temporary Redirect
400：Bad Request
401：Unauthorized
402：Payment Granted
403：Forbidden
404：File Not Found
405：Method Not Allowed
406：Not Acceptable
407：Proxy Authentication Required
408：Request Time-out
409：Conflict
410：Gone
411：Length Required
412：Precondition Failed
413：Request Entity Too Large
414：Request-URI Too Large
415：Unsupported Media Type
416：Requested range not satisfiable
417：Expectation Failed
422：Unprocessable Entity
423：Locked
424：Failed Dependency
500：Internal Server Error
501：Not Implemented
502：Bad Gateway
503：Service Unavailable
504：Gateway Timeout
505：HTTP Version Not Supported
507：Insufficient Storage
完整的 HTTP 1.1規范說明書來自于RFC 2616，你可以在rfc-editor在線查閱。HTTP 1.1的狀態碼被標記為新特性，因為許多瀏覽器只支持 HTTP 1.0。你應只把狀態碼發送給支持 HTTP 1.1的客戶端，支持協議版本可以通過調用request.getRequestProtocol來檢查。
本部分余下的內容會詳細地介紹 HTTP 1.1中的狀態碼。這些狀態碼被分為五大類：
100-199 用于指定客戶端應相應的某些動作。
200-299 用于表示請求成功。
300-399 用于已經移動的文件并且常被包含在定位頭信息中指定新的地址信息。
400-499 用于指出客戶端的錯誤。
500-599 用于支持服務器錯誤。
HttpServletResponse中的常量代表關聯不同標準消息的狀態碼。在servlet程序中，你會更多地用到這些常量的標識來使用狀態碼。例如：你一般會使用response.setStatus(response.SC_NO_CONTENT)而不是 response.setStatus(204)，因為后者不易理解而且容易導致錯誤。但是，你應當注意到服務器允許對消息輕微的改變，而客戶端只注意狀態碼的數字值。所以服務器可能只返回 HTTP/1.1 200 而不是 HTTP/1.1 200 OK。
100 (Continue/繼續)
如果服務器收到頭信息中帶有100-continue的請求，這是指客戶端詢問是否可以在后續的請求中發送附件。在這種情況下，服務器用100(SC_CONTINUE)允許客戶端繼續或用417 (Expectation Failed)告訴客戶端不同意接受附件。這個狀態碼是 HTTP 1.1中新加入的。
101 (Switching Protocols/轉換協議)
101 (SC_SWITCHING_PROTOCOLS)狀態碼是指服務器將按照其上的頭信息變為一個不同的協議。這是 HTTP 1.1中新加入的。
200 (OK/正常)
200 (SC_OK)的意思是一切正常。一般用于相應GET和POST請求。這個狀態碼對servlet是缺省的;如果沒有調用setStatus方法的話，就會得到200。
201 (Created/已創建)
201 (SC_CREATED)表示服務器在請求的響應中建立了新文檔;應在定位頭信息中給出它的URL。
202 (Accepted/接受)
202 (SC_ACCEPTED)告訴客戶端請求正在被執行，但還沒有處理完。
203 (Non-Authoritative Information/非官方信息)
狀態碼203 (SC_NON_AUTHORITATIVE_INFORMATION)是表示文檔被正常的返回，但是由于正在使用的是文檔副本所以某些響應頭信息可能不正確。這是 HTTP 1.1中新加入的。
204 (No Content/無內容)
在并沒有新文檔的情況下，204 (SC_NO_CONTENT)確保瀏覽器繼續顯示先前的文檔。這各狀態碼對于用戶周期性的重載某一頁非常有用，并且你可以確定先前的頁面是否已經更新。例如，某個servlet可能作如下操作：
int pageVersion =Integer.parseInt(request.getParameter("pageVersion"));
if (pageVersion >;= currentVersion) {
response.setStatus(response.SC_NO_CONTENT);
} else {
// Create regular page
}
但是，這種方法對通過刷新響應頭信息或等價的HTML標記自動重載的頁面起作用，因為它會返回一個204狀態碼停止以后的重載。但基于JavaScript腳本的自動重載在這種情況下仍然需要能夠起作用。可以閱讀本書7.2 ( HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1響應頭信息以及他們的意義)部分的詳細討論。
205 (Reset Content/重置內容)
重置內容205 (SC_RESET_CONTENT)的意思是雖然沒有新文檔但瀏覽器要重置文檔顯示。這個狀態碼用于強迫瀏覽器清除表單域。這是 HTTP 1.1中新加入的。
206 (Partial Content/局部內容)
206 (SC_PARTIAL_CONTENT)是在服務器完成了一個包含Range頭信息的局部請求時被發送的。這是 HTTP 1.1中新加入的。
300 (Multiple Choices/多重選擇)
300 (SC_MULTIPLE_CHOICES)表示被請求的文檔可以在多個地方找到，并將在返回的文檔中列出來。如果服務器有首選設置，首選項將會被列于定位響應頭信息中。
301 (Moved Permanently)
301 (SC_MOVED_PERMANENTLY)狀態是指所請求的文檔在別的地方;文檔新的URL會在定位響應頭信息中給出。瀏覽器會自動連接到新的URL。
302 (Found/找到)
與301有些類似，只是定位頭信息中所給的URL應被理解為臨時交換地址而不是永久的。注意：在 HTTP 1.0中，消息是臨時移動(Moved Temporarily)的而不是被找到，因此HttpServletResponse中的常量是SC_MOVED_TEMPORARILY不是我們以為的SC_FOUND。
注意
代表狀態碼302的常量是SC_MOVED_TEMPORARILY而不是SC_FOUND。
狀態碼302是非常有用的因為瀏覽器自動連接在定為響應頭信息中給出的新URL。這非常有用，而且為此有一個專門的方法——sendRedirect。使用response.sendRedirect(url)比調用response.setStatus(response.SC_MOVED_TEMPORARILY)和response.setHeader("Location", url)多幾個好處。首先，response.sendRedirect(url)方法明顯要簡單和容易。第二，servlet自動建立一頁保存這一連接以提供給那些不能自動轉向的瀏覽器顯示。最后，在servlet 2.2版本(J2EE中的版本)中，sendRedirect能夠處理相對路徑，自動轉換為絕對路徑。但是你只能在2.1版本中使用絕對路徑。
如果你將用戶轉向到站點的另一頁中，你要用 HttpServletResponse 中的 encodeURL 方法傳送URL。這么做可預防不斷使用基于URL重寫的會話跟蹤的情況。URL重寫是一種在你的網站跟蹤不使用 cookies 的用戶的方法。這是通過在每一個URL尾部附加路徑信息實現的，但是 servlet 會話跟蹤API會自動的注意這些細節。會話跟蹤在第九章討論，并且養成使用 encodeURL 的習慣會使以后添加會話跟蹤的功能更容易很多。
核心技巧
如果你將用戶轉向到你的站點的其他頁面，用 response.sendRedirect(response.encodeURL(url)) 的方式事先計劃好會話跟蹤(session tracking)要比只是調用 response.sendRedirect(url) 好的多。
這個狀態碼有時可以與301交換使用。例如，如果你錯誤的訪問了某路徑信息不完整)，有些服務器就會回復301狀態碼而有些則回復302。從技術上說，如果最初的請求是GET瀏覽器只是被假定自動轉向。如果想了解更多細節，請看狀態碼307的討論。
303 (See Other/參見其他信息)
這個狀態碼和 301、302 相似，只是如果最初的請求是 POST，那么新文檔(在定位頭信息中給出)藥用 GET 找回。這個狀態碼是新加入 HTTP 1.1中的。
304 (Not Modified/為修正)
當客戶端有一個緩存的文檔，通過提供一個 If-Modified-Since 頭信息可指出客戶端只希望文檔在指定日期之后有所修改時才會重載此文檔，用這種方式可以進行有條件的請求。304 (SC_NOT_MODIFIED)是指緩沖的版本已經被更新并且客戶端應刷新文檔。另外，服務器將返回請求的文檔及狀態碼 200。servlet一般情況下不會直接設置這個狀態碼。它們會實現getLastModified方法并根據修正日期讓默認服務方法處理有條件的請求。這個方法的例程已在2.8部分(An Example Using Servlet Initialization and Page Modification Dates/一個使用servlet初始化和頁面修正日期的例子)給出。
305 (Use Proxy/使用代理)
305 (SC_USE_PROXY)表示所請求的文檔要通過定位頭信息中的代理服務器獲得。這個狀態碼是新加入 HTTP 1.1中的。
307 (Temporary Redirect/臨時重定向)
瀏覽器處理307狀態的規則與302相同。307狀態被加入到 HTTP 1.1中是由于許多瀏覽器在收到302響應時即使是原始消息為POST的情況下仍然執行了錯誤的轉向。只有在收到303響應時才假定瀏覽器會在POST請求時重定向。添加這個新的狀態碼的目的很明確：在響應為303時按照GET和POST請求轉向;而在307響應時則按照GET請求轉向而不是POST請求。注意：由于某些原因在HttpServletResponse中還沒有與這個狀態對應的常量。該狀態碼是新加入HTTP 1.1中的。
注意
在 HttpServletResponse 中沒有 SC_TEMPORARY_REDIRECT 常量，所以你只能顯示的使用307狀態碼。
400 (Bad Request/錯誤請求)
400 (SC_BAD_REQUEST)指出客戶端請求中的語法錯誤。
401 (Unauthorized/未授權)
401 (SC_UNAUTHORIZED)表示客戶端在授權頭信息中沒有有效的身份信息時訪問受到密碼保護的頁面。這個響應必須包含一個WWW-Authenticate的授權信息頭。例如，在本書4.5部分中的“Restricting Access to Web Pages./限制訪問Web頁。”
403 (Forbidden/禁止)
403 (SC_FORBIDDEN)的意思是除非擁有授權否則服務器拒絕提供所請求的資源。這個狀態經常會由于服務器上的損壞文件或目錄許可而引起。
404 (Not Found/未找到)
404 (SC_NOT_FOUND)狀態每個網絡程序員可能都遇到過，他告訴客戶端所給的地址無法找到任何資源。它是表示“沒有所訪問頁面”的標準方式。這個狀態碼是常用的響應并且在HttpServletResponse類中有專門的方法實現它：sendError("message")。相對于setStatus使用sendError得好處是：服務器會自動生成一個錯誤頁來顯示錯誤信息。但是，Internet Explorer 5瀏覽器卻默認忽略你發揮的錯誤頁面并顯示其自定義的錯誤提示頁面，雖然微軟這么做違反了 HTTP 規范。要關閉此功能，在工具菜單里，選擇Internet選項，進入高級標簽頁，并確認“顯示友好的 HTTP 錯誤信息”選項(在我的瀏覽器中是倒數第8各選項)沒有被選。但是很少有用戶知道此選項，因此這個特性被IE5隱藏了起來使用戶無法看到你所返回給用戶的信息。而其他主流瀏覽器及IE4都完全的顯示服務器生成的錯誤提示頁面。可以參考圖6-3及6-4中的例子。
核心警告
默認情況下，IE5忽略服務端生成的錯誤提示頁面。
405 (Method Not Allowed/方法未允許)
405 (SC_METHOD_NOT_ALLOWED)指出請求方法(GET, POST, HEAD, PUT, DELETE, 等)對某些特定的資源不允許使用。該狀態碼是新加入 HTTP 1.1中的。
406 (Not Acceptable/無法訪問)
406 (SC_NOT_ACCEPTABLE)表示請求資源的MIME類型與客戶端中Accept頭信息中指定的類型不一致。見本書7.2部分中的表7.1(HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1響應頭信息以及他們的意義)中對MIME類型的介紹。406是新加入 HTTP 1.1中的。
407 (Proxy Authentication Required/代理服務器認證要求)
407 (SC_PROXY_AUTHENTICATION_REQUIRED)與401狀態有些相似，只是這個狀態用于代理服務器。該狀態指出客戶端必須通過代理服務器的認證。代理服務器返回一個Proxy-Authenticate響應頭信息給客戶端，這會引起客戶端使用帶有Proxy-Authorization請求的頭信息重新連接。該狀態碼是新加入 HTTP 1.1中的。
408 (Request Timeout/請求超時)
408 (SC_REQUEST_TIMEOUT)是指服務端等待客戶端發送請求的時間過長。該狀態碼是新加入 HTTP 1.1中的。
409 (Conflict/沖突)
該狀態通常與PUT請求一同使用，409 (SC_CONFLICT)狀態常被用于試圖上傳版本不正確的文件時。該狀態碼是新加入 HTTP 1.1中的。
410 (Gone/已經不存在)
410 (SC_GONE)告訴客戶端所請求的文檔已經不存在并且沒有更新的地址。410狀態不同于404，410是在指導文檔已被移走的情況下使用，而404則用于未知原因的無法訪問。該狀態碼是新加入 HTTP 1.1中的。
411 (Length Required/需要數據長度)
411 (SC_LENGTH_REQUIRED)表示服務器不能處理請求(假設為帶有附件的POST請求)，除非客戶端發送Content-Length頭信息指出發送給服務器的數據的大小。該狀態是新加入 HTTP 1.1的。
412 (Precondition Failed/先決條件錯誤)
412 (SC_PRECONDITION_FAILED)狀態指出請求頭信息中的某些先決條件是錯誤的。該狀態是新加入 HTTP 1.1的。
413 (Request Entity Too Large/請求實體過大)
413 (SC_REQUEST_ENTITY_TOO_LARGE)告訴客戶端現在所請求的文檔比服務器現在想要處理的要大。如果服務器認為能夠過一段時間處理，則會包含一個Retry-After的響應頭信息。該狀態是新加入 HTTP 1.1的。
414 (Request URI Too Long/請求URI過長)
414 (SC_REQUEST_URI_TOO_LONG)狀態用于在URI過長的情況時。這里所指的“URI”是指URL中主機、域名及端口號之后的內容。該狀態是新加入 HTTP 1.1的。
415 (Unsupported Media Type/不支持的媒體格式)
415 (SC_UNSUPPORTED_MEDIA_TYPE)意味著請求所帶的附件的格式類型服務器不知道如何處理。該狀態是新加入 HTTP 1.1的。
416 (Requested Range Not Satisfiable/請求范圍無法滿足)
416表示客戶端包含了一個服務器無法滿足的Range頭信息的請求。該狀態是新加入 HTTP 1.1的。奇怪的是，在servlet 2.1版本API的HttpServletResponse中并沒有相應的常量代表該狀態。
注意
在servlet 2.1的規范中，類HttpServletResponse并沒有SC_REQUESTED_RANGE_NOT_SATISFIABLE 這樣的常量，所以你只能直接使用416。在servlet 2.2版本之后都包含了此常量。
417 (Expectation Failed/期望失敗)
如果服務器得到一個帶有100-continue值的Expect請求頭信息，這是指客戶端正在詢問是否可以在后面的請求中發送附件。在這種情況下，服務器也會用該狀態(417)告訴瀏覽器服務器不接收該附件或用100 (SC_CONTINUE)狀態告訴客戶端可以繼續發送附件。該狀態是新加入 HTTP 1.1的。
500 (Internal Server Error/內部服務器錯誤)
500 (SC_INTERNAL_SERVER_ERROR) 是常用的“服務器錯誤”狀態。該狀態經常由CGI程序引起也可能(但愿不會如此!)由無法正常運行的或返回頭信息格式不正確的servlet引起。
501 (Not Implemented/未實現)
501 (SC_NOT_IMPLEMENTED)狀態告訴客戶端服務器不支持請求中要求的功能。例如，客戶端執行了如PUT這樣的服務器并不支持的命令。
502 (Bad Gateway/錯誤的網關)
502 (SC_BAD_GATEWAY)被用于充當代理或網關的服務器;該狀態指出接收服務器接收到遠端服務器的錯誤響應。
503 (Service Unavailable/服務無法獲得)
狀態碼503 (SC_SERVICE_UNAVAILABLE)表示服務器由于在維護或已經超載而無法響應。例如，如果某些線程或數據庫連接池已經沒有空閑則servlet會返回這個頭信息。服務器可提供一個Retry-After頭信息告訴客戶端什么時候可以在試一次。
504 (Gateway Timeout/網關超時)
該狀態也用于充當代理或網關的服務器;它指出接收服務器沒有從遠端服務器得到及時的響應。該狀態是新加入 HTTP 1.1的。
505 (HTTP Version Not Supported/不支持的 HTTP 版本)
505 (SC_HTTP_VERSION_NOT_SUPPORTED)狀態碼是說服務器并不支持在請求中所標明 HTTP 版本。該狀態是新加入 HTTP 1.1的。
本文來和大家討論數值框架提取與數據分析運用是怎么相輔相成來推動游戲化項目，幫助設計團隊提升設計專業性和展示產品思維的。分為 2 大塊：如何在設計中平衡效益、如何衡量設計價值。下面會從這 2 個游戲項目：獨立小游戲《嘛哩嘛哩汪》、會員游戲《天天加速》來剖析。
要了解這件事，首先需要簡單介紹下什么是數值，在游戲公司里有個職位叫數值策劃，他是解決游戲里數值平衡和經濟平衡的。在這里，我們不用專業術語，我們的也沒游戲公司的那么難。我總結一下電商里容易理解運用的，就是這么一條公式：
下面講的時候大家可以用這個思路（文中都叫數值框架）來理解并試試能不能運用。
1. 快速理解游戲的玩法（數值框架的運用）
舉個例子，我們之前做的獨立小游戲《嘛哩嘛哩汪》，用戶可以領到一只同樣的小土狗，通過不同的社交玩法：比如戰斗，發送偷偷告白的小紙條等等，最終把自己的狗狗變成一只的萌寵換裝養成游戲。
它的主要功能模塊有采金（收金幣）、對戰、魔法屋（換裝）。
有貨幣系統（金幣、鉆石、氪金）、等級系統（階級經驗值）、任務系統、道具系統（商店、背包）、社交系統（打 call、好友、消息）等。
這樣乍一看，是不是覺得有點復雜？其實只要抓住關鍵流向節點，比如主要貨幣金幣、成長體系的經驗值，這種流入流出最頻繁的地方就是關鍵流向節點，再把游戲主要功能系統串起來，主要功能就是關鍵流向節點流向最多的地方。這樣串聯起來就非常簡潔明了，一眼就知道這個游戲怎么玩（如下圖），通過采金、pk（主要功能）得到金幣（關鍵流向節點），可以用來購買新裝備去換裝（主要功能），但需要靠做任務（社交、互動）去提升經驗值（關鍵流向節點），才能不斷解鎖新裝備，養成一只的狗仔。
當提取了最簡單的框架后，再去細分支線數值，會清晰很多，最后細化的數值從系統的組成和期望去架構數值表和體系：如何實現、從哪里獲取數據、如何方便又泛用化表格、精簡配置、去除冗余數據等；大白話就是解決比如：升階太慢，要調整；金幣太快，裝備很快買完了，玩不下去了，要調整；用戶可操作太少了，要調整；裝備售價多少金幣，多少鉆石適合？道具使用時長多久？任務成就獎勵怎么設定，要送用戶什么？等等這些問題…….
而這些在項目后續可能會困擾的問題其實在初期設計的時候就可以先規劃，照顧到。
2. 數值框架在其他項目中的運用
這樣的思路也很適合分析運營活動，快速抓住別人玩法中最吸引用戶的點，包括自己設計的時候也可以在前期就自我評估項目成本。大家可以拿淘金幣和疊貓貓用這個思路試試看，這邊是比較早期的分析，淘寶的迭代太快了。
先看看 19 年 6 月前的淘金幣，已經有在大促的時候開墾土地，我們不說視覺，先來分析下它的布局思路。
用公式代入看看，業務的訴求植入在領水滴任務中，關鍵流向節點是水滴和金幣，節點流向最多是種地（圖中種子，這里講功能），投金幣。非常清晰的框架。而且棒的是大促期間只需要復用同一套框架變成種寶貝，這對多方來說效益是高的。我們可以看到現在很多都在做這個模式，也就是把框架工具化了，換皮不換骨。19 年雙十一的全民開喵鋪幾乎把它套用到所有的阿里旗下產品，（下方圖左）底部的任務入口（領喵幣）和輔線內容（領組隊紅包）均根據產品來配置，設計的時候規劃得很清晰。（下方圖右）當養成思路之后在活動剛出體驗的時候就可以分析它的設計框架意圖，無需過度依賴網上分析也能知道它好在哪，自己設計的時候也會有好的借鑒。
那在做游戲化產品的時候，里面就有很多東西需要考量植入業務訴求后的平衡了，但游戲玩法肯定是相對簡單些的。
3. 理解業務訴求和游戲玩法關系
拿游戲化產品-會員游戲《天天加速》舉個例子。
天天加速是一款宇宙救援世界觀的游戲，以加速為核心玩法。把產品的各項目標植入到加速的道具中，用戶如需獲得道具需要完成產品目標，獲得獎勵，從而實現雙贏。
拿主線來說，如下圖展示我們植入業務訴求的時候，按那條公式思路來思考，業務層級越高（越難做，比如購買），游戲中設定層級越低（不強推），但游戲和現實中反饋都越多/強，去激勵用戶做重任務。這樣簡單羅列，就可以讓雙方同學都容易理解，并提前規劃后臺配置和配置的數值建議，給運營同學留出后續自運營配置的空間。
副線射擊游戲也是，按照這種思路，把成本均衡到，幾乎相同的玩法，不同的配置成本差別是很大的，下表是對玩法影響最小的，這些產出比都會影響業務方是否為你的功能玩法買單。
當建立了數值框架后，對后續上線的數據分析和推導下一步的迭代有很好的指導作用，因為你清楚知道數據的用戶操作行為、可以知道用戶是怎么流失的，再綜合客戶的投訴建議，用研同學的調研，可以較全面的整合處理。
這里還是拿游戲化產品-會員游戲《天天加速》舉個例子。主要從以下3個方面，通過《會員游戲-天天加速》這個項目不同版本迭代來講。（具體數據均不能透露）。
前面已經介紹過游戲是怎么玩的，這里直接講 1.0 數據結論：在上線 7 天的時候就超額完成 kpi 了，其中 pv 是 kpi 預期 2.5 倍，任務完成率是 kpi 3 倍，近 90% 的用戶都來打卡簽到。超出我們預期挺多的。
但是數據好=我們的價值么？這也是我們從開始做就很想驗證的，我們來看看方式。
建立數據體系、量化設計指標
在前期就和業務方達成共識，把他們的 kpi 指標任務活躍和用戶上行，拆解成了游戲中的具體指標。再根據指標，對應到游戲中用戶完成操作的行為流程，便可對應 kpi 的數據埋點。
最后，等埋點數據出來了，再用工具具體分析。流程可以看下圖~
每周根據數據，發現規律、解決問題
具體的分析，我給大家舉個例，這里是各個 kpi 數據的長線跟蹤，一個點的數據是說明不了問題的，重點在怎么去維持和提高。第一張圖可以看到，項目上線后，uv、pv 穩定上升，但在第 6 周開始回落，我們需要敏感地察覺，并且進行分析，作出反應。當我們快速調整上線 2.0 的時候，在第 11 周數據又開始回漲。
所以需要我們對數據敏感，有解讀能力，和對項目的深刻理解。不然數據就只是數據，結論可能是因人而異的，當然有現成后臺直接看數據結論最好，但沒有的時候也得能處理，野外求生技能還是得有的。
構建合適的數據分析框架
我把如何分析數據的全流程復制下來，每周都會把收集的數據進行梳理，按照流程把各 kpi 的數據梳理一遍，發現問題就去溝通解決推動。這樣也保證項目數據能持續穩定地增長。
其實做到這一步，我們已經是項目密不可分的一部分了，誰又能否定我們的價值呢。
那數據分析除了能驗證設計的價值，還能做什么？
我們再來詳細說說，是如何通過分析數據指標提升游戲體驗的。我們按版本迭代來看看。
首先，我們可以把數據分成兩個層面去看：用戶操作數據和產品目標達成數據，業務方更多關注的肯定是產品目標的達成數據，那我們就多分析用戶操作數據，2 邊匯集，能更好地推動項目。
我們舉些例子～
剛說了數據需要長線跟蹤，需要發現變化規律，那如圖，到了第 7 周，發現數據開始回落，但依舊超過了 kpi。我們去梳理原因，最大的原因是游戲 1.0 只上線了最簡單的核心玩法，用戶回訪多，但沒有太多可操作的內容，久而久之，回訪自然會下降，所以我馬上拉著產品討論穩住 pv 的方案，同時還滿足產品新訴求，植入發放優惠券，并且需要快速上線。這就是 2.0 版穩住 pv 的方案，事件系統，就是畫面一中，右下角的小信封。用戶每次回訪，都有事件系統可操作，系統里會根據問答隨機給到優惠券或者游戲道具。保證用戶每次回訪都有事可做，有利可圖。
的確上線后數據開始回漲，也是首次破 8，數據是暫時穩定了，但是我們也明白這個版本下用戶沒有長線留存的理由。我們必須給用戶帶來積累感和晉升感，才能讓用戶對自己的付出有感知。于是我馬上策劃和實現了長線粘性的新增玩法，讓用戶除開機械的事件操作，還有主動的互動操作。
在圖一主頁面的左下角，有了一個尋寶行動的入口，是個射擊游戲，用戶可以通過擊落隕石獲得高分開寶箱，得到更多用于飛船升級的核能源，積累越多可以換取越高階的飛船，對應更豐厚的獎品，因此長線的留存在游戲中。
前兩點，我都在不斷地去幫助產品達成目標。那我們是不是可以再去拓寬設計的邊界，提升產品的目標呢？
當我們上線 1 個多月時，得到了向好的業務數據，但是我們知道，這是基于用戶的基數大，11% 的轉化已經可以帶來這么大的訂單額，如果我們能撬動另外 90% 的用戶呢？因此我去分析了游戲用戶，發現對促銷敏感度高的用戶，不管是在全量用戶還是核心用戶中，都超過 70%，是相當明確的用戶類型。
于是有了這三者的考慮：
優化轉化目標、尋找合作可能性更高的業務方向、結合我們核心用戶的促銷敏感度高的特點，也去挖掘了一些方向。考慮產品運營成本實現的方式去出了 2 個方案，
第一個方案：轉化入口的優化。
用戶要得到蟲洞道具，需要去購買商品。業務訴求有發券的 kpi，那在購買同時配合得到類目優惠券，這樣就能大大的提升用戶的購買訴求。
第二個方案：植入事件系統
系統事件，之前是只有送優惠券的功能，現在加入跨品類低價商品的推送+對應優惠券的功能，再次打游戲用戶對價格敏感的痛點，目標是提升兩者的轉化。
當然業務有更多深入的考量，我們既然有一些想法能共同推進項目，那就多多溝通交流。
那到這里，文章終于要結束了，通篇其實是在通過實際的項目告訴大家數據框架（開篇那條公式思路）和數據分析能怎么貫穿整個項目，怎么去平衡各方成本，相輔相成地去推動項目、驗證設計價值的。
最后一點小體會，在做這 2 類項目中，我最深刻的感受是獨立小游戲里游戲內容是絕對主角，難點在沒接觸過的游戲引擎技術的攻克和數值的實現打通（游戲資質和法務問題也很麻煩），而游戲化產品里業務訴求和游戲化的包裝是雙主角，難的是兩者的緊密結合和推動落地。第二種在策劃的時候很容易把玩游戲當成主題，但電商公司做游戲化最主要是想讓用戶多回訪，在平臺購物，帶來商業效益。因此，前期都比較閹割，需要看到它為業務帶來實際效益，才有后續的為「趣味性」買單的資源研發投入，這個「游戲」的取舍其實挺難過的。
文章來源：優設 作者：JellyDesign
網師分層對平臺的重要性不言而喻，諸如阿里這類的電商平臺都有完善的商家分級體系，明確了不同等級的權益和運營策略。
2019 年底 CCtalk 平臺的網師數量達到了一定規模，平臺的基礎能力建設也相對完善，因此網師分層的事宜被提上日程。此前我們評估網師的方式是按照流水，將網師分為普通網師、中部網師和大 V 網師 3 類，不同網師對產品功能需求及運營要求差別很大。這種粗略的劃分方式可以幫助簡單評估網師，但并沒有產品化，而且只有單一的 GMV 維度，不夠全面客觀。有些客單價較低的網師也有大量的購課學生，他們對平臺的價值也高。因而我們需要推出一套綜合網師流水、招生數量、內容質量等多個維度的方法來進行分層運營。
面對以上問題，相應的解決方案是：
既然是涉及全平臺網師的重大升級調整，當然要從全局的角度來進行價值分析。我在這個項目中探索了用于多角色價值分析的「三維價值分析法」，從整個關系鏈的角度來解析網師分層對網師和平臺的價值。
Step1.列出相關利益者
分別包括：CCtalk平臺、網師、學生。
△ 列出相關利益者
Step2.設定中心點并建立關系
分析連接這3種角色的關鍵點是什么。我們CCtalk作為一個在線教育平臺，最核心的因素是內容，因而將中心點設定為「內容」。（注意，如果此時是做某個具體功能相關的項目，那么中心點可以是這個具體的功能，例如「作業」或「直播」）設定中心點后，建立不同角色和中心點之間的雙向關系。
△ 設定中心點并建立關系
Step3.進行全局價值分析
在上一步的關系網的基礎上，用圓弧連接相鄰角色的價值走向關系，從全局的角度進行不同角色間的價值分析。
△ 進行全局價值分析
從上面的三維圖中可以看出網師分層對于平臺和網師的價值。
對網師來說，有助于：了解成長路徑，獲得更多產品運營支持，獲取更多功能權益。
對平臺來說，可以：篩選網師，激勵網師自驅動，增加收入。另外，還有一些間接的價值，包括通過督促網師生產高質量的內容來提升平臺的價值，通過督促網師積極招生來擴大用戶規模。
△ 網師分層對于平臺和網師的價值
剛接到需求時，我內心的 OS 是：大項目！概念大，范圍廣，都有點不知從哪里入手。
冷靜下來分析，網師分層本質是一套針對商戶端的激勵體系。從下往上拆解：由底層商戶活躍度來計算經驗值，根據經驗值劃分商戶等級，并賦予不同等級不同的權益，權益包括教學核心功能：直播時長，素材存儲空間，課程人數等。再向上衍生到不同權益對應的使用場景，以及權益的擴展方式。
△ 分層拆解
從設計層面，分為信息展示和場景觸達兩部分。這么一看，其實又挺簡單。
由于項目涉及的底層邏輯多，時間周期跨度大，因此拆分成 3個小版本來實現：商戶權益改造，經驗值等級底層 & 商戶等級外顯。前期的功能實現后，先預埋在版本中。等到經驗等級上線時統一發布。其中經驗值等級底層項目是純技術，不涉及設計。
所以下面將從功能權益分層和等級經驗值外顯兩部分來講解具體的設計過程。
功能權益分層是權益的使用層面，包括多場景觸達和引導購買增量包。設計時分為場景梳理→設計要點→細化直播場景→具體設計這 4 步來實施。
Step A.場景梳理
拆解權益的生命周期，可分為三個階段：充足可用，即將不足，已用盡。而功能的使用場景——直播，也分為三個階段：直播前，直播中，直播后。
Step B.設計要點
將權益生命周期和直播場景結合進行交叉分析，列出設計要點和具體的設計拆解。
△ 不同階段的設計要點及拆解
Step C.細化直播場景
發起直播的入口很多，除了「立即直播」的主場景之外，還有由預告進入直播的 3 種場景，如果在每個入口都做功能禁用判斷的話，不僅邏輯會很復雜，開發實現起來成本也比較大。
于是將直播前的流程細化，發現「直播檢測」是進入直播間的必經環節，因此將功能禁用的判斷節點縮減為 2 處：「立即直播」&「直播檢測」。
△ 細化直播場景
Step D.具體設計
有了前期的分析后，具體設計環節就相對容易了。下面以點擊「立即直播」時的功能余量判斷為例。
點擊「立即直播」按鈕，在按鈕原有的邏輯上加上新的判斷邏輯，此處要注意寫清楚他們之間的優先級關系。如果在不了解背景的情況下，很可能就直接寫點擊按鈕進行可用直播時長的判斷，那需求宣講的時候開發就會問你，和原來按鈕上的邏輯是什么關系呢，此時就會一陣緊張。
△ 立即直播時判斷剩余可用直播時長
等級經驗值屬于展示層。對網師用戶來說，最重要的是了解自己當前處于哪個等級以及相應的權益有哪些。對平臺來說，除了明確每個等級及相應的權益，重要的是要引導網師升級，以激發他們的自驅力。
由此推導出相應的設計方法：錨定目標、降低門檻和利益點吸引。
△ 設計方法
在設計方法的指導下進行落地，分為網師后臺首頁的展示，以及等級詳情頁的設計兩部分。
網師后臺首頁-個人信息模塊的展示
由于等級和權益掛鉤，涉及網師切身利益，因而在網師后臺首頁的個人信息模塊，增加當前的經驗值和相應等級的展示。同時，通過利益點吸引等方式，引導網師向下一個等級努力。
△ 個人信息模塊展示
等級詳情頁的設計
點擊等級進入詳情頁，除了 Lv0 是將所有權益無差別展示，其他等級都是優先展示新增部分，包括新獲得的普通權益和附贈的高級功能。另外，用「箭頭」和「NEW」的圖標幫助用戶區分是老權益的內容升級，還是新增的權益。
1. 前期缺乏深入調研
由于涉及網師的切身利益，因而此功能受到了網師們前所未有的關注。上線前一周，運營以郵件、通知等形式向網師預熱，3 月 5 日會上線這么一個功能。于是還沒上線就有網師來咨詢在哪里可以查看。剛上線就收到了大量的用戶反饋，網師反饋群里的消息簡直是秒速級地在刷屏。
其中，網師對每月直播時長限制的反響最為強烈，部分網師表示平臺應該鼓勵多直播，不能接受對直播時長的限制。因為直接關系到上課這個核心功能，時長不夠課都上不了，網師們的言辭非常激烈。所以我們又重新評估了平臺的直播成本，經過深入討論，全面放開了每月的直播可用時長限制。
帶來的反思是，如果前期有通過問卷、訪談等方式進行深入的用戶調研，了解他們對核心權益的態度，那么在進行權益設置時就能有更全面的考量。
2. 中高等級跨度太大，缺乏激勵效果
游戲任務的上手難度曲線一般是先平緩，再慢慢陡峭，越往上難度越大。我們的等級體系其實也是這個邏輯。初級到中級還較為容易，但再往上要非常難，要經過長時間的積累，一看就無望，難有激勵效果。
因而我們之后的優化方向是在相鄰等級中間設定一些小目標，達到可以提前贈送下一等級的新權益，以此來提高激勵效果。
文章來源：優設 作者：魚游設計
HTTP狀態碼
HTTP狀態碼（英語：HTTP Status Code）是用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼。它由 RFC 2616 規范定義的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 與 RFC 4918 等規范擴展。所有狀態碼的第一個數字代表了響應的五種狀態之一。所示的消息短語是典型的，但是可以提供任何可讀取的替代方案。 除非另有說明，狀態碼是HTTP / 1.1標準（RFC 7231）的一部分。
HTTP狀態碼的官方注冊表由互聯網號碼分配局（Internet Assigned Numbers Authority）維護。
微軟互聯網信息服務 （Microsoft Internet Information Services）有時會使用額外的十進制子代碼來獲取更多具體信息，但是這些子代碼僅出現在響應有效內容和文檔中，而不是代替實際的HTTP狀態代碼。
HTTP狀態碼分類
分類 分類描述
1 信息，服務器收到請求，需要請求者繼續執行操作
2 成功，操作被成功接收并處理
3 重定向，需要進一步的操作以完成請求
4 客戶端錯誤，請求包含語法錯誤或無法完成請求
5** 服務器錯誤，服務器在處理請求的過程中發生了錯誤
1xx 信息（消息）
這一類型的狀態碼，代表請求已被接受，需要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，并以空行結束。由于 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，所以除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。
100 Continue
繼續。客戶端應當繼續發送請求。
101 Switching Protocols
切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議。
2xx 成功
這一類型的狀態碼，代表請求已成功被服務器接收、理解、并接受。
200 OK
請求成功。請求所希望的響應頭或數據體將隨此響應返回。出現此狀態碼是表示正常狀態。
201 Created
已創建。成功請求并創建了新的資源。
202 Accepted
已接受。已經接受請求，但未處理完成。
203 Non-Authoritative Information
非授權信息。請求成功，但返回的meta信息不在原始的服務器，而是一個副本。
204 No Content
無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔。
205 Reset Content
重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域。
206 Partial Content
部分內容。服務器成功處理了部分GET請求，類似于 FlashGet 或者迅雷這類的 HTTP下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同時下載。
3xx 重定向
這類狀態碼代表需要客戶端采取進一步的操作才能完成請求。通常，這些狀態碼用來重定向，后續的請求地址（重定向目標）在本次響應的 Location 域中指明。
當且僅當后續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器才可以在沒有用戶介入的情況下自動提交所需要的后續請求。客戶端應當自動監測無限循環重定向（例如：A->A，或者A->B->C->A），因為這會導致服務器和客戶端大量不必要的資源消耗。按照 HTTP/1.0 版規范的建議，瀏覽器不應自動訪問超過5次的重定向。
300 Multiple Choices
多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用于用戶終端（例如：瀏覽器）選擇。
301 Moved Permanently
永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替。
302 Move Temporarily（Found）
臨時移動。與301類似，但資源只是臨時被移動，客戶端應繼續使用原有URI。
303 See Other
查看其它地址。與301類似，使用GET和POST請求查看。
304 Not Modified
未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源。
305 Use Proxy
使用代理。所請求的資源必須通過代理訪問。
306 Switch Proxy
在版的規范中，306狀態碼已經不再被使用。它算是已經被廢棄的HTTP狀態碼。
307 Temporary Redirect
臨時重定向。與302類似，使用GET請求重定向。
4xx 客戶端錯誤（請求錯誤）
這類的狀態碼代表了客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個 HEAD 請求，否則服務器就應該返回一個解釋當前錯誤狀況的實體，以及這是臨時的還是永久性的狀況。這些狀態碼適用于任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。
如果錯誤發生時客戶端正在傳送數據，那么使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的連接之前，客戶端已經收到了包含錯誤信息的數據包。如果客戶端在收到錯誤信息后繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端所有還未識別的輸入緩沖，以免這些數據被服務器上的應用程序讀取并干擾后者。
400 Bad Request
客戶端請求的語法錯誤，服務器無法理解。
401 Unauthorized
當前請求需要用戶驗證。
402 Payment Required
該狀態碼是為了將來可能的需求而預留的。（保留，將來使用。）
403 Forbidden
服務器理解請求客戶端的請求，但是拒絕執行此請求。
404 Not Found
請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因為某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用于當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。出現這個錯誤的最有可能的原因是服務器端沒有這個頁面。
405 Method Not Allowed
客戶端請求中的方法被禁止，也就是請求行中指定的請求方法不能被用于請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源能夠接受的請求方法的列表。
406 Not Acceptable
服務器無法根據客戶端請求的內容特性完成請求，也就是請求的資源的內容特性無法滿足請求頭中的條件，因而無法生成響應實體。
407 Proxy Authentication Required
與401響應類似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端可以返回一個 Proxy-Authorization 信息頭用以驗證。參見RFC 2617。
408 Request Timeout
請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端可以隨時再次提交這一請求而無需進行任何更改。
409 Conflict
由于和被請求的資源的當前狀態之間存在沖突，請求無法完成。這個代碼只允許用在這樣的情況下才能被使用：用戶被認為能夠解決沖突，并且會重新提交新的請求。該響應應當包含足夠的信息以便用戶發現沖突的源頭。
沖突通常發生于對 PUT 請求的處理中。例如，在采用版本檢查的環境下，某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與之前的某個（第三方）請求向沖突，那么此時服務器就應該返回一個409錯誤，告知用戶請求無法完成。此時，響應實體中很可能會包含兩個沖突版本之間的差異比較，以便用戶重新提交歸并以后的新版本。
410 Gone
客戶端請求的資源已經不存在。410不同于404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置。
411 Length Required
服務器拒絕在沒有定義 Content-Length 頭的情況下接受請求。在添加了表明請求消息體長度的有效 Content-Length 頭之后，客戶端可以再次提交該請求。
412 Precondition Failed
客戶端請求信息的先決條件錯誤，也就是服務器在驗證在請求的頭字段中給出先決條件時，沒能滿足其中的一個或多個。這個狀態碼允許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其希望的內容以外的資源上。
413 Request Entity Too Large
服務器拒絕處理當前請求，因為該請求提交的實體數據大小超過了服務器愿意或者能夠處理的范圍。此種情況下，服務器可以關閉連接以免客戶端繼續發送此請求。
如果這個狀況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端可以在多少時間以后重新嘗試。
414 Request-URI Too Long
請求的URI過長（URI通常為網址），服務器無法處理。
415 Unsupported Media Type
服務器無法處理請求附帶的媒體格式，也就是對于當前請求的方法和所請求的資源，請求中提交的實體并不是服務器中所支持的格式，因此請求被拒絕。
416 Requested Range Not Satisfiable
客戶端請求的范圍無效，也就是如果請求中包含了 Range 請求頭，并且 Range 中指定的任何數據范圍都與當前資源的可用范圍不重合，同時請求中又沒有定義 If-Range 請求頭，那么服務器就應當返回416狀態碼。
417 Expectation Failed
服務器無法滿足Expect的請求頭信息，也就是在請求頭 Expect 中指定的預期內容無法被服務器滿足，或者這個服務器是一個代理服務器，它有明顯的證據證明在當前路由的下一個節點上，Expect 的內容無法被滿足。
5xx 服務器錯誤
這類狀態碼代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處理。除非這是一個HEAD 請求，否則服務器應當包含一個解釋當前錯誤狀態以及這個狀況是臨時的還是永久的解釋信息實體。瀏覽器應當向用戶展示任何在當前響應中被包含的實體。這些狀態碼適用于任何響應方法。
500 Internal Server Error
服務器內部錯誤，無法完成請求。服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器端的源代碼出現錯誤時出現。
501 Not Implemented
服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，并且無法支持其對任何資源的請求。
502 Bad Gateway
作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應。
503 Service Unavailable
由于臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，并且將在一段時間以后恢復。如果能夠預計延遲時間，那么響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 信息，那么客戶端應當以處理500響應的方式處理它。
注意：503狀態碼的存在并不意味著服務器在過載的時候必須使用它。某些服務器只不過是希望拒絕客戶端的連接。
504 Gateway Timeout
作為網關或者代理工作的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。
505 HTTP Version Not Supported
服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示著服務器不能或不愿使用與客戶端相同的版本。響應中應當包含一個描述了為何版本不被支持以及服務器支持哪些協議的實體。
感謝觀看！
參考資料：
https://www.runoob.com/http/http-status-codes.html
若想了解更多請參考：
HTTP狀態碼百度百科
https://blog.csdn.net/GarfieldEr007/article/details/77984065
HTML基礎知識
第一篇，HTML的結構
HTML中兩個概念
(1).HTML標簽：<元素名稱></元素名稱>
完整語法：<元素名稱>要控制的元素</元素名稱>
HTML標簽分為兩種： 成對：只對標簽內的元素起作用
單獨：在相應位置插入換行
標簽屬性設置在元素的首標簽：語法：<元素 屬性1=“值1” …>元素資料</元素>,""可省略
HTML元素： 一組標簽將一段文字包含在中間，這一組標簽與文字就是元素
結構
在所有的HTML文件中最外層由標簽建立，并包含兩個子標簽：元素為文件標題 ：元素為文件主題
：說明文件標題和文件的一些公共屬性 ：文件主體
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>HTML結構</title>
</head>
<body>
Hellow Word！
</body>
</html>
聊到香港設計，當聊完靳埭強大家也基本能猜到接下來會聊誰，自然就是香港第三代設計師的代表人物陳幼堅，他的成就跟靳埭強可謂旗鼓相當，所以繼靳埭強被封香港設計教父后，他也被封為香港設計教主，按文無第一的原則，也無謂去為他們成就分一個高低，就好比香港歌壇的譚詠麟張國榮，你喜歡誰都是對的。
陳幼堅在國際上的名聲是超越了諸多香港著名設計師的，他職業生涯當中獲得了600多個獎項，其中更是以國際獎項為主，包括美國、英國及日本的設計大獎，特別在日本他的名聲就跟成龍在演藝圈一樣的響當當，也有很多人評價他的作品受日本風格影響很大，后來他自己也回應過非常喜歡日本設計，在1991年及2002年他曾或日本東京邀約，舉辦了"東方匯合西方"、"東情西韻"個人展覽。
跟前面兩位大師一樣，石漢瑞是“跨文化設計”，靳埭強是“中國傳統結合西方現代”，陳幼堅則是“東情西韻”，都離不開東西方文化的碰撞路徑，個人認為這是可以給內地設計師一些重大啟發的。
相對陳幼堅的名聲地位，令人感到非常不解的是原來他并非設計科班出生，也沒有嚴謹的設計專業學習經歷。
陳幼堅1950年出生在香港，父親是一名普通的水果攤主，母親是澳門人，也是普通家庭主婦，都沒有受過高等教育，陳幼堅小時候是一名品學兼優的學生，興趣也很廣泛，中學時候入讀了西味濃厚的嘉道理爵士中學，但這時候陳幼堅早戀了，交了女朋友的他有點無心向學，不久就輟學去機構做了十個月的代課教師，然后又無法忍受循規蹈矩的教學工作，幸虧在嘉道理爵士中學培養出不錯的英文功底，陳幼堅去了一所外資廣告公司做學徒，為了盡快適應工作，期間他參加了一個為期個月的香港大一藝術設計學院夜間設計課程的學習，這也是他人生中唯一受過的設計教育經歷。
20歲的陳幼堅從助理學徒開始，在廣告界努力奮斗了十年，基本都在外國老板的公司里，這也是后來陳幼堅回憶讓他得以從西方角度看東方的重要原因，在1980年時，30歲的陳幼堅比較厭倦廣告公司的比稿情況跟復雜人事（當時的香港免費比稿成風，甚至引發了設計師集體抗議的運動），跟妻子一起出來獨立創業，成立達爾訊廣告公司，6年后更名為“陳幼堅廣告設計公司”。
已經有40多載設計經歷的陳幼堅代表作數不勝數，這里我們選擇一部分來談談，比方為娛樂圈大咖們的設計、可口可樂的中文標識設計，羅西尼手表的海報設計，香港城市形象設計。
很多人都不知道，陳幼堅在80年代為眾多當紅巨星設計過演唱會海報、唱片封面，其中有羅文、林子祥、梅艷芳、張學友、周華健跟張國榮等等，其中張國榮是跟陳幼堅合作最久的，整個八十年代，從初出道到89年告別演唱會《FINAL ENCOUNTER》陳幼堅都擔任美術指導，一手包辦他的個人大碟。但陳幼堅并沒有將這些創作放到公司的案例當中，他認為這件事他的興趣大于商業，所以很多人都不知道，在張國榮61歲冥壽時，陳幼堅參加一個訪談才相對詳細的回顧了他跟哥哥的這段交情。
到了2000年時候，50歲的陳幼堅為羅西尼手表設計的海報，讓很多人都印象深刻，也是我對其印象最深刻的設計之一，海報上的刻度不是以往的羅馬數字或阿拉伯數字，而是換成了一些不完整的文字，但是時針的走動卻能為每一時刻添上一筆，使其拼成一個完整的中文小寫數字，簡潔明了地體現了表盤的創意，這是中國元素運用在現代設計中的一個體現，這樣的設計產品不但美觀而且極具趣味性。
其實2000年左右是陳幼堅名聲鵲起的關鍵階段，除了羅西尼手表海報外，他相繼完成了諸多重要項目，比方北京申辦奧運的招貼畫，在日本舉辦“東情西韻”個展，還有就是完成了可口可樂的中文標識設計。在我的《商業設計祖師爺—美國設計》里談過，可口可樂享譽全球的英文標識第一次改造由美國工業設計之父雷蒙羅維完成，而陳幼堅在巨人之后承接中文標識設計的艱巨任務，可想而知需求方對他的專業認可及厚望的寄予，但也沒有太多懸念，陳幼堅出色的完成了項目。
這是可口可樂中文標識自1979年進入中國以來首次大的變動。陳幼堅通過對“COCA-COLA”英文標識的仔細研究，發現其中的飄帶和襯線筆劃弧度的設計可以成為中西方兩種字體風格相互映襯的契合點，經過巧妙的構思與反復的修改，為了和英文標識中斯賓塞（Spencerian s cript）襯線字體相互協調，他將之前傳統的中文漢字改編設計成了彎曲流暢的“斯賓塞式”中文字體。從形式上看，多層次的飄柔絲帶設計，和飄帶中的銀色邊線，使標識更加富有時代感，經過微妙的調整和添加之后，原有的視覺元素被激活起來。從色彩上看，底色色彩為紅色，字體色彩為白色銀邊，高純度的紅色與白色形成鮮明的對比，而銀色邊線則起到了降低飽和度的作用，再加上富有韻律的銀白色飄帶設計，使整個標識更加富有動感效果。
經過陳幼堅的創意設計，使可口可樂新的中文標識既有中國特點又兼具國際風范，讓人一眼就能認出可口可樂家族的新成員。陳幼堅一直不斷地發掘各種獨特的創意思維，把已有的設計在自己的思維模式中進行解剖與重構，使作品完全脫離原本的面貌，誕生出新的意義和內涵。
然后是2008年時，已經58歲的陳幼堅為香港政府主筆形象升級項目。
這次形象升級經過了全市調研，包括舉行專業民意調查、咨詢會、核心小組討論、工作坊、設立專門網站、比賽等，收集公眾的意見和期望”；最后通過公開招標，最終確定陳幼堅的設計。
這個設計改造其實也引起了廣泛討論，有叫好有叫壞，其中內地的歐陽黎明曾經在紅動論壇專門寫貼來表示失望，并說如果由他來改造一定會更好，該貼引發了比較熱烈的討論，當時我還在讀大學，也關注過此事，不管歐陽大師的動機如何，其實這種類型的改造肯定無法一致叫好，總會有持相反意見的群體存在。
這里也剛好可以談一談香港設計風格的問題，其實個人認為陳幼堅的這個城市形象改造是很符合香港設計風格里那種內核的，我在做這期內容時，專門去了一趟香港做詳細觀察，我希望身在當地來感受他們的設計氛圍。
我為香港設計風格總結了幾個特點：
1、 非常豐富繽紛的色彩計劃（這點是給我最直接深刻的印象）。
2、 雅俗共存的設計環境
3、 東西方交融的商業特色風格
所謂為何我說陳幼堅的改造是符合香港設計精神內核，我們嘗試將幾張圖放在一起比對，圖片中我們看到香港的街景是全世界所獨有的，具備非常突出東西交融的市井風格，一眼就能讓人識別到：
你會發覺陳幼堅的這個形象圖案是很符合香港設計給人的感覺，色彩豐富繽紛，既國際化又通俗化，有東方元素（龍）又具備西方形式（圖形簡潔），所以從這個角度刨析，陳幼堅的這個升級設計是很成功的，我們如果單純從圖案的好看與否來分析，未免太過淺薄了。
關于陳幼堅的故事大致聊到這里，他有諸多作品都是非常出色的，比如做了大量極為優秀的茶類商業設計，知道后來干脆自己創了一個品牌“MR CHAN 陳茶館”，標識就是那個經典的佛手，又例如自己公司的標識四喜娃娃，又比如早期陰陽魚概念的日本西武百貨vi系統，不勝枚舉，留待大家去發掘這些資料，自行品鑒。
最后補充一點：
客戶跟設計師之間的結合就像婚姻一樣，不存在一名設計師是通吃全部客戶的，如同你再優秀也會有女生不喜歡你一樣，就算大師超級明星都不行，因為每一名設計師在長期設計創作中會形成作品風格與氣質，這些是作為匹配客戶的主要因素，假設我的企業及產品傾向更加柔美、細膩、、精致的展示風格，那么相對靳埭強及陳幼堅，我可能會首先傾向選擇陳幼堅，因為他似乎更加擅長，跟他的氣質也更吻合。
這期關于香港設計歷史的內容先聊到這里，我們除了講述香港現代設計的發展起源，還合計介紹了三位大師，分別是石漢瑞、靳埭強及陳幼堅，其實計劃聊多一些，但最后發覺最具代表性的還是這三位，聊多不如聊透，雖然最后發覺也許仍沒有聊透，但所謂猶抱琵琶半遮面，剩下的一些空間等待大家自行研究其實更好。
下一期我們將繼續國家之旅，以時空切換的方式，回到接近兩百年前的英國，因為我們將為大家探究現代設計的萌芽之地，聊一聊英國設計。
轉自：站酷-設計史太濃
提起香港設計師，大部分人首先想到的就是香港設計教父靳埭強先生，他有諸多前無古人的創舉，比方首位以設計師身份獲選香港十大杰出青年的港人、唯一設計師獲頒贈市政局設計大獎、首位華人名列世界平面設計師名人錄、并獲英國選為二十世紀杰出藝術家及設計師。在全球設計界都是大師級的人物，業內都親切的稱呼他為“靳叔”。
靳叔1942年出生于廣州番禺， 15歲才跟隨父親到香港定居，所以并非土生土長的香港人。
靳叔祖父是廣州有名的民間工藝師，從事灰塑建筑裝飾藝術，還曾做過領班參與廣州陳家祠的灰塑修建。同時伯父靳微天及姑母靳思薇早在五六十年代就是香港著名的畫家。弟弟靳杰強是物理學博士，但受家庭人員的藝術背景影響，在國畫方面也小有成就，跟靳叔一起哥倆多次在香港及美國舉辦二人聯展，非常有意思。
很多人其實都知道靳叔并非學設計或者藝術出身的，而是一名裁縫，而且還是從學徒開始。1957年剛剛到港15歲的靳叔因為不忍心父親獨自一人撐起整個家庭的開支，所以雖然懷著藝術家理想，但必須先幫家里維持生計，所以就出來找了一份裁縫學徒的工作，從搞衛生等粗重雜碎活開始，通過努力的學習很快成為裁縫師傅，每天早出晚歸，早上9點到晚上9點，并且一做就做了十年。
這十年之間靳叔內心還沒有放棄自己的藝術夢，所以每逢周日有半天假期，就會跟大伯父學習水彩跟素描等基本功。終于，靳叔的人生轉機在60年代末出現，這時候的香港剛剛經歷“六七暴動”不久，港英政府對華人變得相對友善，實施“積極不干預政策”刺激香港經濟，帶動輕工業發展，其中就包括了設計業，而此時此刻，來自西方的設計師石漢瑞已經獨立創業，經營圖語設計公司，事業發展如日中天。
這一年，港中文大學開設了校外進修部的一個設計夜間課程班，授課老師是后來鼎鼎大名的王無邪（香港著名水墨畫家及設計師），跟留學德國的鐘培正，課程恰好就是教授德國包豪斯設計理論及平面設計。
靳叔被課程吸引了，馬上報名。但課程是晚上7 點開課，而他晚上9 點半才能下班，剛好時間重疊，幸運的是靳叔當時的老板非常賞識他，同意他只要完成工作就能提前下班。通過這種方式靳叔白天做裁縫晚上學設計，此時的靳叔25歲。這里我們又推導了一下，靳叔按如此這般的師徒傳承關系，屬于包豪斯的第四代傳人。
靳叔最具代表性的是水墨風格系列作品，但其實靳叔剛剛出道時候，一直做的都是非常包豪斯的設計，1967年，就在靳叔通過夜校學習設計三個月后，經同學介紹就去了玉屋百貨做設計員，正式開始第一份設計工作，主要做櫥窗設計及促銷廣告，歷時一年。隨后去了老師鐘培正先生經營的恒美商業設計公司，從設計員開始，兩年做到設計指導，4年做到設計總監，基本上恒美大部分成功案例都出自靳叔之手，在恒美靳叔一共呆了8年，這個時候的靳叔已經由懵懂少年成為一個成熟設計師。
而且這個期間的他還是一頭長發的男子，但是已經找不到太多年輕時候的圖片，長發形象一直伴隨他到50歲。按時間推算，當時正值披頭士風靡全港的時候，我們看回當時的男明星也普遍如此，比如粵語歌之父許冠杰先生。
在做包豪斯式的現代主義及美國式的國際主義風格設計的過程中，靳叔曾經把美國波普大師安迪?沃霍爾的波普藝術融入水墨畫中，呈現機械型、幾何型效果。獲得了啟發，靳叔開始思考“為什么是自己追他人的潮流，不是自己開創潮流？”于是開始把中國傳統文化的精髓，融入西方現代設計的理念。傳統書法的筆觸被他大膽地融入設計，荷花、水墨、漢字這些極具中國文化意味的元素開始出現在他作品中。“靳氏風格”的設計水墨開始自成一派。
這個時候離開恒美的靳叔也開始正式自立門戶，當時處于80年代初，他與同學張樹新及幾位舊同事合伙創業,成立新思域設計制作,這就是他現在公司“靳與劉”的前身。靳與劉當中的劉是指合伙人劉小康，同樣是香港著名設計大師，代表作就是屈臣氏的包裝設計。跟很多大師的情況雷同，經典的作品總是從獨立經營公司后開始產生，而第一個讓靳叔聲名大噪的就是中國銀行的標志。
1980年，靳埭強被中銀集團總行委以設計標志，靳叔當時向中銀集團總行香港分行的主管索要五位數報酬，他們覺得是天價，因為內地工人一個月工資才36 元。國內設計師設計一個標志才幾十元。
受到古錢幣的啟發，靳叔以中國古錢幣為基本形態，中間方孔，上下加垂直線，成為“中”字形狀，又暗合天圓地方的意象。“想前人未想，做前人未做”、靳叔說，“如何讓一張白紙變得好看？最重要是嘗試、運用想象力讓它獨特，有趣味。”上世紀80 年代中期，中國銀行開始在內地公開使用這個標志。而靳叔憑此獲得CA 獎( 美國傳達藝術獎)，名噪一時，這個時候的靳叔剛好40不惑。
靳叔在香港做設計的歲月里，服務了大量知名的企業，可以跟這些知名品牌共同成長，相互成就對方，其實關于這塊讓設計師很感觸，就是為何要視每一個項目都是自己的孩子般愛惜，因為當設計師服務了這些企業就等于做了一項投資，如果你用足了心思讓設計趨于完美，為客戶充分考慮并全力以赴時，當這些品牌獲得了發展，設計師也是受益者之一，比方靳叔服務榮華月餅時，榮華也并非一個大牌餅家，又比方力銳的歐陽黎明在2002年服務騰訊時，也并不知道它日后會成為龐然大物，同樣的例子非常多，當這些品牌壯大時，提供設計服務的企業也會收到福蔭，成為設計企業一筆有形的財產及品牌背書。
靳叔前后服務過的知名品牌包括：太太口服液、榮華餅家、櫻雪沐浴露、嘉頓、麒麟啤酒、周生生珠寶等等。
隨著香港回歸，靳叔的靳與劉設計咨詢公司也參與服務諸多內地項目，其中著名的有重慶市政府項目，就是重慶城市標志的設計。這個項目非常值得談一談，因為靳叔曾經說過：這是記憶力最困難的設計工作。
這個標志誕生的過程是“痛苦”的，“因為重慶的文化積淀非常深厚，任何一個具象的東西，如朝天門、解放碑、大禮堂等，都很難代表重慶。難就難在要得到當地市民的普遍認可。”為了充分了解這座城市，靳叔從五所大學找來設計專業學生座談，了解重慶文化，收集大量資料。經過無數次修改，最終定稿的城標圖案是兩個人形的“慶”字。“慶”字的形象如手舞足蹈的人，喻意重慶人樂觀向上的性格，也有“巴”文化“寬厚樂天”的意蘊；兩個“慶”字疊加，又有“重”的意義，也體現了重慶作為超大城市接納眾多外來人口，兼容并蓄的特點。
而這個項目靳叔的設計費高達7位數，雖然設計費用不菲，但是靳叔說這是一個虧本的項目，因為整個項目歷經了兩年的時長才完成。由此我們再次要強調，一個標志的誕生并非單純繪制一個圖形那么的簡單，大型項目中，設計工作的復雜程度可以非常高，同時也強調，不要認為設計的價格很低廉，盡管是7位數都仍然虧本了。
其實回顧起來，靳叔十年裁縫的工作背景對他的設計態度影響也很大，這種感受出自他本人：因為做衣服需要耐心，一針一線，跟設計很像，而且當時的衣服都是定制為主，你肥一些或者瘦一些都決定了衣服的差異，這點跟設計工作就更加像了。每一個項目來之前我們都不知道客戶是誰，要求我們做什么，但是做出來的東西都是圍繞適合他本人的需求去走的。
靳叔50多年的設計歷程，兼顧了設計師與藝術家雙重身份，并且到了后期將諸多精力放在了國畫的研究上，已經是名副其實的畫家，也圓了一直以來的夢想，在此期間獲獎無數，個人榮譽加上靳與劉公司獲得的獎項的高達500多項，成為香港當之無愧的設計教父，其中值得一提的有以下這些：
洛杉磯世界藝術比賽金獎
亞洲廣告獎之最佳企業形象設計
波蘭第一屆國際電腦藝術雙年展冠軍
另外，在香港地區，靳叔更是以設計師身份獲得以下榮譽：
1979，首位獲選為香港十大杰出青年的設計師
1984，唯一獲頒贈市政局設計大獎的設計師
1991，獲香港藝術家年獎之設計師年獎
1992，被選為90年代風云男士之一
1999，獲香港特區頒予銅紫荊星章勛銜
2001，獲香港特區頒予銀紫荊星章勛銜。
羅列完這些榮譽顯然不可能，靳叔跟諸多大師一樣，年長后將一部分精力放在扶持后輩的成長上，比方香港第四代設計師的代表人物李永銓就是師從靳叔，本來這期內容是計劃一起聊聊這位“品牌醫生”的，但礙于篇幅只能暫擱，靳叔也出版了諸多著作，比方平面設計實踐》、《商業設計藝術》、《海報設計》、《廣告設計》、《日本設計師對談錄》、我在前年也曾購買他的新書《設計心法100+1》，獲益良多。
靳叔的故事還有很多，比方受李嘉誠邀約出任汕頭大學長江藝術與設計學院院長，比方在1999年為熱愛設計的年輕人創立了"靳埭強設計獎"，又比方跟美國著名設計大師保羅蘭德（就是那個收喬布斯10萬美元標志設計費，要求只出一個方案并且不修改的平面設計師大師）、跟日本平面設計之父龜倉雄策（關于他的故事可以詳見上一期《日本的設計水平為什么高》）交往的故事等。
這些足以聊三集，但今天我們先聊到這里，有機會時候我們再來展開，并且提供更多靳叔的設計作品進行賞析。
最后補充一點靳叔的思想，其實靳叔在不同的場合跟著作當作都談過不少他的創作理念，我在相對充分的了解后，針對泛數碼設計的時代，覺得特別值得在這里跟大家分享的是：我們要做到“意在筆先”，就是創作前先要在我們的腦里產生好的創意，然后再借助電腦等工具將創意完全表現出來。對于現在許多做設計的年青人來說，離開了電腦就做不出東西，其實是很不健康的現象，真正好的作品飽含設計師的全部激情，這些僅靠電腦是遠遠不夠的。“意在筆先”是中國傳統使用工具的觀念，無論用什么工具，筆或者電腦，或者將來有什么新的工具，做創作時，意在先，這是永恒的概念。
轉自：站酷-設計史太濃
藍藍設計的小編 http://m.ssll180.com