整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
. JavaScript 有哪些數據類型，它們的區別？
JavaScript 共有八種數據類型，分別是 Undefined、Null、Boolean、Number、String、Object、Symbol、BigInt。
其中 Symbol 和 BigInt 是 ES6 中新增的數據類型：
●Symbol 代表創建后獨一無二且不可變的數據類型，它主要是為了 解決可能出現的全局變量沖突的問題。
●BigInt 是一種數字類型的數據，它可以表示任意精度格式的整數，使用 BigInt 可以安全地存儲和操作大整數，即使這個數已經超出了 Number 能夠表示的安全整數范圍。
這些數據可以分為原始數據類型和引用數據類型：
●棧：原始數據類型（Undefined、Null、Boolean、Number、String）●堆：引用數據類型（對象、數組和函數）
兩種類型的區別在于存儲位置的不同：
●原始數據類型直接存儲在棧（stack）中的簡單數據段，占據空間 小、大小固定，屬于被頻繁使用數據，所以放入棧中存儲；
●引用數據類型存儲在堆（heap）中的對象，占據空間大、大小不固 定。如果存儲在棧中，將會影響程序運行的性能；引用數據類型在棧 中存儲了指針，該指針指向堆中該實體的起始地址。當解釋器尋找引 用值時，會首先檢索其在棧中的地址，取得地址后從堆中獲得實體。
堆和棧的概念存在于數據結構和操作系統內存中，在數據結構中：●在數據結構中，棧中數據的存取方式為先進后出。
●堆是一個優先隊列，是按優先級來進行排序的，優先級可以按照大 小來規定。
在操作系統中，內存被分為棧區和堆區：
●棧區內存由編譯器自動分配釋放，存放函數的參數值，局部變量的 值等。其操作方式類似于數據結構中的棧。
●堆區內存一般由開發者分配釋放，若開發者不釋放，程序結束時可 能由垃圾回收機制回收。
2. 數據類型檢測的方式有哪些
（1）typeof
其中數組、對象、null 都會被判斷為 object，其他判斷都正確。
（2）instanceof
instanceof 可以正確判斷對象的類型，其內部運行機制是判斷在其 原型鏈中能否找到該類型的原型。
可以看到，instanceof 只能正確判斷引用數據類型，而不能判斷其 本數據類型。instanceof 運算符可以用來測試一個對象在其原型鏈 中是否存在一個構造函數的 prototype 屬性。
（3） constructor
constructor 有兩個作用，一是判斷數據的類型，二是對象實例通過 constrcutor 對象訪問它的構造函數。需要注意，如果創建一個對象 來改變它的原型，constructor 就不能用來判斷數據類型了：
（4）Object.prototype.toString.call()
Object.prototype.toString.call() 使用 Object 對象的原型方法 toString 來判斷數據類型：
同樣是檢測對象 obj 調用 toString 方法，obj.toString()的結果和 Object.prototype.toString.call(obj)的結果不一樣，這是為什 么？
這是因為 toString 是 Object 的原型方法，而 Array、function 等類 型作為 Object 的實例，都重寫了 toString 方法。不同的對象類型調 用 toString 方法時，根據原型鏈的知識，調用的是對應的重寫之后
的 toString 方法（function 類型返回內容為函數體的字符串，Array 類型返回元素組成的字符串…），而不會去調用 Object 上原型 toString 方法（返回對象的具體類型），所以采用 obj.toString() 不能得到其對象類型，只能將 obj 轉換為字符串類型；因此，在想要 得到對象的具體類型時，應該調用 Object 原型上的 toString 方法。
3. null 和 undefined 區別
首先 Undefined 和 Null 都是基本數據類型，這兩個基本數據類型 分別都只有一個值，就是 undefined 和 null。
undefined 代表的含義是未定義，null 代表的含義是空對象。一般 變量聲明了但還沒有定義的時候會返回 undefined，null 主要用于 賦值給一些可能會返回對象的變量，作為初始化。
undefined 在 JavaScript 中不是一個保留字，這意味著可以使用 undefined 來作為一個變量名，但是這樣的做法是非常危險的，它會 影響對 undefined 值得判斷。我們可以通過一些方法獲得安全的 undefined 值，比如說 void 0。
當對這兩種類型使用 typeof 進行判斷時，Null 類型化會返回“object”，這是一個歷史遺留的問題。當使用雙等號對兩種類型的 值進行比較時會返回 true，使用三個等號時會返回 false。
4. intanceof 操作符的實現原理及實現
instanceof 運算符用于判斷構造函數的 prototype 屬性是否出現 在對象的原型鏈中的任何位置。
5. 如何獲取安全的 undefined 值？
因為 undefined 是一個標識符，所以可以被當作變量來使用和賦值，但是這樣會影響 undefined 的正常判斷。表達式 void ___ 沒有返 回值，因此返回結果是 undefined。void 并不改變表達式的結果，只是讓表達式不返回值。因此可以用 void 0 來獲得 undefined。
6. Object.is() 與比較操作符 “===”、“==” 的區別？
使用雙等號（==）進行相等判斷時，如果兩邊的類型不一致，則會進 行強制類型轉化后再進行比較。
使用三等號（===）進行相等判斷時，如果兩邊的類型不一致時，不 會做強制類型準換，直接返回 false。
使用 Object.is 來進行相等判斷時，一般情況下和三等號的判斷相 同，它處理了一些特殊的情況，比如 -0 和 +0 不再相等，兩個 NaN 是相等的。
7. 什么是 JavaScript 中的包裝類型？
在 JavaScript 中，基本類型是沒有屬性和方法的，但是為了便于操 作基本類型的值，在調用基本類型的屬性或方法時 JavaScript 會在 后臺隱式地將基本類型的值轉換為對象，如：
在 訪 問 'abc'.length 時 ， JavaScript 將 'abc' 在 后 臺 轉 換 成 String('abc')，然后再訪問其 length 屬性。
JavaScript 也可以使用 Object 函數顯式地將基本類型轉換為包裝類 型：
也可以使用 valueOf 方法將包裝類型倒轉成基本類型：
看看如下代碼會打印出什么：
答案是什么都不會打印，因為雖然包裹的基本類型是 false，但是 false 被包裹成包裝類型后就成了對象，所以其非值為 false，所以 循環體中的內容不會運行。
8. 為什么會有 BigInt 的提案？
JavaScript 中 Number.MAX_SAFE_INTEGER 表示最?安全數字，計算 結果是 9007199254740991，即在這個數范圍內不會出現精度丟失（?數除外）。但是?旦超過這個范圍，js 就會出現計算不準確的情況，這在?數計算的時候不得不依靠?些第三?庫進?解決，因此官?提 出了 BigInt 來解決此問題。
9. 如何判斷一個對象是空對象
使用 JSON 自帶的.stringify 方法來判斷：
使用 ES6 新增的方法 Object.keys()來判斷：
10. const 對象的屬性可以修改嗎
const 保證的并不是變量的值不能改動，而是變量指向的那個內存地 址不能改動。對于基本類型的數據（數值、字符串、布爾值），其值 就保存在變量指向的那個內存地址，因此等同于常量。
但對于引用類型的數據（主要是對象和數組）來說，變量指向數據的 內存地址，保存的只是一個指針，const 只能保證這個指針是固定不 變的，至于它指向的數據結構是不是可變的，就完全不能控制了。
11. 如果 new 一個箭頭函數的會怎么樣
箭頭函數是 ES6 中的提出來的，它沒有 prototype，也沒有自己的 this 指向，更不可以使用 arguments 參數，所以不能 New 一個箭頭函數。
new 操作符的實現步驟如下：
1.創建一個對象
2.將構造函數的作用域賦給新對象（也就是將對象的__proto__屬性 指向構造函數的 prototype 屬性）
3.指向構造函數中的代碼，構造函數中的 this 指向該對象（也就是 為這個對象添加屬性和方法）
4.返回新的對象
所以，上面的第二、三步，箭頭函數都是沒有辦法執行的。
12. 箭頭函數的 this 指向哪?？
箭頭函數不同于傳統 JavaScript 中的函數，箭頭函數并沒有屬于??的 this，它所謂的 this 是捕獲其所在上下?的 this 值，作為??的 this 值，并且由于沒有屬于??的 this，所以是不會被 new 調?的，這個所謂的 this 也不會被改變。
可以?Babel 理解?下箭頭函數:
轉化后：
13. 擴展運算符的作用及使用場景
（1）對象擴展運算符
對象的擴展運算符(...)用于取出參數對象中的所有可遍歷屬性，拷 貝到當前對象之中。
上述方法實際上等價于:
Object.assign 方法用于對象的合并，將源對象（source）的所有可 枚舉屬性，復制到目標對象（target）。Object.assign 方法的第一 個參數是目標對象，后面的參數都是源對象。(如果目標對象與源對 象有同名屬性，或多個源對象有同名屬性，則后面的屬性會覆蓋前面 的屬性)。
同樣，如果用戶自定義的屬性，放在擴展運算符后面，則擴展運算符 內部的同名屬性會被覆蓋掉。
利用上述特性就可以很方便的修改對象的部分屬性。在 redux 中的 reducer 函數規定必須是一個純函數，reducer 中的 state 對象要求 不能直接修改，可以通過擴展運算符把修改路徑的對象都復制一遍，然后產生一個新的對象返回。
需要注意：擴展運算符對對象實例的拷貝屬于淺拷貝。
（2）數組擴展運算符
數組的擴展運算符可以將一個數組轉為用逗號分隔的參數序列，且每 次只能展開一層數組。
下面是數組的擴展運算符的應用：
將數組轉換為參數序列
復制數組
要記住：擴展運算符(…)用于取出參數對象中的所有可遍歷屬性，拷 貝到當前對象之中，這里參數對象是個數組，數組里面的所有對象都 是基礎數據類型，將所有基礎數據類型重新拷貝到新的數組中。
合并數組
如果想在數組內合并數組，可以這樣：
擴展運算符與解構賦值結合起來，用于生成數組
需要注意：如果將擴展運算符用于數組賦值，只能放在參數的最后一 位，否則會報錯。
將字符串轉為真正的數組
任何 Iterator 接口的對象，都可以用擴展運算符轉為真正的數組
比較常見的應用是可以將某些數據結構轉為數組：
用于替換 es5 中的 Array.prototype.slice.call(arguments)寫法。使用 Math 函數獲取數組中特定的值
14. Proxy 可以實現什么功能？
在 Vue3.0 中通過 Proxy 來替換原本的 Object.defineProperty 來實現數據響應式。
Proxy 是 ES6 中新增的功能，它可以用來自定義對象中的操作。
代表需要添加代理的對象，handler 用來自定義對象中的操作，比如 可以用來自定義 set 或者 get 函數。
下面來通過 Proxy 來實現一個數據響應式：
在上述代碼中，通過自定義 set 和 get 函數的方式，在原本的邏輯 中插入了我們的函數邏輯，實現了在對對象任何屬性進行讀寫時發出 通知。
當然這是簡單版的響應式實現，如果需要實現一個 Vue 中的響應式，需要在 get 中收集依賴，在 set 派發更新，之所以 Vue3.0 要使用 Proxy 替換原本的 API 原因在于 Proxy 無需一層層遞歸為每個屬 性添加代理，一次即可完成以上操作，性能上更好，并且原本的實現 有一些數據更新不能監聽到，但是 Proxy 可以完美監聽到任何方式 的數據改變，唯一缺陷就是瀏覽器的兼容性不好。
15. 常用的正則表達式有哪些？
16. 對 JSON 的理解
JSON 是一種基于文本的輕量級的數據交換格式。它可以被任何的編 程語言讀取和作為數據格式來傳遞。
在項目開發中，使用 JSON 作為前后端數據交換的方式。在前端通過 將一個符合 JSON 格式的數據結構序列化為
JSON 字符串，然后將它傳遞到后端，后端通過 JSON 格式的字符串 解析后生成對應的數據結構，以此來實現前后端數據的一個傳遞。
因為 JSON 的語法是基于 js 的，因此很容易將 JSON 和 js 中的對 象弄混，但是應該注意的是 JSON 和 js 中的對象不是一回事，JSON 中對象格式更加嚴格，比如說在 JSON 中屬性值不能為函數，不能出 現 NaN 這樣的屬性值等，因此大多數的 js 對象是不符合 JSON 對 象的格式的。
在 js 中提供了兩個函數來實現 js 數據結構和 JSON 格式的轉換 處理，
JSON.stringify 函數，通過傳入一個符合 JSON 格式的數據結構，將其轉換為一個 JSON 字符串。如果傳入的數據結構不符合 JSON 格 式，那么在序列化的時候會對這些值進行對應的特殊處理，使其符合 規范。在前端向后端發送數據時，可以調用這個函數將數據對象轉化 為 JSON 格式的字符串。
JSON.parse() 函數，這個函數用來將 JSON 格式的字符串轉換為一 個 js 數據結構，如果傳入的字符串不是標準的 JSON 格式的字符串 的話，將會拋出錯誤。當從后端接收到 JSON 格式的字符串時，可以 通過這個方法來將其解析為一個 js 數據結構，以此來進行數據的訪 問。
17. JavaScript 腳本延遲加載的方式有哪些？
延遲加載就是等頁面加載完成之后再加載 JavaScript 文件。 js 延 遲加載有助于提高頁面加載速度。
一般有以下幾種方式：
defer 屬性：給 js 腳本添加 defer 屬性，這個屬性會讓腳本的加 載與文檔的解析同步解析，然后在文檔解析完成后再執行這個腳本文 件，這樣的話就能使頁面的渲染不被阻塞。多個設置了 defer 屬性
的腳本按規范來說最后是順序執行的，但是在一些瀏覽器中可能不是 這樣。
async 屬性：給 js 腳本添加 async 屬性，這個屬性會使腳本異步 加載，不會阻塞頁面的解析過程，但是當腳本加載完成后立即執行 js 腳本，這個時候如果文檔沒有解析完成的話同樣會阻塞。多個 async 屬性的腳本的執行順序是不可預測的，一般不會按照代碼的順序依次 執行。
動態創建 DOM 方式：動態創建 DOM 標簽的方式，可以對文檔的加載 事件進行監聽，當文檔加載完成后再動態的創建 script 標簽來引入 js 腳本。
使用 setTimeout 延遲方法：設置一個定時器來延遲加載 js 腳本文 件
讓 JS 最后加載：將 js 腳本放在文檔的底部，來使 js 腳本盡可能 的在最后來加載執行。
18. 什么是 DOM 和 BOM？
DOM 指的是文檔對象模型，它指的是把文檔當做一個對象，這個對象 主要定義了處理網頁內容的方法和接口。
BOM 指的是瀏覽器對象模型，它指的是把瀏覽器當做一個對象來對待，這個對象主要定義了與瀏覽器進行交互的法和接口。BOM 的核心是 window，而 window 對象具有雙重角色，它既是通過 js 訪問瀏覽器 窗口的一個接口，又是一個 Global（全局）對象。這意味著在網頁 中定義的任何對象，變量和函數，都作為全局對象的一個屬性或者方 法存在。window 對象含有 location 對象、navigator 對象、screen
對象等子對象，并且 DOM 的最根本的對象 document 對象也是 BOM 的 window 對象的子對象。
19. escape、encodeURI、encodeURIComponent 的區別
encodeURI 是對整個 URI 進行轉義，將 URI 中的非法字符轉換為合 法字符，所以對于一些在 URI 中有特殊意義的字符不會進行轉義。
encodeURIComponent 是對 URI 的組成部分進行轉義，所以一些特殊 字符也會得到轉義。
escape 和 encodeURI 的作用相同，不過它們對于 unicode 編碼為 0xff 之外字符的時候會有區別，escape 是直接在字符的 unicode 編碼前加上 %u，而 encodeURI 首先會將字符轉換為 UTF-8 的格式，再在每個字節前加上 %。
20. 對 AJAX 的理解，實現一個 AJAX 請求
AJAX 是 Asynchronous JavaScript and XML 的縮寫，指的是通過 JavaScript 的 異步通信，從服務器獲取 XML 文檔從中提取數據，再更新當前網頁的對應部分，而不用刷新整個網頁。
創建 AJAX 請求的步驟：
創建一個 XMLHttpRequest 對象。
在這個對象上使用 open 方法創建一個 HTTP 請求，open 方法所需 要的參數是請求的方法、請求的地址、是否異步和用戶的認證信息。
在發起請求前，可以為這個對象添加一些信息和監聽函數。比如說可 以通過 setRequestHeader 方法來為請求添加頭信息。還可以為這個 對象添加一個狀態監聽函數。一個 XMLHttpRequest 對象一共有 5 個狀態，當它的狀態變化時會觸發 onreadystatechange 事件，可以
通過設置監聽函數，來處理請求成功后的結果。當對象的 readyState 變為 4 的時候，代表服務器返回的數據接收完成，這個時候可以通 過判斷請求的狀態，如果狀態是 2xx 或者 304 的話則代表返回正常。
這個時候就可以通過 response 中的數據來對頁面進行更新了。
當對象的屬性和監聽函數設置完成后，最后調用 sent 方法來向服務 器發起請求，可以傳入參數作為發送的數據體。
使用 Promise 封裝 AJAX：
21. 什么是尾調用，使用尾調用有什么好處？
尾調用指的是函數的最后一步調用另一個函數。代碼執行是基于執行 棧的，所以當在一個函數里調用另一個函數時，會保留當前的執行上 下文，然后再新建另外一個執行上下文加入棧中。使用尾調用的話，因為已經是函數的最后一步，所以這時可以不必再保留當前的執行上 下文，從而節省了內存，這就是尾調用優化。但是 ES6 的尾調用優 化只在嚴格模式下開啟，正常模式是無效的。
22. ES6 模塊與 CommonJS 模塊有什么異同？
ES6 Module 和 CommonJS 模塊的區別：
CommonJS 是對模塊的淺拷?，ES6 Module 是對模塊的引?，即 ES6 Module 只存只讀，不能改變其值，也就是指針指向不能變，類似 const；
import 的接?是 read-only（只讀狀態），不能修改其變量值。 即 不能修改其變量的指針指向，但可以改變變量內部指針指向，可以對 commonJS 對重新賦值（改變指針指向），但是對 ES6 Module 賦值會 編譯報錯。
ES6 Module 和 CommonJS 模塊的共同點：
CommonJS 和 ES6 Module 都可以對引?的對象進?賦值，即對對象內 部屬性的值進?改變。
23. for...in 和 for...of 的區別
for…of 是 ES6 新增的遍歷方式，允許遍歷一個含有 iterator 接口 的數據結構（數組、對象等）并且返回各項的值，和 ES3 中的 for…in 的區別如下
for…of 遍歷獲取的是對象的鍵值，for…in 獲取的是對象的鍵名；
for… in 會遍歷對象的整個原型鏈，性能非常差不推薦使用，而 for … of 只遍歷當前對象不會遍歷原型鏈；
對于數組的遍歷，for…in 會返回數組中所有可枚舉的屬性(包括原 型鏈上可枚舉的屬性)，for…of 只返回數組的下標對應的屬性值；
總結：for...in 循環主要是為了遍歷對象而生，不適用于遍歷數組；for...of 循環可以用來遍歷數組、類數組對象，字符串、Set、Map 以 及 Generator 對象。
24. ajax、axios、fetch 的區別
（1）AJAX
Ajax 即“AsynchronousJavascriptAndXML”（異步 JavaScript 和 XML），是指一種創建交互式應用的網頁開發技術。它是一種在 無需重新加載整個網頁的情況下，能夠更新部分網頁的技術。通過在 后臺與服務器進行少量數據交換，Ajax 可以使網頁實現異步更新。這意味著可以在不重新加載整個網頁的情況下，對網頁的某部分進行 更新。傳統的網頁（不使用 Ajax）如果需要更新內容，必須重載整 個網頁頁面。其缺點如下：
本身是針對 MVC 編程，不符合前端 MVVM 的浪潮
基于原生 XHR 開發，XHR 本身的架構不清晰
不符合關注分離（Separation of Concerns）的原則
配置和調用方式非常混亂，而且基于事件的異步模型不友好。
（2）Fetch
fetch 號稱是 AJAX 的替代品，是在 ES6 出現的，使用了 ES6 中的 promise 對象。Fetch 是基于 promise 設計的。Fetch 的代碼結構比
起 ajax 簡單多。fetch 不是 ajax 的進一步封裝，而是原生 js，沒有 使用 XMLHttpRequest 對象。
fetch 的優點：
語法簡潔，更加語義化
基于標準 Promise 實現，支持 async/await
更加底層，提供的 API 豐富（request, response）
脫離了 XHR，是 ES 規范里新的實現方式
fetch 的缺點：
fetch 只對網絡請求報錯，對 400，500 都當做成功的請求，服務器 返回 400，500 錯誤碼時并不會 reject，只有網絡錯誤這些導致請 求不能完成時，fetch 才會被 reject。
fetch 默 認 不 會 帶 cookie ， 需 要 添 加 配 置 項 ：fetch(url, {credentials: 'include'})
fetch 不 支 持 abort ， 不 支 持 超 時 控 制 ， 使 用 setTimeout 及 Promise.reject 的實現的超時控制并不能阻止請求過程繼續在后臺 運行，造成了流量的浪費
fetch 沒有辦法原生監測請求的進度，而 XHR 可以
（3）Axios
Axios 是一種基于 Promise 封裝的 HTTP 客戶端，其特點如下：瀏覽器端發起 XMLHttpRequests 請求
node 端發起 http 請求
支持 Promise API
監聽請求和返回
對請求和返回進行轉化
取消請求
自動轉換 json 數據
客戶端支持抵御 XSRF 攻擊
25. 對原型、原型鏈的理解
在 JavaScript 中是使用構造函數來新建一個對象的，每一個構造函 數的內部都有一個 prototype 屬性，它的屬性值是一個對象，這個 對象包含了可以由該構造函數的所有實例共享的屬性和方法。當使用 構造函數新建一個對象后，在這個對象的內部將包含一個指針，這個 指針指向構造函數的 prototype 屬性對應的值，在 ES5 中這個指針 被稱為對象的原型。一般來說不應該能夠獲取到這個值的，但是現在 瀏覽器中都實現了 __proto__ 屬性來訪問這個屬性，但是最好不要 使用這個屬性，因為它不是規范中規定的。ES5 中新增了一個 Object.getPrototypeOf() 方法，可以通過這個方法來獲取對象的原 型。
當訪問一個對象的屬性時，如果這個對象內部不存在這個屬性，那么 它就會去它的原型對象里找這個屬性，這個原型對象又會有自己的原 型，于是就這樣一直找下去，也就是原型鏈的概念。原型鏈的盡頭一 般來說都是 Object.prototype 所以這就是新建的對象為什么能夠 使用 toString() 等方法的原因。
特點：JavaScript 對象是通過引用來傳遞的，創建的每個新對象實 體中并沒有一份屬于自己的原型副本。當修改原型時，與之相關的對 象也會繼承這一改變。
26. 原型鏈的終點是什么？如何打印出原型鏈的終點？
由于 Object 是構造函數，原型鏈終點 Object.prototype.__proto__，而 Object.prototype.__proto__=== null // true，所以，原型鏈 的終點是 null。原型鏈上的所有原型都是對象，所有的對象最終都 是由 Object 構造的，而 Object.prototype 的下一級是
Object.prototype.__proto__。
27. 對作用域、作用域鏈的理解
1）全局作用域和函數作用域
（1）全局作用域
最外層函數和最外層函數外面定義的變量擁有全局作用域
所有未定義直接賦值的變量自動聲明為全局作用域
所有 window 對象的屬性擁有全局作用域
全局作用域有很大的弊端，過多的全局作用域變量會污染全局命名空 間，容易引起命名沖突。
（2）函數作用域
函數作用域聲明在函數內部的變零，一般只有固定的代碼片段可以訪 問到
作用域是分層的，內層作用域可以訪問外層作用域，反之不行 2）塊級作用域
使用 ES6 中新增的 let 和 const 指令可以聲明塊級作用域，塊級作用 域可以在函數中創建也可以在一個代碼塊中的創建（由{ }包裹的代 碼片段）
let 和 const 聲明的變量不會有變量提升，也不可以重復聲明
在循環中比較適合綁定塊級作用域，這樣就可以把聲明的計數器變量 限制在循環內部。
作用域鏈：
在當前作用域中查找所需變量，但是該作用域沒有這個變量，那這個 變量就是自由變量。如果在自己作用域找不到該變量就去父級作用域 查找，依次向上級作用域查找，直到訪問到 window 對象就被終止，這一層層的關系就是作用域鏈。
作用域鏈的作用是保證對執行環境有權訪問的所有變量和函數的有 序訪問，通過作用域鏈，可以訪問到外層環境的變量和函數。
作用域鏈的本質上是一個指向變量對象的指針列表。變量對象是一個 包含了執行環境中所有變量和函數的對象。作用域鏈的前端始終都是 當前執行上下文的變量對象。全局執行上下文的變量對象（也就是全 局對象）始終是作用域鏈的最后一個對象。
當查找一個變量時，如果當前執行環境中沒有找到，可以沿著作用域 鏈向后查找。
28. 對 this 對象的理解
this 是執行上下文中的一個屬性，它指向最后一次調用這個方法的 對象。在實際開發中，this 的指向可以通過四種調用模式來判斷。
第一種是函數調用模式，當一個函數不是一個對象的屬性時，直接作 為函數來調用時，this 指向全局對象。
第二種是方法調用模式，如果一個函數作為一個對象的方法來調用時，this 指向這個對象。
第三種是構造器調用模式，如果一個函數用 new 調用時，函數執行 前會新創建一個對象，this 指向這個新創建的對象。
第四種是 apply 、 call 和 bind 調用模式，這三個方法都可以顯 示的指定調用函數的 this 指向。其中 apply 方法接收兩個參數：一個是 this 綁定的對象，一個是參數數組。call 方法接收的參數，第一個是 this 綁定的對象，后面的其余參數是傳入函數執行的參數。
也就是說，在使用 call() 方法時，傳遞給函數的參數必須逐個列舉 出來。bind 方法通過傳入一個對象，返回一個 this 綁定了傳入對 象的新函數。這個函數的 this 指向除了使用 new 時會被改變，其 他情況下都不會改變。
這四種方式，使用構造器調用模式的優先級最高，然后是 apply、call 和 bind 調用模式，然后是方法調用模式，然后是函數調用模式。
29. call() 和 apply() 的區別？
它們的作用一模一樣，區別僅在于傳入參數的形式的不同。
apply 接受兩個參數，第一個參數指定了函數體內 this 對象的指向，第二個參數為一個帶下標的集合，這個集合可以為數組，也可以為類 數組，apply 方法把這個集合中的元素作為參數傳遞給被調用的函數。
call 傳入的參數數量不固定，跟 apply 相同的是，第一個參數也是 代表函數體內的 this 指向，從第二個參數開始往后，每個參數被依 次傳入函數。
30. 異步編程的實現方式？
JavaScript 中的異步機制可以分為以下幾種：
回調函數 的方式，使用回調函數的方式有一個缺點是，多個回調函 數嵌套的時候會造成回調函數地獄，上下兩層的回調函數間的代碼耦 合度太高，不利于代碼的可維護。
Promise 的方式，使用 Promise 的方式可以將嵌套的回調函數作為 鏈式調用。但是使用這種方法，有時會造成多個 then 的鏈式調用，可能會造成代碼的語義不夠明確。
generator 的方式，它可以在函數的執行過程中，將函數的執行權轉 移出去，在函數外部還可以將執行權轉移回來。當遇到異步函數執行 的時候，將函數執行權轉移出去，當異步函數執行完畢時再將執行權 給轉移回來。因此在 generator 內部對于異步操作的方式，可以以 同步的順序來書寫。使用這種方式需要考慮的問題是何時將函數的控 制權轉移回來，因此需要有一個自動執行 generator 的機制，比如 說 co 模塊等方式來實現 generator 的自動執行。
async 函數 的方式，async 函數是 generator 和 promise 實現的 一個自動執行的語法糖，它內部自帶執行器，當函數內部執行到一個 await 語句的時候，如果語句返回一個 promise 對象，那么函數將 會等待 promise 對象的狀態變為 resolve 后再繼續向下執行。因此 可以將異步邏輯，轉化為同步的順序來書寫，并且這個函數可以自動 執行。
31. 對 Promise 的理解
Promise 是異步編程的一種解決方案，它是一個對象，可以獲取異步 操作的消息，他的出現大大改善了異步編程的困境，避免了地獄回調，它比傳統的解決方案回調函數和事件更合理和更強大。
所謂 Promise，簡單說就是一個容器，里面保存著某個未來才會結束 的事件（通常是一個異步操作）的結果。從語法上說，Promise 是一 個對象，從它可以獲取異步操作的消息。Promise 提供統一的 API，各種異步操作都可以用同樣的方法進行處理。
（1）Promise 的實例有三個狀態:
Pending（進行中）
Resolved（已完成）
Rejected（已拒絕）
當把一件事情交給 promise 時，它的狀態就是 Pending，任務完成了 狀態就變成了 Resolved、沒有完成失敗了就變成了 Rejected。
（2）Promise 的實例有兩個過程：
pending -> fulfilled : Resolved（已完成）
pending -> rejected：Rejected（已拒絕）
注意：一旦從進行狀態變成為其他狀態就永遠不能更改狀態了。
Promise 的特點：
對象的狀態不受外界影響。promise 對象代表一個異步操作，有三種 狀態，pending（進行中）、fulfilled（已成功）、rejected（已失 敗）。只有異步操作的結果，可以決定當前是哪一種狀態，任何其他 操作都無法改變這個狀態，這也是 promise 這個名字的由來——“承 諾”；
一旦狀態改變就不會再變，任何時候都可以得到這個結果。promise 對象的狀態改變，只有兩種可能：從 pending 變為 fulfilled，從 pending 變為 rejected。這時就稱為 resolved（已定型）。如果改 變已經發生了，你再對 promise 對象添加回調函數，也會立即得到這 個結果。這與事件（event）完全不同，事件的特點是：如果你錯過 了它，再去監聽是得不到結果的。
Promise 的缺點：
無法取消 Promise，一旦新建它就會立即執行，無法中途取消。
如果不設置回調函數，Promise 內部拋出的錯誤，不會反應到外部。
當處于 pending 狀態時，無法得知目前進展到哪一個階段（剛剛開始 還是即將完成）。
總結：
Promise 對象是異步編程的一種解決方案，最早由社區提出。Promise 是一個構造函數，接收一個函數作為參數，返回一個 Promise 實例。一個 Promise 實例有三種狀態，分別是 pending、resolved 和 rejected，分別代表了進行中、已成功和已失敗。實例的狀態只能由 pending 轉變 resolved 或者 rejected 狀態，并且狀態一經改變，就凝固了，無法再被改變了。
狀態的改變是通過 resolve() 和 reject() 函數來實現的，可以在 異步操作結束后調用這兩個函數改變 Promise 實例的狀態，它的原 型上定義了一個 then 方法，使用這個 then 方法可以為兩個狀態的 改變注冊回調函數。這個回調函數屬于微任務，會在本輪事件循環的 末尾執行。
注意：在構造 Promise 的時候，構造函數內部的代碼是立即執行的
32. Promise 解決了什么問題
在工作中經常會碰到這樣一個需求，比如我使用 ajax 發一個 A 請求 后，成功后拿到數據，需要把數據傳給 B 請求；那么需要如下編寫代 碼：
上面的代碼有如下缺點：
后一個請求需要依賴于前一個請求成功后，將數據往下傳遞，會導致 多個 ajax 請求嵌套的情況，代碼不夠直觀。
如果前后兩個請求不需要傳遞參數的情況下，那么后一個請求也需要 前一個請求成功后再執行下一步操作，這種情況下，那么也需要如上 編寫代碼，導致代碼不夠直觀。
Promise 出現之后，代碼變成這樣：
這樣代碼看起了就簡潔了很多，解決了地獄回調的問題。
33. 對 async/await 的理解
async/await 其實是 Generator 的語法糖，它能實現的效果都能用 then 鏈來實現，它是為優化 then 鏈而開發出來的。從字面上來看，async 是“異步”的簡寫，await 則為等待，所以很好理解 async 用 于申明一個 function 是異步的，而 await 用于等待一個異步方法 執行完成。當然語法上強制規定 await 只能出現在 asnyc 函數中，先 來看看 async 函數返回了什么：
所以，async 函數返回的是一個 Promise 對象。async 函數（包含 函數語句、函數表達式、Lambda 表達式）會返回一個 Promise 對象，如果在函數中 return 一個直接量，async 會把這個直接量通過 Promise.resolve() 封裝成 Promise 對象。
async 函數返回的是一個 Promise 對象，所以在最外層不能用 await 獲取其返回值的情況下，當然應該用原來的方式：then() 鏈 來處理這個 Promise 對象，就像這樣：
那如果 async 函數沒有返回值，又該如何？很容易想到，它會返回 Promise.resolve(undefined)。
聯想一下 Promise 的特點——無等待，所以在沒有 await 的情況下 執行 async 函數，它會立即執行，返回一個 Promise 對象，并且，絕不會阻塞后面的語句。這和普通返回 Promise 對象的函數并無二 致。
注意：Promise.resolve(x) 可以看作是 new Promise(resolve => resolve(x)) 的簡寫，可以用于快速封裝字面量對象或其他對象，將 其封裝成 Promise 實例。
34. async/await 的優勢
單一的 Promise 鏈并不能發現 async/await 的優勢，但是，如果需 要處理由多個 Promise 組成的 then 鏈的時候，優勢就能體現出來 了（很有意思，Promise 通過 then 鏈來解決多層回調的問題，現在 又用 async/await 來進一步優化它）。
假設一個業務，分多個步驟完成，每個步驟都是異步的，而且依賴于 上一個步驟的結果。仍然用 setTimeout 來模擬異步操作：
現在用 Promise 方式來實現這三個步驟的處理：
輸出結果 result 是 step3() 的參數 700 + 200 = 900。doIt() 順 序執行了三個步驟，一共用了 300 + 500 + 700 = 1500 毫秒，和 console.time()/console.timeEnd() 計算的結果一致。
如果用 async/await 來實現呢，會是這樣：
結果和之前的 Promise 實現是一樣的，但是這個代碼看起來是不是
清晰得多，幾乎跟同步代碼一樣
35. async/await 對比 Promise 的優勢
代碼讀起來更加同步，Promise 雖然擺脫了回調地獄，但是 then 的
鏈式調?也會帶來額外的閱讀負擔
Promise 傳遞中間值?常麻煩，?async/await?乎是同步的寫法，?常優雅
錯誤處理友好，async/await 可以?成熟的 try/catch，Promise 的 錯誤捕獲?常冗余
調試友好，Promise 的調試很差，由于沒有代碼塊，你不能在?個返 回表達式的箭頭函數中設置斷點，如果你在?個.then 代碼塊中使?調試器的步進(step-over)功能，調試器并不會進?后續的.then 代 碼塊，因為調試器只能跟蹤同步代碼的每?步。
36. 對象創建的方式有哪些？
一般使用字面量的形式直接創建對象，但是這種創建方式對于創建大
量相似對象的時候，會產生大量的重復代碼。但 js 和一般的面向對
象的語言不同，在 ES6 之前它沒有類的概念。但是可以使用函數來
進行模擬，從而產生出可復用的對象創建方式，常見的有以下幾種：
（1）第一種是工廠模式，工廠模式的主要工作原理是用函數來封裝 創建對象的細節，從而通過調用函數來達到復用的目的。但是它有一 個很大的問題就是創建出來的對象無法和某個類型聯系起來，它只是 簡單的封裝了復用代碼，而沒有建立起對象和類型間的關系。
（2）第二種是構造函數模式。js 中每一個函數都可以作為構造函數，只要一個函數是通過 new 來調用的，那么就可以把它稱為構造函數。執行構造函數首先會創建一個對象，然后將對象的原型指向構造函數 的 prototype 屬性，然后將執行上下文中的 this 指向這個對象，最后再執行整個函數，如果返回值不是對象，則返回新建的對象。因 為 this 的值指向了新建的對象，因此可以使用 this 給對象賦值。構造函數模式相對于工廠模式的優點是，所創建的對象和構造函數建 立起了聯系，因此可以通過原型來識別對象的類型。但是構造函數存 在一個缺點就是，造成了不必要的函數對象的創建，因為在 js 中函 數也是一個對象，因此如果對象屬性中如果包含函數的話，那么每次 都會新建一個函數對象，浪費了不必要的內存空間，因為函數是所有 的實例都可以通用的。
（3）第三種模式是原型模式，因為每一個函數都有一個 prototype 屬性，這個屬性是一個對象，它包含了通過構造函數創建的所有實例 都能共享的屬性和方法。因此可以使用原型對象來添加公用屬性和方 法，從而實現代碼的復用。這種方式相對于構造函數模式來說，解決 了函數對象的復用問題。但是這種模式也存在一些問題，一個是沒有 辦法通過傳入參數來初始化值，另一個是如果存在一個引用類型如 Array 這樣的值，那么所有的實例將共享一個對象，一個實例對引用 類型值的改變會影響所有的實例。
（4）第四種模式是組合使用構造函數模式和原型模式，這是創建自 定義類型的最常見方式。因為構造函數模式和原型模式分開使用都存 在一些問題，因此可以組合使用這兩種模式，通過構造函數來初始化 對象的屬性，通過原型對象來實現函數方法的復用。這種方法很好的 解決了兩種模式單獨使用時的缺點，但是有一點不足的就是，因為使 用了兩種不同的模式，所以對于代碼的封裝性不夠好。
（5）第五種模式是動態原型模式，這一種模式將原型方法賦值的創 建過程移動到了構造函數的內部，通過對屬性是否存在的判斷，可以 實現僅在第一次調用函數時對原型對象賦值一次的效果。這一種方式 很好地對上面的混合模式進行了封裝。
（6）第六種模式是寄生構造函數模式，這一種模式和工廠模式的實 現基本相同，我對這個模式的理解是，它主要是基于一個已有的類型，在實例化時對實例化的對象進行擴展。這樣既不用修改原來的構造函 數，也達到了擴展對象的目的。它的一個缺點和工廠模式一樣，無法 實現對象的識別。
37. 對象繼承的方式有哪些？
（1）第一種是以原型鏈的方式來實現繼承，但是這種實現方式存在 的缺點是，在包含有引用類型的數據時，會被所有的實例對象所共享，容易造成修改的混亂。還有就是在創建子類型的時候不能向超類型傳 遞參數。
（2）第二種方式是使用借用構造函數的方式，這種方式是通過在子 類型的函數中調用超類型的構造函數來實現的，這一種方法解決了不 能向超類型傳遞參數的缺點，但是它存在的一個問題就是無法實現函 數方法的復用，并且超類型原型定義的方法子類型也沒有辦法訪問到。
（3）第三種方式是組合繼承，組合繼承是將原型鏈和借用構造函數 組合起來使用的一種方式。通過借用構造函數的方式來實現類型的屬 性的繼承，通過將子類型的原型設置為超類型的實例來實現方法的繼 承。這種方式解決了上面的兩種模式單獨使用時的問題，但是由于我 們是以超類型的實例來作為子類型的原型，所以調用了兩次超類的構 造函數，造成了子類型的原型中多了很多不必要的屬性。
（4）第四種方式是原型式繼承，原型式繼承的主要思路就是基于已 有的對象來創建新的對象，實現的原理是，向函數中傳入一個對象，然后返回一個以這個對象為原型的對象。這種繼承的思路主要不是為 了實現創造一種新的類型，只是對某個對象實現一種簡單繼承，ES5 中定義的 Object.create() 方法就是原型式繼承的實現。缺點與原 型鏈方式相同。
（5）第五種方式是寄生式繼承，寄生式繼承的思路是創建一個用于 封裝繼承過程的函數，通過傳入一個對象，然后復制一個對象的副本，然后對象進行擴展，最后返回這個對象。這個擴展的過程就可以理解 是一種繼承。這種繼承的優點就是對一個簡單對象實現繼承，如果這 個對象不是自定義類型時。缺點是沒有辦法實現函數的復用。
（6）第六種方式是寄生式組合繼承，組合繼承的缺點就是使用超類 型的實例做為子類型的原型，導致添加了不必要的原型屬性。寄生式 組合繼承的方式是使用超類型的原型的副本來作為子類型的原型，這 樣就避免了創建不必要的屬性。
38. 哪些情況會導致內存泄漏
以下四種情況會造成內存的泄漏：
意外的全局變量：由于使用未聲明的變量，而意外的創建了一個全局 變量，而使這個變量一直留在內存中無法被回收。
被遺忘的計時器或回調函數：設置了 setInterval 定時器，而忘記 取消它，如果循環函數有對外部變量的引用的話，那么這個變量會被 一直留在內存中，而無法被回收。
脫離 DOM 的引用：獲取一個 DOM 元素的引用，而后面這個元素被刪 除，由于一直保留了對這個元素的引用，所以它也無法被回收。
閉包：不合理的使用閉包，從而導致某些變量一直被留在內存當中。
者：靛藍工房 文章轉自78DM
原標題：一起來做模型之“MG艾比安篇”，淺談打磨作用與金屬色/偽電鍍應用，因標題字數限制有刪減
又來到了一起來做模型的系列欄目了。本次我選用了萬代MG1/100 “艾比安高達”作為素體對象進行制作。最主要就是這個堆積了很久想盡快清理了它。
本次的制作中，在基礎修整部分，我將會把重點放在塑料零件的表面打磨基礎理論，介紹打磨的作用、手法、常用工具介紹；
而在涂裝上我打算做成金屬+電鍍色效果，因此我會重點介紹金屬色的使用手法，金屬色上覆蓋透明色的操作要領。
上一期的水性漆使用中沒想到引起了各位的熱烈討論，而就像是命運開玩笑一般，在我發帖的三天后就在貼吧上出了個瓜，某位玩家因為過分相信水性漆而導致了患病。確實是有點諷刺。但也證明了涂料安全性的論點。
而金屬漆的毒性可以說是在同系列的涂料中最強烈的。而出于保命以及不為各位玩家帶壞頭，本次的制作只使用我個人相信的日本漆進行制作。
說白了就是郡士GX系以及SM系金屬色。但不管使用什么涂料，也請各位做好完善的個人防護再來制作模型。
那么事不宜遲，我們現在就來開始制作艾比安吧。
本次制作中除了模型套件以外，主要將使用水口鉗、筆刀、銼刀、鷹嘴刻線刀、砂紙、面相筆、GX系以及SM系金屬色。同時還準備好GX系列透明色。
我這次要做的正是電鍍風格涂裝。這種涂裝的作品對模型的表面處理要求非常高，任何瑕疵都會在光澤面下表露無遺。這是對作者基本功的一次考驗。
第一部分：零件水口及分模線的打磨方法。
制作模型的第一步，依舊還是水口打磨。雖然關于水口打磨每一期都有說，都是老調重彈。但考慮到很多人沒看前幾期，而且打磨又是本次的重點之一，我還是簡略說說吧。
我在這里選用了武裝的一個圓形零件進行操作展示。
首先，我們先把零件裁剪下來。初步裁剪的時候需要注意水口應留有較多的距離，以保障零件的表面完整。
接著我們使用水口鉗逐點逐點地剪除水口。注意采用逐步貼近零件多次修剪的方法，可以防止一下裁剪太多而導致的缺肉風險。
請勿太過相信網紅們一刀流的制作方法。那種偷懶性質的做法會增加損壞零件的風險。如果你有足夠留意萬代或者壽屋的模型說明書前面的注意事項，就會發現日本的模型生產商也是建議你采用這種逐步剪切的方法的。
因為是圓弧型外表的零件，水口鉗是無法完全剪除干凈的。但也無妨，像圖中這樣裁剪到呈現切線貼近圓弧邊緣就可以了。
接下來我們使用筆刀切除水口兩端多余的凸角。同樣注意不需要切除太多以防止缺肉。
最后，我會對疊砂紙但不折平，使用圓角按壓在零件表面，以畫圈的形式打磨水口位置。
考慮到這是涂裝的模型作品。砂紙我是使用1000目的直接打磨便能滿足制作需求。
砂紙打磨完成后，可以看到水口已經完全消失，零件表面是規則而平整的圓弧外形。
使用砂紙打磨弧形的零件表面的時候，可以像圖中這種，對疊砂紙但不折平，然后以圓角按壓在零件表面。砂紙的圓角具有充足彈性，當按壓到零件上時會因擠壓而形成適配弧面的角度。這樣的打磨小技巧可以幫助各位快速而高效地打磨弧面，不用擔心磨壞弧度
像這樣的操作，僅使用水口鉗、筆刀、砂紙，基本能滿足全部的水口打磨。
但如果水口出現的位置是平面的話，我們還能結合銼刀來提高操作的便利性與效率性。
這是背包上的零件，剛好是直線邊緣位置上存在水口的理想示范。
同樣地，我先使用水口鉗大概修剪了水口。因為是在平面上的水口。郡士水口鉗鋒利的單刃結構幾乎僅需一刀就能把水口去除。
接著使用筆刀將殘余的水口痕跡修剪去除。
然后我們使用銼刀按壓在水口出現的平面上來回拖行兩三遍，水口就已經完全消失不見。我手上的這把是郡士的細目型銼刀，刀身上呈現層紋的切割片結構，就像是剃須刀那樣。操作時只需要注意用力方向，零件表面上的凸起瑕疵很容易就會被削除而且在零件表面上留下的痕跡很少，是打磨水口時非常好用的輔助型工具。我們在很多日本模型博主的視頻里面都能發現他們在使用這款銼刀處理水口（例如宇宙戰艦大和號的日本相關模型制作視頻），強烈建議各位嘗試。
最后僅需要使用砂紙打磨表面就完成了操作。因為已經是使用銼刀預打磨了一遍，所以砂紙打磨時候的操作壓力很低，很容易就可以打磨平滑。由此可見，配合銼刀與砂紙來進行水口打磨，效率性非常高，也能節約砂紙的損耗。
換句話說，花幾十塊買一把銼刀，可以節省好幾年里面幾百塊的砂紙錢。
這是翅膀狀零件，可以看到在零件中央有著一道貫穿水口的分模線，非常扎眼必須要完全去除。
去除的方法也是非常簡便，只需要使用1000目砂紙來回打磨，耐心地重復操作就能去除干凈。如果覺得僅用砂紙打磨的操作壓力很大，當然也可以配合銼刀使用。
這是打磨前后的效果對比。可見這道分模線的存在是非常顯眼的。打磨去除是制作中必要的操作，可不能馬虎處理。
像這種水口伴隨分模線的瑕疵，在塑料模型中比比皆是，像圖中的紅色裝甲零件上便能再次發現。
我們采用相同的手法進行處理，就能得到平滑統一的零件表面。
面積較大的塑料零件很可能還會有波紋。就像圖片紅色零件反光面上出現的弧形層紋。這是塑料在注模時流動而帶入的瑕疵，波紋較深的位置放任不管也有可能會透過漆面表露出來，因此同樣需要處理干凈。
這里只需要使用1000目砂紙直接對零件表面采用按壓式打磨就能完全去除波紋瑕疵。
有時水口出現的位置還會出現模具開合而產生的高低斷層面，一個零件上存在三種瑕疵也確實是讓人頭痛。
但不管是什么瑕疵，沒有銼刀+砂紙處理不了的，這里同樣通過打磨的手法完全去除。
如此不斷重復，我們就能把塑料零件上的水口、分模線、波紋面完全去除干凈了。
階段總結：
水口處理確實是千古不變的恒定話題。要處理好水口其實能使用的工具或者方法無非也就那么兩三種。
關于水口鉗，當然是性能好的會省事很多。常見的，本人津津樂道的恐怕就是田宮的神手。但這個價格太貴且耐用性太差，其實性價比并不高。我個人會推薦用本文中的這一把郡士單刃鉗。150左右的價格跟田宮金牌相近，還略微便宜少許。而使用性能上比田宮金牌要好，耐用性也要比田宮的產品更強更耐操。性價比確實是很不錯的，因此是我的個人推薦。
而銼刀則應該選用層紋型的銼刀。這種多排刀片的結構跟我們用的剃須刀相似，使用方向正確，就會去除表面凸起的異物但不會傷到皮膚，在模型制作中也是同理。如果只是打磨水口就不需要使用顆粒型的銼刀了，這個更加偏向于整形改造，打磨的壓力比層紋型的高。
至于砂紙嘛，就不做討論了，選用合適目數的就好。對比田宮的砂紙，郡士的砂紙打磨的手感較為生澀，但耐用性更強。田宮的砂紙打磨順滑性更好，但耐用性較差更換頻率更密。所以各位就按照自己的喜好與經濟狀況選擇吧。
第二部分：縮膠的產生與打磨處理方法
縮膠，是塑料在凝固硬化時體積收縮而產生的自然現象。通常在面積較大，或厚度較高的零件上會出現得尤為明顯。
如果是消光涂裝的模型，縮膠的位置往往不會十分明顯，因為光線在漫反射下有一定的遮瑕作用。但如果是光澤面的作品，縮膠會因反光差異而被展露出來。在制作金屬色涂裝、偽電鍍涂裝這種光澤模型時，縮膠需要打磨干凈才能盡善盡美。
這是上文中打磨過水口的零件，一眼看上去表面平整規則。
倘若你對表面進行打磨，就會發現表面上有兩處圓點型的凹陷。這就是縮膠了。
面對這種輕微的縮膠，我們只需要使用1000目砂紙按壓表面進行打磨就可以完全去除。
像這樣，表面經過打磨后縮膠已經完全消失，且零件的邊緣線尤為銳利，這都是對零件進行充分打磨而帶來的好處。
以翅膀零件來舉例，可以看到縮膠的位置更為明顯。而且縮膠內陷的造型非常規則。翻過背后，我們就能發現縮膠的位置跟零件內部的固定框架、組合樁等完全匹配。
因為零件越厚，收縮越大，縮膠就越是明顯。剛好內部框架、組合樁等位置厚度要比空缺位置大，因此縮膠就全都集中在這些位置上了。
這塊零件的表面還有不少的細節刻線。在打磨縮膠的時候可能會把刻線也一起磨掉，因此在打磨去除縮膠前，我們需要先對刻線進行加深操作。
圖中我使用的是郡士的鷹嘴刻線刀，選用了0.15mm寬度的刀頭。這個尺寸與原零件的線寬完全一致，只需要簡單地勾拉幾次就能完成加深。
然后就是使用1000目砂紙對零件按壓打磨。因為這個零件的面積較大，縮膠分布廣，所以打磨操作需要很有耐心，多花時間才能完成。
經過數次打磨，縮膠位置已經完全去除干凈了。
這是肩甲上的零件。經過表面打磨可以看到其實表面也是存在較為明顯的縮膠情況。
階段總結：
縮膠，是廣泛存在于塑料零件上的瑕疵。尤其出現在組合樁等厚度較大的位置。而對模型零件的表面進行打磨，原本難以發現的縮膠就能輕易地發現，從而進行修正。
同時，經過打磨之后的零件表面會出現很多細小的打磨坑紋。如果我們使用1000目砂紙進行打磨，那么打磨后的坑紋也是會在1000目或以下。我們涂裝前噴涂的1000目水補土可以完美地填補坑紋，并且形成卡扣結構，以物理形式令漆面更加牢固地附著在零件表面，不易掉漆或者磨花。
綜上所述，總結全件打磨對制作模型所帶來的好處：
1、 去除例如水口、分模線、飛邊、落差、波紋等塑料瑕疵；
2、 去除縮膠等表面缺陷。
3、 物理層面上增強水補土對零件的附著力。
說到縮膠打磨，可能就會有朋友問：“為什么不用牙膏補土填平后再打磨”之類的問題。
確實，使用牙膏補土填平打磨也是很常見的方法。可是牙膏補土本身的收縮性也很強，打磨過程中掉落的可能性也有，用起來需要注意的事情也很多，用不好也會適得其反。
再考慮到我這里邊幅有限，關于牙膏補土填補，或者AB補土填補空缺的操作，就讓我日后再開一期詳談吧。
第三部分：線條的強化加深操作。
以小腿裝甲為例。此零件左右兩端均有一段由斜角狀細節產生的90°夾角高低線。這種細節線位沒有規則線槽，在涂裝后難以進行滲線，因此我們需要進行加深刻畫。
我使用郡士的0.15mm寬度的鷹嘴刻線刀，以夾角為輔助在高低線拉刻2~3次便能制作出一道規則的線槽。如此一來便不用擔心涂裝后無法滲線的問題了。
這是小腿接近膝蓋的零件，在紅色零件的一側存在兩道帶有斜角的高低細節線。這里同樣沒有規則線槽，需要進行加深刻畫。可是這里的夾角太淺，無法為刻線刀提供輔助，因此我們需要使用額外的輔助措施。
這里我是用了透明硬邊膠帶進行輔助。郡士的鷹嘴刻線刀指向性較強，只需要稍加輔助就能順暢地完成刻線制作。
加深高低刻線之后，同樣使用1000目的砂紙將零件的表面打磨感覺，去除刻線時產生的多余毛刺就能完成全部操作。
圖中這是頭部的零件，我同樣使用0.15mm寬度的刀頭對刻線進行加深操作。
0.15mm的刻線刀頭寬度幾乎能滿足這款艾比安的全部操作。由始至終都不需要替換其他刀頭。0.15mm確實是制作高達模型中常用的尺寸，建議各位常備。
如此一來，通過充分的零件打磨與加深刻線操作，我們便完成了這次MG艾比安的基礎修整工作。
那么接下來我們就準備開始對模型進行涂裝吧。
階段總結：
關于刻線的處理，其實我在之前的“阿斯莫德·上篇”中以及“大白鵝篇”中描述得會更多更具體。所以喜歡的話可以回頭去看看。
阿斯莫德·上篇：https://bbs.78dm.net/forum/post/819276.html
大白鵝篇：https://bbs.78dm.net/forum/post/754012.html
第四部分，郡士GX及SM系列金屬色涂裝展示。
考慮到這次的涂裝是以紅色+金色+黑色為主導配色風格，因此我特意準備了郡士GX202金屬紅、GX212金屬桃紅、SM207超級黃金色等涂料進行展示。而噴涂的設備為郡士PS289型0.3噴筆，這也是模型圈子里絕大部分人的選擇。
圈子里的人常言說，涂裝金屬色最好使用黑色作為底漆進行涂裝。事實真的如傳言那樣嗎？我來驗證一番。
在開始涂裝模型之前，我先準備了一些黑色以及白色的塑料勺子來模擬黑白兩種底色。我們先一起來對比下不同的底色對金屬色的影響吧。
這里先用郡士SM208超級鋁合金色作為示范。這個顏色跟銀色較為接近，以此作為銀色系的代表。
在黑底下涂裝時，顯色的金屬質感比白底的更為顯著，同時色澤也更為潔白。由此看來使用銀色系的涂料時，黑底確實具有更好的表現效果。
接著我們使用SM207超級金為示范，這也能作為金色系的標準代表了。
在黑底時涂裝此金色涂料，金色的光感更好，且金屬質感也更為明確。使用白底的話在金屬質感上有輕微的削弱情況。因此黑底對金色系涂裝有提高作用的結論也是成立的。
接著我們使用GX202金屬紅作為示范。這款金屬紅可以說是除金銀二色以外的金屬一般色的典型代表了。
在黑底涂裝時，金屬紅出現了發灰發暗的情況，金屬質感有輕微的提高但紅色的飽和度卻出現不足。而在白底時，涂層色調紅潤，飽和度更高顏色更為鮮艷，發色更為理想。看來金屬紅還是要使用白底為好。
最后我使用GX212金屬桃紅色做示范。這個顏色比金屬紅要淺，是介乎于金屬紅與銀之間的一種涂料。
圖片上可以看出，使用黑底時桃紅色缺飽和的情況更加明顯，涂層漆面出現了更為明顯的偏灰的情況。而在白底時，涂層顯色情況與涂料瓶蓋的示范色幾乎一致。由此看來白底確實更適合金屬桃紅色的發色。
關于金屬色的底色選擇總結：
其實嘛，金屬色的底色是需要根據想要的效果來做選擇的，不能以一概論來選擇黑色。
黑色的底色，更能激發金屬色的金屬質感，但卻會對彩色金屬色造成發灰發暗的情況。
白色的底色，更能還原彩色金屬色的色彩，但對金屬質感的表達提升不明顯。
以銀色為例，我們看待銀色首先就是金屬質感。因為銀色自身沒有彩色的色感，所以缺飽和的問題在銀色上并不能反映出來，甚至可能還會覺得適當的缺飽和，越是好。因此在銀色涂裝上確實是使用黑色的底色是最好的選擇。
以金色為例，使用白色做底色與黑色做底色，在實際中表達的差異性其實并沒有很顯著。如果模型作品最終是放在光線良好的攝影棚中拍攝，相信沒有人能看出白色底色與黑色底色的區別，這是大實話。但金色同樣是更為追求金屬質感的色種，因此我也是推薦各位使用黑色做底色。
以金屬紅/藍/綠為例。以黑色作為底色確實會更能激發金屬質感，但缺飽和的問題將會很嚴重，令顏色偏黑、發灰，效果強差人意。用白色作底色時，金屬紅/藍/綠（以下統稱金屬彩色系）的發色會更加鮮艷，飽和度更高，更能還原色彩本身應有效果。雖然金屬質感表達并不如銀色突出，但起碼最基本的飽和度和色澤得到保障。因此，我建議在使用金屬彩色系涂裝時，采用白色作為底漆。
由此可見，網絡上的網紅說：“黑色是金屬色唯一正確的底色選擇”的這個說法我是不認同的。我認為必須要根據實際環境以及作品的表達效果來選擇合適的底色。所以網紅的說法到底有多少是親身經驗？還是以訛傳訛得出來的謠言？請各位根據我上文的內容來自行判斷吧。
最后我再說一個小小的經驗。
由上個世紀90年代就開始做模型涂裝的鐵骨玩家圈子里，有對金屬色底漆的一個獨特理解：“銀色最好的底色是深灰色，光澤深德灰的那種。金色最好的底色是偏深的中性灰，不用太深像高達關節色那種就可以了。”
至于這個老一派的說法是真是假是不是符合各位的價值觀，就還得請各位去對比探究一下了。反正我是挺認同的。
接下來我們開始進行透明色涂裝。
我本次制作的艾比安，針對紅色部分是打算采用偽電鍍風格涂裝。因此透明紅是必須的。我選擇了郡士新推出的GX121透明紅涂料。而不同的金屬色底色上使用透明紅最終呈現的顏色差異是怎樣的？現在也我們來一探究竟。
首先，我以SM208超級鋁合金以及SM207超級金來作對比。這恰好也就是我們常見的銀底與金底之間的差異了。
在SM208超級鋁合金色為底漆（即銀系底色）的時候，透明紅覆蓋紅整體呈現出純正的深紅色外觀，紅色調較為深邃了。如果采用不銹鋼色這種深沉的銀色，電鍍紅會呈現更為醇厚的質感，非常適合深沉紅色為主的科幻模型制作。
在SM207超近金色為底漆（即金系底色）的時候，透明紅覆蓋后呈現出一定的橙色調。這是黃金色穿透透明紅后帶入的效果。輕微偏橙的電鍍紅色讓人感覺更為鮮艷，顏色層次更豐富且帶有火熱的感覺，個人覺得非常適合制作新安洲、沙扎比一類的機體。
然后，我再以GX202金屬紅與GX212金屬桃紅色來作對比。同樣是覆蓋涂裝GX121透明紅來展示效果。
使用GX202金屬紅作為底色制作的電鍍紅，呈色紅潤飽和度較高。金屬紅自身的紅色色彩對透明紅產生了一定的補正，色彩飽和度比金銀底色的更高，個人覺得十分好看。
使用GX212金屬桃紅色作為底色的效果與使用銀色時候的效果較為接近。
經對比，我個人覺得使用SM207超級金色以及GX202金屬紅做底色制作的兩種偽電鍍紅是最好看的。一個色澤鮮艷，一個飽和度極高。事實上使用金色作為底色制作電鍍紅的手法亦是圈子里絕大部分人的選擇。在這次制作中，我希望能做出與別不同的感覺，因此將使用GX202金屬紅作為底色。
關于透明色使用的階段總結：
透明色是一種特殊的色種，它與不透明的實色（以下簡稱做實色）的區別在于：透明色的色度會隨厚度的增加而增加，且沒有明確的飽和上限。
以一句文言文來比喻：“水清則淺，水綠則深，水墨則淵。”換句話說，透明色的厚度越大顏色越深。
因此，我們在涂裝透明色的時候一定要把握好漆面厚度，不然就會出現有深淺色差。
模型的零件會存在C面、夾角、凹陷等高低落差不同的位置，倘若涂裝手法不成熟，就很容易造型漆面厚度不一而導致的色差問題。當涂裝厚度過大的時候，透明漆可能出現邊緣積聚，而導致邊緣顏色深，中心顏色淺的情況。
同時，如果透明色覆蓋金屬色時厚度過大，就有可能會出現溶解金屬色（也就是返底現象），導致金屬色局部質感下降，令電鍍涂裝出現局部的質感缺陷。
由此我們可以得出透明色的使用注意事項：
1、注意漆面的厚度控制，防止出現厚度色差；
2、注意厚度控制，防止出現溶解底層金屬色。
所以說白了，透明色的涂裝就是要注意厚度控制。而要控制漆面厚度最有效的措施就是采用薄噴多層的技術了。請各位合理使用薄噴多層，不要盲目使用濕噴、厚噴、自流平等措施。
第五部分：模型涂裝制作。
考慮到GX202金屬紅在白色底漆時具有更高的發色效果。因此我使用了白色水補土來簡化制作。這里我選用了郡士的水性1000目水補土。這個水性水補土顆粒細膩，涂裝后能形成光滑平面，有助于提高漆面的平滑度。而且這款水性水補土的漆面韌性極強，可以減低剮蹭掉漆的風險。
隨后，我使用GX202金屬紅對零件進行統一涂裝。GX202金屬紅的覆蓋力在白底下非常理想，僅一層涂裝幾乎就能完全顯色。
然后我使用GX121透明紅進行涂裝。這里我使用了薄噴多層的操作要領進行制作，為的是控制透明漆的厚度。左邊零件為未涂裝GX121透明紅的金屬紅狀態，中間的零件為透明紅涂裝1層時的效果，右邊零件為GX121涂裝了兩層后的效果。
GX121透明紅在薄噴兩層時能達到完全顯色的效果。
在曲面零件上可以直觀看出，涂裝GX121透明紅后，零件的質感、色澤已經得到了飛躍性提高。在燈光下的效果已經可以達到偽電鍍的質感要求，且光潔度也非常理想。
套件中黑色的零件，我直接使用了GX02光澤黑進行涂裝。雖然看上去黑色已經非常純正了，但其實這還有這可以提高的空間。
對于提升黑色零件的涂裝質感，我同樣使用了GX121透明紅進行覆蓋涂裝。
圖中左側的零件組為單純使用GX02亮光黑色涂裝的效果。而右面的零件組為GX02亮光黑上覆蓋了GX121透明紅的效果。
可以非常直觀地看到，覆蓋了GX121透明紅以后，零件的飽和度得到了顯著提高。
倘若在光線良好的環境下，通過反光我們可以發現，在GX02亮光黑的基礎上覆蓋GX121透明紅的零件，其光感更好，表面更加光潔且反光質感帶有明顯的紅調。
這個覆蓋涂裝的操作能更進一步提升作品層次，豐富色澤，是一個實用性很強的技巧。
作品中金色的部分我直接使用了SM207超級黃金色來進行涂裝。個人認為黃金色、耀金色這些標準的金色搭配紅色使用效果非常理想。
MG套件的分件分色幾乎是完美的。但為了彰顯個人風格，我個人增加了不少分色的地方。因為是偽電鍍的涂裝，漆面比較嬌氣。以防在分色環節出現問題，我還是建議各位選擇可靠的遮蓋帶進行操作以防出現傷害漆面的情況。我在這里使用的是郡士的遮蓋帶，當然其實不同品牌的遮蓋帶效果都差不多，也可以用田宮或者鴨井的，大家按照自己的喜好來選擇吧。
反正，千萬不要用工業遮蓋帶就好了，容易損壞漆面。
在進行骨架涂裝前，我會先用遮蓋帶包裹主要關節的可動軸，防止漆面增加厚度而導致關節過緊。
骨架與關節位置的零件，我使用郡士GX201金屬鐵黑色進行涂裝。這個涂料的成色效果幾乎能滿足所有科幻模型對骨架的表達要求。
艾比安高達的大腿、上臂等位置是灰色的成型色，而我在這里主要使用了SM208超級鋁合金來表達。為了能有更貼近于原設定風格，我在SM208中額外添加了5%的GX201鐵黑色來令鋁合金色帶有一定的灰度。
多節鞭以及大劍等武裝零件，我在涂裝了SM208超級鋁合金色的基礎上，覆蓋涂裝了一層GX101透明黑，操作方法與紅色零件的偽電鍍涂裝完全一致。GX101透明黑更像是一種煙熏的透明色，能增加底下金屬色的暗度，但又不會影響金屬光彩。像這樣類似暗鋼色的效果也是不錯。
什么？你說看不見我對鞭子做無縫？說什么呢，無縫又不是本次的主題，這么麻煩的東西當然用愛無視啦。
如此一來，我們便完成了作品的基礎涂裝了。
第六部分：后期制作與細節優化
當完成了基礎涂裝以后，我們就需要對模型的細節位置進行優化處理。而面對難以遮蓋的細節我們可以采用面相筆手涂的形式來實現。
我在這里準備了一把郡士的“丸筆2號”型面相筆來進行筆涂補色操作的展示，使用的涂料為SM207超級黃金色。
首先搖勻涂料，然后打開瓶蓋后，以瓶蓋內的小碗為容器，使用面相筆蘸取涂料。
在使用SM系列金屬色手涂時，我會在不稀釋的情況下直接蘸取手涂。SM系列金屬色的涂料流動狀態良好，適合直接手涂使用。
然后直接以面相筆在需要補色的位置上輕畫就能完成細節補色，非常簡便。而且郡士的金屬色系列就算手涂也能有很好的效果，減免了大量繁瑣的遮蓋分色工序。
這是我第一次使用郡士的面相筆，不得不說這款面相筆的手感極好，甚至超出我的預期。
全鋼筆身的相當有分量感，筆身堅硬不易變形且外皮還有猛男粉的透明橡膠包裹。手感非常好也不容易打滑，拿在手上感覺棒極了。且筆頭的收束性極好，也很容易清洗干凈，值得推薦。
這樣一把讓我覺得手感極佳的面相筆，售價確實不算便宜。目前淘寶上也得要好幾十塊。而在相同的價格區間我們還能買到國產的，一包20~30支的廉價面相筆，可以實現用完即棄的土豪玩法。所以到底是選擇買一把好的面相筆重復使用？還是選擇以量取勝的便宜品？那就讓各位玩家自行決定了。
倘若你選擇了購買這把郡士的面相筆，我們在使用后必須要注意清洗與保養，不然就會產生損壞。清洗時可以使用藍標稀釋液泡洗蘸有涂料的筆頭數秒，然后來回晃動讓涂料充分溶解脫落。
隨即在紙巾上擦拭干凈就能完成清洗。
再次重申，不管面相筆性能再好，不注重清洗與保養，筆是用不持久的，因此我們必須要在每次使用后及時清洗。
套件的噴口細小，內部空間亦較小，使用面相筆手涂補色是合理的選擇。
這里我使用GX202金屬紅，以面相筆手涂制作。在使用GX系列金屬色手涂時，我會適當使用少量稀釋液，在1/0.5的比例下蘸取手涂。
當完成了補色操作后，我們就能對零件進行滲線操作。這里我使用WC01黑色滲線液。具體使用方法是使用面相筆蘸取隨即進行縫線的滲涂。在過往幾期均有描述，這里便不再重復贅述了。
因為本次作品是偽電鍍涂裝。在涂裝透明色時漆面已經非常非常光滑，所以滲線操作的壓力很低，而且也非常容易擦干凈。所以大家平常涂裝時需要注意涂裝漆面的平整度，方便后續的表面處理工序。
最后的表面處理，就是制作細節水貼了。這里準備了郡士藍蓋底膠型水貼軟化劑。我以紅色零件使用一般的市售水貼進行操作展示。
首先，我會使用藍蓋底膠型水貼軟化劑瓶蓋內部的刷頭，點加少量軟化劑在零件表面。
隨即將已經泡發好的水貼轉移到軟化劑之上。
等待約30秒作用，讓水貼充分軟化后，以棉簽吸收內部多余的軟化劑。
等軟化劑干透，便能完成水貼的制作了。使用了水貼軟化劑后，水貼圖案能更貼服地附著在零件表面，就算是起伏、轉角的位置也不容易出現水貼翹起的情況。這里使用的軟化劑為底膠型軟化劑，也能促進水貼更加牢固地粘貼在零件表面，不會輕易掉落，是水貼操作中必不可少的耗材。
最后，我們需要對模型零件涂裝透明保護漆。
因為是光澤面的模型，因此這次我選用的是郡士GX100光油。這款光油在模型制作圈子里被譽為是最好的硝基光油，沒有之一。光澤度、平整度都可圈可點，得到玩家群體的廣泛認可。
而近年來，圈子里面很多人開始流行使用氨基光油。據說氨基光油的效果更好而且漆面更堅固。但是處于身體安全的角度考慮，我還是老老實實地使用專用的模型漆吧。
GX100光油具有極好的填補能力，涂裝后，水貼與零件表面的高度落差幾乎被完全填補，看不出水貼的邊緣厚度。同時GX100的光澤感非常強，原本已經光潔的為電鍍紅涂層在其加持下有著更強的反光效果，已經達到了鏡面涂裝的程度。
GX100極好的填補能力，也能對透明件打磨后的輕微磨痕有著良好的修補效果。正因GX100極好的填補能力，以及出眾的光澤度，令它成為了圈子里玩家們的不二之選。
最后的最后，我們僅需將零件組合，便能完成本次模型的制作。
阿宅點評：大佬的教程是真的強，然后光黑之后上透明紅，這個真的挺新奇，以后要試下
者按：日前，《連線》雜志發表了一篇文章，詳細描述了Facebook早期發展的故事，內容摘錄自《天才谷：未刪減的硅谷歷史》（Valley of Genius：The Uncensored History of Silicon Valley）一書，這本書的作者為亞當·費舍爾（Adam Fisher），里面描述了硅谷各家主要科技公司的創業史，其中有很多不為人知的故事。
每個看過《社交網絡》（The Social Network）電影的人都知道Facebook成立的故事。那是2004年，哈佛大學的春季學期。然而，人們往往忘記的是，Facebook在劍橋市只有短短幾個月的時間。當時它叫做TheFacebook.com，是一款專門針對大學生的Friendster復制品。Friendster是一個位于硅谷的開創性社交網絡。
馬克·扎克伯格（Mark Zuckerberg）的山寨網站在校園里很受歡迎，所以他和幾個學校里的好友決定期末考試后搬到硅谷，在那里度過暑假，將Facebook推廣到全國的其他大學。硅谷是互聯網行動的發源地。他們大概就是這么想的。
在當時的硅谷，人們普遍認為互聯網淘金熱已經基本結束。地盤被搶走了，邊界已經確定了。互聯網贏了。見鬼，三年前，繁榮就已經破滅了。然而，沒有人會費心把備忘錄寄給馬克·扎克伯格——因為在那個時候，扎克只是個無名小卒：一個雄心勃勃的十幾歲大學生，癡迷于電腦地下組織。他對電腦了如指掌，但除此之外，他相當無知——當他還在哈佛的時候，總得有人向他解釋，Napster這樣的互聯網網站實際上是企業建立的。
但是扎克伯格可以黑進去，在那個決定命運的夏天，他遇到了硅谷的幾個關鍵人物，他們最終將徹底改變這家公司的方向。對于2004年和2005年這兩個關鍵月份的口述史，我采訪了所有的關鍵人物，并與其他一些有洞察力的人物交談。正如你將看到的，出現的是一幅關于企業原始文化的畫像，它將繼續影響著現在的Facebook。整個企業一開始就像一種玩笑，它不是一家企業，而是一個夏日“啤酒乒乓”和代碼沖刺的借口。事實上，扎克伯格的第一張名片上寫著:“我是CEO……賤人。”
2006年3月，扎克伯格在位于帕洛阿爾托的 Facebook 總部拍攝。 他的第一張名片上寫著“我是 CEO... 賤人。”圖片來源：ELENA DORFMAN/REDUX
肖恩·帕克（Sean Parker）( Napster的創始人之一，Facebook的首任總裁) ：互聯網時代以 Napster 結束，然后是互聯網泡沫破裂，這導致了社交媒體時代的到來。
史蒂文·約翰遜（Steven Johnson ）(著名作家和文化評論員) ：當時，網絡基本上是一種文學隱喻:“頁面”——然后是頁面之間的超文本鏈接。沒有用戶的概念；這根本不是隱喻的一部分。
馬克·平卡斯（Mark Pincus）(基礎社交媒體專利的共同所有者)：我把Napster看作為社交網絡的開端——專注人，而不是頁面。對我來說，這是一個突破性的時刻，因為我看到互聯網可以是一個完全分布式的對等網絡。我們可以繞開那些大的媒體公司，并且彼此聯系。
史蒂文·約翰遜：對我來說，這真的是從21世紀初寫博客開始的。你開始把這些網站聚焦在一個人的觀點上。它突然變得可以想象，哦，也許這里還有另外一個元素，網絡也可以組織起來？就像我信任這五個人一樣，我想了解他們的建議。早期的博客就是這樣的。
埃文·威廉姆斯（Ev Williams）( Blogger、Twitter和Medium的創始人)：當時博客鏈接很重，主要是關于互聯網的。“我們在網上寫關于互聯網的文章，然后鏈接到更多的互聯網，這不是很有趣嗎？”
史蒂文·約翰遜：你會把一大堆不同的聲音匯聚起來，這些聲音基本上都可以向你推薦鏈接，所以會有一個個人的過濾器。
馬克·平卡斯：2002年，雷德·霍夫曼（Reid Hoffman）和我開始了頭腦風暴：如果互聯網能像一場偉大的雞尾酒會，會是什么樣的呢？你可以帶著一些驚人的體驗離開，對吧？好的體驗是什么？好的體驗是工作、面試、約會的機會，以及公寓、房子、沙發等。
所以雷德和我開始說，“哇，這個人際網絡實際上可以產生比谷歌更有價值的東西，因為你在這個接受高度審查的社區里，彼此之間有一些相似之處，每個人都有自己出現在這里的理由，所以你會得到信任。”信噪比可能很高。我們稱之為Web 2.0，但沒人想聽，因為這是在消費互聯網的冬天。
肖恩·帕克：所以在2000年到2004年間，在Facebook出現之前，有一種感覺就像是互聯網上的一切都已經完成了。絕對的底部大概出現在2002年左右。PayPal在2002年上市，這是當年唯一一家進行IPO的消費互聯網公司。所以，有一個奇怪的過渡時期，總共只有六家公司得到了資金，或者類似的資助。Plaxo就是其中之一。Plaxo是一個原始的社交網絡。這是一種介于兩者之間的東西：一種有腿的怪魚。
亞倫·斯蒂格（Aaron Sittig）(發明 Facebook中“Like”的平面設計師) : Plaxo 是缺失的一環。 Plaxo是第一家真正成功的病毒式增長公司。 這時，我們才開始真正理解病毒式增長。
肖恩·帕克：我做過的最重要的事情是在 Plaxo 開發優化病毒性的算法。
亞倫·斯蒂格: 病毒式增長是指使用產品的人將產品傳播給其他人的時候——就是這樣。 人們不是因為喜歡而決定傳播產品。而是人們在使用產品做他們想做的事情的自然過程中，自然而然地將產品傳播給其他人。
肖恩·帕克：從最早的類社交網絡(可能是Napster )到Plaxo (它有點像一個社交網絡，但具有許多社交網絡的特征)，再到LinkedIn、MySpace和Friendster，再到Facebook這個現代化的社交網絡，發生了很大的演變。
埃茲拉·卡拉漢（Ezra Callahan）( Facebook第一批員工之一)：在21世紀初，Friendster獲得了所有早期用戶，擁有一個非常密集的網絡，有很多活動，然后就達到了這個臨界點。
亞倫·斯蒂格：當時正在進行一場非常大的競賽，Friendster真的起飛了，看起來Friendster真的發明了一種叫做“社交網絡”的新東西，他們是贏家，明顯的贏家。現在還不完全清楚到底發生了什么，但是這個網站的發展開始變得越來越慢，在某個時候它就處于停滯狀態了。
埃茲拉·卡拉漢：這為 MySpace 打開了大門。
埃文·威廉姆斯：MySpace 在當時可是個“大人物”。
肖恩·帕克：那是一個復雜的時期。MySpace很快就從Friendster手中接管了世界。他們抓住了接力棒。所以Friendster在衰落，MySpace在上升。
斯科特·馬萊特（Scott Marlette）(在Facebook上增加照片標簽的程序員) : MySpace非常受歡迎，但后來MySpace在擴展上也遇到了問題。
亞倫·斯蒂格：然后，Facebook在2004年2月推出，幾乎無人問津，也沒有引發太多談論。
達斯汀·莫斯科維茨（Dustin Moskovitz）(扎克伯格的左膀右臂)：當時有一個非常普遍的問題，現在看來很微不足道。根本不可能想到一個人的名字，去查他們的照片。哈佛大學的所有宿舍都有一本名為face books的個人目錄——有些是印刷的，有些是在線的，大部分只提供給那個特定宿舍的學生。所以我們決定在網上創建一個統一的版本，我們稱之為“Facebook”，以區別于那個版本。
扎克伯格與他的哈佛室友、達斯廷·莫斯科維茨、中心共同創建了 Facebook。 2004年，肖恩·帕克以總裁身份加入了公司。 這個三人組照片于2005年5月在公司的帕洛阿爾托辦公室拍攝。圖片來源：JIM WILSON/NEW YORK TIMES/REDUX
馬克·扎克伯格（Mark Zuckerberg）(Facebook 的創始人和現任首席執行官) : 幾周之內，就有幾千人注冊了。 我們開始收到其他大學的人發來的電子郵件，要求我們在他們的學校發布。
埃茲拉·卡拉漢：Facebook最初是在常春藤聯盟推出的，并不是因為他們是傲慢自大的孩子，只想把東西交給常青藤聯盟。而是因為他們有這種直覺，上常春藤盟校的人更有可能和其他常春藤盟校的學生成為朋友。
亞倫·斯蒂格: Facebook在伯克利推出時，把社交規則完全改變了。當我在伯克利的時候，你會發現，聚會就是你花了整整一周的時間和人們交談，想知道什么是有趣的，然后你必須不斷地與他們保持聯系。有了 Facebook，知道周末發生了什么是微不足道的。一切都是為你準備的。
Facebook早在2004年3月就來到了硅谷中心的斯坦福大學校園。
肖恩·帕克: 我在波托拉瓦利的室友都要去斯坦福。
埃茲拉·卡拉漢：我2003年我從斯坦福大學畢業，當時我和我的四個大學朋友在校園附近租了一所房子，我們有一間額外的臥室，所以我們在斯坦福大學的幾份電子郵件列表上做了廣告，找一個室友和我們一起搬進那所房子。我們得到了一個叫肖恩·帕克的人的回復。他最終非常隨意地和我們住在一起，我們發現，雖然Napster成了一種文化現象，但并沒有給他帶來任何收入。
肖恩·帕克：我的一個室友的女朋友在使用一種產品，我就想，“你知道，它看起來很像Friendster或者MySpace。”她說，“哦，是的，但大學里沒有人使用MySpace。”MySpace有點粗糙。
馬克·扎克伯格：MySpace有將近三分之一的員工都在監控上傳的色情圖片。我們幾乎沒有在這方面花費過多少力氣。原因是人們在Facebook上使用真名。
亞當·達安熱洛（Adam D’Angelo）(扎克伯格高中時的黑客好友)：真名真的很重要。
亞倫·斯蒂格：我們很早就明白了這一點，因為在Well上，社區原則已經確立了：你為你說的話負責。我們把它帶得比Well還遠。我們總是讓一切都可以追溯到一個特定的真人。
斯圖爾特·布蘭德（Stewart Brand） (第一個重要的社交網站Well的創始人) ：Well本來可以走這條路，但我們沒有。這是我們犯的錯誤之一。
馬克·扎克伯格：我認為，對于一個可能非常復雜的技術問題來說，這是一個非常簡單的社會解決方案。
埃茲拉·卡拉漢：在早期，它是一個相當黑客化的簡單網站：只是基本的網頁表單，Facebook個人資料就是這樣的。
魯奇·桑哈維（Ruchi Sanghvi）(創建Facebook Newsfeed的程序員) :有一張小的個人資料照片，上面寫著“這是我的個人資料”和“看看我的朋友”，下面有三四個鏈接和一到兩個其他的框。
亞倫·斯蒂格：但我對他們產品的專注和清晰度印象深刻。一些小細節——比如當你去查看你的個人資料時，它非常清楚地說，“這就是你”，因為當時的社交網絡非常非常難以理解。所以，這款產品有一種成熟性，在產品問世幾年并得到改進之前，你通常不會看到這種成熟性。
肖恩·帕克：我看到了這個東西，我給Facebook上的一些電子郵件地址發了郵件，我基本上說，“我和Friendster合作了一段時間，我只是想見見你們，看看是否有什么可以談的。”然后，我們在紐約開了個會——我不知道為什么會在紐約——剛開始的時候，馬克和我只是討論產品設計和我認為產品需要什么。
亞倫·斯蒂格：我接到肖恩·帕克的電話，他說:“嘿，我在紐約。我剛剛遇到了一個非常聰明的孩子馬克·扎克伯格，他就是那個創建Facebook的家伙，他們說他們有一個“秘密功能”即將推出，將改變一切！但他不肯告訴我是什么。我快瘋了。我不知道是什么。你知道這件事嗎？你能想出來嗎？你覺得會是什么？”所以我們花了一點時間談論它，我們無法真正弄清楚他們將會改變一切的“秘密功能”到底是什么。我們有點沉迷于此。
在和肖恩·帕克見面兩個月后，馬克·扎克伯格搬到硅谷，打算把宿舍項目變成一項真正的事業。陪同他的還有他的共同創始人兼顧問達斯汀·莫斯科維茨和幾名實習生。
馬克·扎克伯格：帕洛阿爾托是一個神話般的地方，所有的技術都來自那里。 所以我想去看看。
魯奇·桑哈維：當我聽到Facebook搬到海灣地區時，我很驚訝，我以為他們還在哈佛的宿舍里工作。
在 Facebook 早期，扎克伯格招募了哈佛大學的同學克里斯·休斯，幫助對這項初創的服務提出建議。 兩人于2004年5月在艾略特宮拍攝。圖片來源： RICK FRIEDMAN/GETTY IMAGES
埃茲拉·卡拉漢：2004年夏天，一系列重大事件發生了：肖恩在街上偶遇Facebook聯合創始人的傳奇故事，在幾個月前他在東海岸遇見了他們。那次會面發生在我們都搬出一直住在一起的房子一周后。肖恩和他女朋友的父母在一起。
肖恩·帕克：當時，我在屋外散步，有一群孩子朝我走來——他們都穿著連帽衫，看起來很可能是剛剛出去鬧事的吸大麻的高中生，我聽到了我的名字。我想，哦，這是巧合，我再次聽到我的名字，就像是，“肖恩，你在這里做什么？”然后，我轉過身來。
我花了大約30秒的時間才弄清楚到底發生了什么，我終于意識到這是馬克和達斯汀以及其他一些人。 所以我就說“你們來這兒干嘛?”他們說,“我們就住在那里。”我就說“這真奇怪，我也住在這里!”這真是太奇怪了。
亞倫·斯蒂格：我接到肖恩的電話，他告訴我，“嘿，你不會相信剛剛發生的事情。肖恩說：“你得過來見見這些人。馬上過來。過來見見他們！”
肖恩·帕克：我甚至不知道從那里發生了什么，這甚至不是一種特別正式的關系。
亞倫·斯蒂格：于是我過去和他們見面，我對他們作為一個團隊的專注度印象深刻。 他們偶爾會放松一下，做自己的事情，但是大部分時間他們都是坐在餐桌旁，開著筆記本電腦。 我會每周去他們那里幾次，那里總是我能找到他們的地方，只是坐在餐桌旁，不停地工作，以保持他們的產品不斷增長。
馬克想做的就是，要么把產品做得更好，要么休息一下，放松一下，這樣你就能有足夠的精力去做更多的產品。就這樣。他們除了去看電影，從來沒有離開過那所房子。
埃茲拉·卡拉漢：早期的公司文化非常非常松散。感覺就像一個失控的項目，有著驚人的商業潛力。想象一下你的新生宿舍經營著一家企業，就是那種感覺。
馬克·扎克伯格：大多數企業都不會像這樣：一群孩子，住在房子里，做他們想做的事情，不在正常時間醒來，不進辦公室，雇人，比如把他們帶進你的房子，讓他們和你一起放松一下，和你一起聚會，和你一起抽煙。
埃茲拉·卡拉漢：客廳是辦公室，到處都有顯示器和工作站，眼睛能看到的地方，都是白板。
當時馬克·扎克伯格癡迷于文件共享，在硅谷暑假的宏偉計劃是讓Napster起死回生。它會再次崛起，但這一次是Facebook內部的一個功能。它的名字是Wirehog。
亞倫·斯蒂格：Wirehog就是馬克所說的要改變一切的秘密功能。馬克已經確信，Facebook之所以能真正受歡迎，并鞏固其在學校的地位，是因為它是一種向他人發送文件的方式——主要是為了交換音樂。
馬克·平卡斯：他們內置了一個看起來像Napster的小東西——你可以看到別人在電腦上有什么音樂文件。
埃茲拉·卡拉漢：就在這個時候，我們目睹了Napster被法庭完全禁止，娛樂業開始起訴隨意分享文件的人。互聯網狂野西部的時代明顯結束了。
亞倫·斯蒂格：記住，Wirehog是在Facebook頁面上無法分享照片的時候發生的，這一點很重要。Wirehog將成為與他人分享照片的解決方案。你可以在你的個人資料上放一個框，人們可以去那里訪問你分享的所有照片——或者你分享的任何文件。它可能是音頻文件，可能是視頻文件，也可能是他們度假的照片。
埃茲拉·卡拉漢：但歸根結底，這只是一種文件共享服務。當我加入Facebook的時候，大多數人已經開始意識到，除非Wirehog有一些我們沒有想到的新用途，否則這只是一種負擔。“我們總有一天會被起訴，那又有什么意義呢？”這就是我們的心態。
馬克·平克斯：我有點奇怪為什么肖恩還想再次接近音樂。
亞倫·斯蒂格：我的理解是，Facebook的一些律師認為這是一個壞主意。就在Facebook用戶增長非常迅速的時候，這項關于 Wirehog 的工作就被放棄了。
埃茲拉·卡拉漢：它們（各種大學）瘋狂地要求加入。現在還只有一百所學校，但是在全國所有的學校，大學里的每個人都已經聽說過了。使用數量已經瘋了。白板上的一切都是與學校下一步要推出什么東西有關。這個問題非常獨特。簡單地說，“我們如何擴大規模？"
亞倫·斯蒂格: Facebook 在一所學校發布，一天之內，就會有70% 的本科生注冊。 當時，沒有什么產品能像 Facebook 那樣快速發展。
埃茲拉·卡拉漢：我們要成功似乎并不是不可避免的，但成功的范圍看起來越來越清晰。達斯汀已經在談論成為一家10億美元的公司。他們從一開始就有這個雄心。他們非常自信：兩個還是19歲的趾高氣揚的孩子。
馬克·扎克伯格：有一天，我們只是坐在一起，說:“我們不會回學校了，不是嗎？”
埃茲拉·卡拉漢：這種傲慢看上去很了不起。
大衛·崔（David Choe）(著名涂鴉藝術家)：肖恩是個瘦弱的書呆子，他說:“我要去為Facebook籌款。我要改變這些混蛋的想法。”我說，“你打算怎么做？”他把自己變成了一個“阿爾法”男性。他的發型真TM的超級鋒利。他開始每天鍛煉，曬黑了，穿了一套漂亮的西裝。他參加了這些會議，拿到了錢！
馬克·平卡斯：大概是2004年9月或10月，我在Tribe位于波特雷羅山塵土飛揚的磚房里的辦公室——Tribe.net的想法就像Friendster加上Craigslist——我們在會議室，肖恩說他要把Facebook的人帶進來。他把扎克帶進來，扎克穿著一條運動褲，穿著阿迪達斯的人字拖，他看起來很年輕，坐在那里，雙腳放在桌子上，肖恩正在飛快地談論Facebook將要做的和關于增長的所有事情以及其他一切，我被迷住了。
因為我在做Tribe，我們沒有成功，我們已經停滯不前了，我們正在碰壁，試圖找出如何增長，這是一個孩子，他有一個簡單的想法，他剛剛起飛！我已經對他們的成就感到敬畏，也許還有點惱火。因為他們做了一些更簡單、更快、更少的事情，然后我記得肖恩在我辦公室的電腦上打開了Facebook，他開始向我展示它，而我不能夠在它上面注冊，因為只有大學生才能用，太神奇了。
人們把他們的電話號碼和家庭地址，以及關于他們自己的一切都放上去了，我簡直不敢相信！但那是因為他們得到了這種信任。然后肖恩迅速組織了一輪投資，他建議扎克，我想，從彼得·蒂爾那里拿50萬美元，然后從我和雷德·霍夫曼那里各拿3.8萬美元。因為我們基本上是唯一一個在社交網絡上做任何事情的人。那是一個非常非常小的俱樂部。
埃茲拉·卡拉漢：到了12月，這種氣氛——我不會說這是一種更專業的氣氛，但是馬克和達斯汀一起工作的所有孩子要么回到學校，要么回到斯坦福，工作對他們來說變得更加嚴肅了。他們比第一個夏天工作得多。我們要到2005年2月才搬進辦公室。就在我們簽租約的時候，肖恩胡亂地開始說:“老兄！我認識一個街頭藝術家。讓他進去把事情（裝飾）都做完。”
大衛·崔：我當時說,“如果你想讓我把整棟大樓都粉刷一遍，那就是6萬美元。” 肖恩說:“你要現金還是要股票?”
埃茲拉·卡拉漢：他用Facebook的股票支付了大衛·崔裝修的費用。
大衛·崔：我根本不在乎 Facebook，甚至不知道它是什么。 你必須要有大學郵箱才能進去。 但我喜歡賭博，你知道嗎？ 我相信肖恩。 我就想，這孩子知道些什么，我要把我的錢押在他身上。
埃茲拉·卡拉漢：然后我們就搬了進去，當你第一次看到這個涂鴉時，就會說，“天哪，這個家伙對辦公室做了什么？”辦公室在二樓，所以當你走進來的時候，你必須馬上走上樓梯，而在面對你的10英尺高的大墻上，你看到的只是一個胸部巨大的女人，穿著瘋狂的麥克斯風格的服裝，騎著一只斗牛犬。
這是最嚇人、完全不合適的東西。“該死的，肖恩！你做了什么？”與其說這是一幅畫，還不如說那是文化。更重要的是肖恩這么做了，這為我們定下了基調。當你走進辦公室的時候，第一件看到的就是一個騎著斗牛犬的大胸女戰士，所以，要做好準備！
魯奇·桑哈維：是的，這個涂鴉有點不雅，但是它是不同的，它是充滿活力的，它是活的。 這種能量非常明顯。
凱蒂·杰明德（Katie Geminder）( Facebook早期項目經理)：我喜歡它，它給人的感覺很強烈。里面有一些非常性感的畫面，我并不在意，但是這可能被認為有點敵意，我想我們已經處理了一些更具挑釁性的畫面。
埃茲拉·卡拉漢：我不認為是大衛·崔干的，我認為是肖恩的女朋友，她在女廁所里描繪了兩個完全赤裸的女人糾纏在一起，露骨而親密的女同性戀場景。這肯定比一個人通常在一個辦公室的女廁所里看到的更具暗示性。實際上，這只持續了幾個星期。
麥克斯·凱利（Max Kelly）(Facebook 的第一位網絡安全官) : 有一幅4英寸 × 4英寸的圖畫，上面畫著某人被干了。 一位客服人員抱怨說，這是“性本質”，考慮到他們每天看到的情況，我不知道他們為什么要抱怨這個。 但是我最終還是去了當地的一家商店，買了一支金色的畫筆，在涂鴉上涂鴉——只是一個隨意的設計ーー這樣就不會顯示有人被干了。
杰夫·羅斯柴爾德（Jeff Rothschild）(投資者變成Facebook員工)：這很瘋狂，但我覺得很酷。它看起來更像大學宿舍或兄弟會，而不是一個公司。
凱蒂·杰明德：角落里塞著毯子，到處都是電子游戲，還有 Nerf 玩具和樂高玩具，有點亂七八糟。
杰夫·羅斯柴爾德：有一個PlayStation。有幾張舊沙發。很明顯，有人睡在那里。
卡雷爾·巴隆（Karel Baloun）(Facebook 最早的程序員之一) ：我每周可能會在那里呆上兩三個晚上。 我在一次員工集會上贏得了“最有可能在桌子下面發現你的”獎。
杰夫·羅斯柴爾德：他們有一個酒吧，一整個架子上都是酒，一天下來人們可能會喝一杯。
埃茲拉·卡拉漢：辦公室里有很多酒。 總有這樣的早晨，我走進辦公室，聽到啤酒罐在我打開門的時候移動，辦公室里散發著陳釀啤酒的味道，就像一個垃圾桶。
魯奇·桑哈維：他們有桶裝啤酒。 啤酒桶上面有一些攝像技術。 它基本上能檢測到人的存在，并發布誰在桶前的消息，所以當你在啤酒桶前的時候，它會拍下你的照片，然后貼上一些東西，上面寫著“某某人在桶前”，這個小桶是有專利的。
埃茲拉·卡拉漢：我們剛搬進來的時候，辦公室的門上有一把我們搞不清楚的鎖，但是每天早上9點門就會自動打開。 我必須在9點之前到達辦公室，確保沒有人走進來偷走所有東西，因為沒有人會在中午之前到達那里。 Facebook的員工基本上都是夜間活動的。
凱蒂·杰明德：這些孩子會進來——我說孩子，意思是他們真的是孩子——他們11歲或者12歲就開始工作了。
魯奇·桑哈維：有時候我會穿著睡衣去上班，那是完全沒問題的。 這感覺就像是大學生活的延伸; 我們所有人都在同一時間經歷著相同的生活經歷。 工作太棒了。 真是太有趣了。 感覺不像是在工作。我們一直都很開心。
埃茲拉·卡拉漢：你們一起在外面閑逛。你和你的同事喝酒。人們開始在辦公室約會…
魯奇·桑哈維: 我們在 Facebook 發現了我們的重要人物。 我們所有人最終都結婚了。 現在我們正處在有孩子的階段。
凱蒂·杰明德：如果你看看最初幾年在 Facebook 工作的成年人——比如，30歲以上的已婚人士——你做一項調查，我告訴你，他們中75 %的人可能離婚了。
麥克斯·凱利：那么午餐就要開始了。我們的午餐承辦人精神不平衡，你永遠不知道TM的食物里會出現什么鬼東西。有一次魚里有蟲子。太可怕了。通常，我會工作到下午3點左右，然后在辦公室里轉一圈，看看那天晚上到底會發生什么。誰要發布什么？誰準備好了？有什么傳言？發生什么事了？
史蒂夫·帕爾曼（Steve Perlman）(硅谷老兵，雅達利時代開始)：我們和Facebook共用一個休息室。我們正在建造硬件：面部捕捉技術。Facebook的人在做一些HTML的事情。他們一大早就來了。他們會有一頓午餐供應。然后他們通常在中午前離開。我想，伙計，這就是生活！我需要這樣的創業。你知道嗎？我們每個人對Facebook唯一能想到的就是：人真好，但哪兒也不去。
麥克斯·凱利：大約4點左右，我會和我的團隊開會，說“我們今晚會被搞得一團糟。”然后我們去酒吧。大約5到8個人一起，分別去大學大街上不同的酒吧，吃晚飯，什么的。
魯奇·桑哈維：我們會坐在一起進行這些智力對話:“假設，如果這個網絡是一個圖表，你如何衡量兩人之間的關系？你如何衡量一個人和一張照片之間的關系？那是什么樣子？這個網絡最終會是什么樣子？如果我們真的擁有這個網絡，我們該怎么辦？”
肖恩·帕克：“社交圖譜”是圖論中的一個數學概念，但它是一種試圖向那些有點學術和數學傾向的人解釋我們正在構建的不是一個產品，而是一個由節點組成的網絡，節點之間有大量信息流動。這就是圖論。所以我們正在構建一個社交圖譜。它從來沒有被公開談論過。這是一種向有數學背景的人表達我們正在建造的東西的方式。
魯奇·桑哈維：回想起來，我真不敢相信我們當時還有這樣的對話。 這似乎是一件很成熟的事情。 我們會坐在一起進行這些對話，他們并不局限于團隊中的某些成員; 沒有任何明確的結果。它純粹是知識性的，對每個人都開放。
麥克斯·凱利：人們一直都在喝酒，就像要玩一整晚一樣，但是從9點左右開始，氣氛就開始凝固了:“今晚我們要發布什么？誰準備好了？誰還沒準備好？”大約11點左右，我們就知道那天晚上我們要做什么了。
凱蒂·杰明德：沒有一個過程是令人振奮的。會有工程師在潛心研究他們熱愛的事情。然后他們會在半夜把它發布出來。沒有測試——他們只是把它發布出去。
埃茲拉·卡拉漢：大多數網站都有這些非常強大的測試平臺，以便測試變化。我們不是這樣做的。
魯奇·桑哈維：只要按下一個按鈕，你就可以把代碼推上去，因為我們真正相信“快速移動，打破常規”的理念。所以你不應該一周等一次，也不應該一天等一次。如果你的代碼已經準備好了，你應該能夠將它實時推出給用戶。這顯然是一場噩夢。
凱蒂·杰明德：我們的服務器能經得起考驗嗎？或者安全性：測試安全漏洞的功能如何？真的就只是把它發布到外面，看看會發生什么。
杰夫·羅斯柴爾德：這就是黑客的心態：你只要完成它。當你有10個人的時候，效果很好。到了20個、30個、40個人的時候，我花了很多時間來保持網站的正常運行。所以我們必須培養某種程度的紀律。
魯奇·桑哈維：那么我們只能在半夜推出代碼，因為如果我們弄壞了東西，不會影響那么多人。但這很可怕，因為我們每天晚上都要熬夜到凌晨3、4點左右，因為這種推搡行為只會讓每個寫了任何代碼的人都在場，以防發生任何事情。
麥克斯·凱利：凌晨1點左右，我們就會知道要么我們完蛋了，要么我們很好。如果我們做得好，每個人都會像“whoopee”一樣，也許能睡一會兒。如果我們被搞砸了，然后我們會說，“好吧，現在我們得試著把這個東西回滾回來或者修復它。”
凱蒂·杰明德：凌晨2點：那就是狗屎發生的時候。
魯奇·桑哈維：然后再來一次，這種情況會一直持續到凌晨3、4或5點。
麥克斯·凱利：如果凌晨4點左右，我們無法修復它，我會說，“我們將嘗試恢復它。”這意味著基本上我的團隊會一直工作到早上6點，在4到6點之間睡覺，然后每天重復，持續了大概9個月。太瘋狂了。
杰夫·羅斯柴爾德：一周工作七天。我一直都在。睡覺前我會喝一大杯水，保證兩個小時后醒來，這樣我就可以去檢查所有的東西，確保我們沒有把它搞砸。這是一整天，一整夜。
凱蒂·杰明德：對于一個想要和丈夫這樣的成年人一起生活的人來說，這是一個很大的挑戰。肯定有一種感覺，因為你年紀大了，結婚了，有一種工作之外的生活，而這些都是你沒法保證的。
馬克·扎克伯格：為什么大多數象棋大師都在30歲以下？年輕人的生活比較簡單。我們可能沒有汽車。我們可能沒有家人……我只有一張床墊。
凱特·杰明德：想象一下，30歲以上的人聽到你的老板這么說會是什么感受。
馬克·扎克伯格：年輕人只是更聰明。
魯奇·桑哈維：那時候我們還很年輕。 我們確實有大量的能量，我們可以做到這一點，但我們不一定是最有效率的團隊。 對于高層領導來說，這絕對是令人沮喪的，因為很多談話都發生在他們不在的時候，第二天早上他們就會處在變化中。 但是我們做的時候還是很有趣的。
埃茲拉·卡拉漢：對于最初的幾百名員工來說，幾乎所有人都已經是公司工作人員的朋友，包括工程師和用戶支持人員。這里有很多剛畢業的學生。當我們搬進辦公室的時候，宿舍文化開始真正突出，也開始有一點點破裂。它有宿舍的感覺，但并不是完全由大學生主導。大人開始進來了。
杰夫·羅斯柴爾德：我是2005年5月加入的。辦公室外的人行道上是比薩店的菜單。那是一幅漫畫，畫的是一位廚師，下面有一張需要招募人員的工作清單。
肖恩·帕克：當時谷歌非常有吸引力。所有偉大的工程師都要去谷歌。
凱特·羅斯（Kate Losse）(早期客戶服務代表)：我不認為我能夠在谷歌工作。 對我來說，Facebook 看起來比谷歌酷多了，并不是因為 Facebook 是最酷的。 只是那時的谷歌似乎已經顯得乏味無趣了，而像 在Facebook工作的人，其實并不想變成書呆子。 Facebook是一個社交網絡，所以它必須有一些社交成分，就像正常的美國社交活動——比如啤酒乒乓。
凱特·杰明德：在街對面的辦公室里有一棟房子，五六個工程師住在那里，那是一個正在舉行的啤酒乒乓派對。這就像一個男孩俱樂部——盡管不僅僅是男孩。
特里·維諾格拉德（Terry Winograd）(著名的斯坦福大學計算機科學教授)：我認為Facebook更像是一種本科生文化，而谷歌更像是研究生文化。
杰夫·羅斯柴爾德：在我走進Facebook的大門之前，我以為這些家伙已經創建了一個約會網站。大概過了一兩個星期，我才真正明白是怎么回事。馬克，他曾經告訴我們，我們不是一個社交網絡。他會堅持說:“這不是一個社交網絡。我們是對你真正認識的人有用的社交工具。”
MySpace是在有相似興趣的人中間建立一個在線社區。我們看起來可能是一樣的，因為在某種程度上它的形狀是一樣的，但是它為個人所做的是解決一個不同的問題。我們正在努力提高朋友之間的交流效率。
麥克斯·凱利：馬克和我坐在一起，向我描述了他在Facebook上看到的一切。他說:“這關系到人與人之間的聯系，建立一個系統，在這個系統中，凡是與你的生活有任何價值的人，只要你希望它被保存下來，就會被保存下來。不管你在哪里，和誰在一起，也不管你的生活如何改變：因為你總是和對你來說最重要的人聯系在一起，你總是能夠和他們分享。”
我聽到了，我想參與其中。我想讓這一切發生。早在90年代，我們所有人都對互聯網抱有烏托邦的想法。這幾乎讓人回想起美麗的互聯網，在那里，每個人都可以連接在一起，每個人都可以分享，這樣做沒有任何阻礙。Facebook在我看來也是一樣。馬克還太年輕，不知道當時的情況，但我認為他從本質上理解了80年代和90年代互聯網應該是什么樣子。而在這里，我又聽到了同樣的故事，可以想象，我有能力幫助它成功。這很有吸引力。
亞倫·斯蒂格：所以在2005年夏天，馬克讓我們大家坐下來，他說:“今年夏天我們要做五件事。”他說，“我們正在重新設計網站。我們正在做一個叫做News Feed的事情，它將告訴你，你的朋友在網站上做的一切。我們將推出照片功能，我們將重做 Parties 并將其轉化為 Events，我們要做一個本地企業產品。”我們完成了其中一項工作，重新設計了網站。照片是我的下一個項目。
埃茲拉·卡拉漢：Facebook當時的產品非常簡單：個人資料。沒有News Feed，消息傳遞系統非常薄弱。他們有一個非常簡單的活動產品，你可以用它來組織聚會。幾乎沒有其他功能可言。網站上沒有照片，只有你的個人資料照片。沒有任何東西能告訴你網站上的任何東西是什么時候改變的。你會發現有人改變了他們的個人資料圖片，才會去注意他們的個人資料，并注意到，哦，照片變了。
亞倫·斯蒂格：有一些人每小時換一次個人資料照片，只是為了分享他們自己的照片。
斯科特·馬萊特：當時照片是最受歡迎的功能。于是，亞倫和我走進一個房間，在白板上為一些網頁添加一些線框圖，決定需要存儲什么數據。在一個月內，我們做出了一個在內部基本上可以完全運作的原型。很簡單：你發布一張照片，它會進入一個相冊，然后你會有一套相冊，而且你可以在照片中標記人物。
杰夫·羅斯柴爾德：亞倫有做標記的洞察力，這是一個非常有價值的洞察力。這真的改變了游戲規則。
亞倫·斯蒂格：我們認為，最重要的是要說照片中的人是誰。我們不確定這是否真的會那么成功；我們只是感覺這很好。
Facebook Photos于2005年10月上線。大約有500萬用戶，幾乎都是大學生。
斯科特·馬萊特：我們首先在哈佛和斯坦福推出，因為我們的朋友都在那里。
扎克伯格從小在紐約州的多布斯渡口長大，他的父母愛德華和凱倫以及他的姐妹蘭迪，左，阿瑞爾一起撫養長大。圖片來源：SHERRY TESLER/NEW YORK TIMES/REDUX
亞倫·斯蒂格：我們制作了這個程序，它會填滿一個電視屏幕，向我們展示上傳到服務器上的所有東西，然后我們打開它，等待照片的出現。第一批進來的照片是Windows壁紙：有人剛剛從Windows目錄上傳了他們所有的壁紙文件，這讓人很失望，也許人們不明白？也許這樣不行？
但接下來的照片是一個男人和他的朋友出去玩，然后接下來的照片是一群不同的女孩：三個女孩在一起，這四個女孩在一起，其中兩個在一起，不過是她們在聚會上玩的照片，然后就沒有停下來。
麥克斯·凱利：你參加了每一場婚禮，參加了每一個成年禮，看到了這些令人敬畏的東西，然后還有一個XX。所以，這是一個同時具有令人敬畏和糟糕的感覺的時刻。
亞倫·斯蒂格：在第一天，有人上傳了700張照片，并在上面做了標記，然后就從那里起飛了。
杰夫·羅斯柴爾德：三個月內，我們傳送的照片比互聯網上任何其他網站都多。現在你不得不問自己：為什么？答案就是標記。沒有人能收到一封電子郵件，上面寫著“有人把你的照片上傳到互聯網上”——而不去看一看。這是人類的本性。
埃茲拉·卡拉漢：有史以來唯一最大的增長機制是照片標記。它決定了所有其他的產品決策。這是人們使用Facebook的方式第一次發生了真正的根本性變化，Facebook的心態發生了變化，News Feed的理念開始萌芽。現在，有理由看到這種變化會如何擴展到大學之外。
杰夫·羅斯柴爾德：News Feed項目于2005年秋季啟動，2006年秋季交付。
達斯汀·莫斯科維茨：News Feed 是病毒式傳播概念的化身。
埃茲拉·卡拉漢：News Feed就是今天 Facebook 的基礎。
肖恩·帕克：最初，它被稱為“What’s New”，它只是網絡中正在發生的所有事情的反饋——實際上只是一系列正在發生的狀態更新和個人資料的更新。
凱蒂·杰明德：這是一個集合，是所有這些故事的集合，其中包含一些邏輯，因為我們無法向你展示正在發生的一切。有兩種流：你正在做的事情和你的網絡其他部分正在做的事情。
埃茲拉·卡拉漢:所以News Feed是第一次，現在你的主頁不再是靜態的、無聊的和無用的，而是不斷更新的“報紙”，可以說，是Facebook上發生的我們認為你會關心的事情。
魯奇·桑哈維: 這是一個很有意思的想法，因為通常當你想到報紙時，他們會有一些編輯化的內容，他們決定他們想說什么，他們想要印刷什么，他們在前一個晚上這樣做，然后他們把這些文章發給成千上萬的人。 但就 Facebook 而言，我們正在建立一千萬種不同的報紙，因為每個人都有一個個性化的版本。
埃茲拉·卡拉漢：這確實是第一次具有里程碑意義的產品工程壯舉。它必須處理很大的數據量：所有這些變化以及如何在個人層面上傳播這些變化。
魯奇·桑哈維：我們一年半來一直在不停地研究這個問題。
埃茲拉·卡拉漢：……然后是所有這些東西的智力方面：我們如何把你最關心的東西傳遞出來？從工程角度來看，這些都是非常棘手的問題。
魯奇·桑哈維：在沒有意識到這一點，我們最終在軟件中建立了一個最大的分布式系統。 這是相當前衛的。
埃茲拉·卡拉漢：我們內部有它，我們使用了好幾個星期——這真的很不尋常。
凱蒂·杰明德：我記得當時我在想想，“好吧，你們這些家伙，我們得做一些用戶研究。”最后我說服扎克，我們應該把用戶帶到實驗室，坐在玻璃后面，看著我們的用戶使用產品。我花了很大的力氣才讓達斯汀、扎克和其他人去觀看。他們認為這是浪費時間。他們說:“不，我們的用戶很笨。”
埃茲拉·卡拉漢：這是我們第一次真正帶外界人士來為我們測試東西，他們的反應，他們的初步反應是清楚的。人們就像，“我靠，我不應該看到這些，好像這感覺不對，”因為你馬上看到這個人改變了他們的個人形象，這個人做了這個，這個人做了那個，你的第一反應是，哦，我的上帝！每個人都可以看到我！每個人都知道我在Facebook上做的一切。
麥克斯·凱利：但是News Feed對我們所有人來說都是非常有意義的，在內部，我們都很喜歡它。
埃茲拉·卡拉漢：所以在內部我們有這樣一個想法，認為這是不正確的：這是一個太不和諧的變化，它需要慢慢推廣，我們需要讓人們對此保持熱情——但馬克卻很堅定。“我們就這樣做。我們就要發布了。就像撕掉創可貼一樣。”
魯奇·桑哈維: 我們在夜深人靜的時候推出了這個產品，我們真的很興奮，我們在慶祝。 我寫了這樣一篇博客文章:“Facebook換了一個新面貌。”
凱蒂·杰明德：我們寫了一封小信，在信的底部放了一個按鈕。按鈕說:“太棒了！”不是說，“好吧。”而是“太棒了！”那太無禮了。我希望我有一個截圖。哦天啊！就這樣。你登陸Facebook，你就有了這個功能。我們沒有給你選擇，也沒有很好的解釋，這讓人們感到害怕。
杰夫·羅斯柴爾德：人們驚慌失措，因為它似乎暴露了以前從未見過的信息。事實上并非如此。News Feed中顯示的所有內容都是人們放在網站上的東西，如果他們去訪問了那個個人資料，每個人都會看到。
魯奇·桑哈維: 用戶們很反感。 他們威脅要抵制這種產品。 他們覺得自己被侵犯了，他們的隱私受到了侵犯。 有學生在組織請愿書。 人們在辦公室外排隊等候。 我們雇了一個保安。
凱蒂·杰明德：外面有攝影師。 有人抗議說：“把舊的 Facebook 帶回來!” 每個人都討厭它。
杰夫·羅斯柴爾德：反應非常激烈。 有人在辦公室里游行。 有人在Facebook 上組織了抗議News Feed的群組，不到兩天，就有一百萬人加入。
魯奇·桑哈維：還有一個關于“魯奇是魔鬼”的群組，因為我寫了那篇博客文章。
麥克斯·凱利: 用戶群體每一步都在與之爭斗，他們會對我們施加壓力，會對客戶服務施壓，然后說：“這真是一團糟！ 這太可怕了!”
埃茲拉·卡拉漢：我們收到親友的電子郵件。他們說，“你做了什么？太可怕了！換回來。”
凱蒂·杰明德：我們坐在辦公室里，抗議活動在外面進行，“我們要把它回滾回去嗎？我們要把它回滾回去嗎！？”
魯奇·桑哈維：在通常情況下，如果大約10 %的用戶開始抵制該產品，你會關閉它。但是我們看到了一個非常不尋常的模式。
麥克斯·凱利：即使是那些告訴我們這很可怕的人，我們也會看著他們的用戶流，然后說：你TM在不斷地使用它！你在說什么？
魯奇·桑哈維：盡管有這些反抗，這些請愿和人們在辦公室外排起了長隊，但他們還是在使用產品。他們實際上在使用它，而且使用它的次數是News Feed前的兩倍。
埃茲拉·卡拉漢：這幾天對公司里的每個人來說都是一場情緒上的災難。尤其是那些揮舞著手臂說：“不要這樣！別這樣做的人！”因為他們覺得，“這就是我們告訴你會發生的事！”
魯奇·桑哈維：馬克在東海岸的第一次新聞發布會上，我們其他人都在帕洛阿爾托辦公室處理這個問題，看著這些日志，試圖傳達“這真的有用!”在我們選擇關閉它之前，先嘗試做一些事情。
凱蒂·杰明德：我們必須馬上推出一些隱私功能來平息風暴。
魯奇·桑哈維：我們要求每個人給我們24小時。
凱蒂·杰明德：我們用這些小滑條建立了這個簡潔的隱私“音頻混音器”，你可以在那里打開和關閉。它設計得很漂亮——看起來很漂亮——但它無關緊要。
杰夫·羅斯柴爾德：我想沒有人用過它。
埃茲拉·卡拉漢：但它被添加上去了，最終，即時反應消退了，人們意識到News Feed正是他們想要的，這個功能完全正確，這使得Facebook變得更加有用了一千倍。
凱蒂·杰明德：就像照片一樣，News Feed只是——轟！——這是產品的一個重大變化。
杰夫·羅斯柴爾德：使用量在News Feed 的發布上飛速上升。 大約在同一時間，我們也對那些沒有教育郵箱的人開放了網站。
埃茲拉·卡拉漢：一旦Facebook向公眾開放，它就變得越來越明顯，Facebook正在成為世界上所有人的目錄。
杰夫·羅斯柴爾德：這兩件事加在一起——就是Facebook成為一個被大規模使用的產品的轉折點。在此之前，我們只是被高中生和大學生使用的產品。
馬克·扎克伯格：統治！
魯奇·桑哈維：“統治”在當時是 Facebook 的一大口號。
麥克斯·凱利：我記得公司開會時，我們高喊“統治”。
埃茲拉·卡拉漢：我們一直都有公司聚會，2005年的一段時間里，馬克在公司聚會上的所有敬酒都以“統治”結束。
馬克·扎克伯格：統治！！
麥克斯·凱利：我們撕毀雅虎提議的那次會議，我記得特別清楚。
馬克·平卡斯：2006年，雅虎向 Facebook 提供了12億美元的收購提案，我認為是這樣的，當時這似乎是一個驚人的價格，很難想象他們不會接受。 每個人都看到了 Napster、Friendster以及MySpace 結局，所以，一個沒有收入的公司面臨著一個可靠的公司提供了12億美元的收入，你能夠對此說不嗎？ 你必須非常尊重那些拒絕這些提議的創始人。
達斯汀·莫斯科維茨：我確信如果雅虎收購我們，產品將遭受重大損失。 肖恩告訴我，90% 的合并都以失敗告終。
馬克 ·平卡斯：對于扎克來說，非常幸運，雅虎的股票下跌，他們說不會改變報價。 但他們說這個報價是固定數量的股票，所以這個出價降到了8億美元，我認為，扎克在情感上可能不想這么做，這讓他清醒了過來。 如果雅虎說：“沒問題，我們會用現金或股票支持這一報價，使其達到12億美元”，那么對于扎克來說，這可能不會太難，也許 Facebook 會成為雅虎的一個小分支。
麥克斯·凱利：我們真的撕毀了雅虎的協議，把它當作一個公司來踐踏！ 我們就像這樣,“去他們的，我們要收購他們!”那是惡意的胡說八道。
馬克·扎克伯格: 統治! ! ！
凱特·羅斯：他說話的方式有點諷刺。 這不是一個字面意義上的、可怕的“統治” ，這很有趣。 只有當你想到更大規模的事情時，你才會這樣想，嗯，人們是否意識到，他們之間的互動是由一群對世界如何運作和什么是好的想法的人所構建的嗎？
埃茲拉·卡拉漢：互聯網的發展方向，有多少是受到了19歲、20歲、21歲富有的白人男孩的視角影響？這是一個現實的問題，社會學家需要深入地研究。
凱特·羅斯：我認為大多數人并沒有真正考慮到現在幾個人的價值觀對每個人的影響。
史蒂文·約翰遜：關于這個問題，我認為存在一些合理的爭論。 Facebook確實造成了一些回音室問題和政治兩極化問題，但是我花了很多時間爭論，互聯網的責任要比人們想象的要少。
馬克·平卡斯：也許我太接近這一切了，但我認為當你把視角拉回來的時候，我們中沒有一個人真的那么重要。 我認為互聯網正在走一條通向互聯網想要去的道路。 我們都在試圖弄清楚消費者想要什么，如果人們想要的是這個巨大的回聲室和這個虛榮的、充滿點贊的世界，有人會把它給他們，他們會成為贏家，而那些不提供這些的人，不會成為贏家。
史蒂夫·喬布斯：除了 Facebook 之外，我沒有看到其他公司占據了統治地位。
馬克·平卡斯：我不認為一群大學男生塑造了互聯網。 我只是覺得他們先到達了那里。
馬克·扎克伯格: 統治！！！！
埃茲拉·卡拉漢：直到我們有了一個全職的顧問，他說：“馬克，看在上帝的份上: 你不能再用統治這個詞了,”他停了下來。
肖恩·帕克：一旦你占據統治地位，那么它就會突然變成一個反競爭的術語。
史蒂文·約翰遜: 互聯網用了30年才有了10億用戶。 Facebook 花了10年時間。 Facebook 的關鍵是它不是一個服務或者應用程序，它是一個基本的平臺，和互聯網本身的規模一樣。
史蒂夫·喬布斯: 我很欣賞馬克 · 扎克伯格。 我對他了解不多，但我欣賞他沒有出賣公司——因為他想要成立一家公司。 我很欣賞這一點。
書面語言和口頭語言有很大的不同。 因此，我冒昧地糾正了口誤，將意識流的想法分成了句子，將句子排序成段落，消除了冗余的部分。 這中間的關鍵是不要把原來的口頭語言變成書面語言，而是要把實際上的內容逐字記錄下來。
我小心翼翼地保留了所有為了這篇文章而采訪的每個人的語言節奏和語言風格，所以，你讀到的內容在你的腦海里是真實的：真實的生活，真實的文字記錄，真實的演講者的意圖。
這篇文章中發現的絕大多數詞語都來自于我的采訪。 在有些地方地方，我嘗試著去挖掘之前未發表的采訪，并引用他們的話。 在一些地方，我引用了之前發表過的采訪：
2005年，馬克·扎克伯格在哈佛大學計算機科學入門課上發表的演講，以及同年2月他接受哈佛克里姆森報的采訪； 達斯汀·莫斯科維茨2008年12月青年運動聯盟峰會的主題演講；大衛·柯克帕特里克(David Kirkpatrick)的著作《Facebook效應》(The Facebook Effect)；大衛 · 崔在2016年3月的霍華·史坦秀上發表的評論； 史蒂夫 · 喬布斯對他的傳記作者沃爾特 · 艾薩克森做出的評論，2011年喬布斯去世后不久，這個采訪就在《60 Minutes》欄目播出。
原文鏈接：https://www.wired.com/story/sex-beer-and-coding-inside-facebooks-wild-early-days/
編譯組出品。編輯：郝鵬程
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
