整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
.前言
關于javascript中的this對象，可能已經被大家說爛了。
即使是這樣，我依然決定將這篇文章給水出來。畢竟全國在新型肺炎的影響下，公司沒法正常復工。
除了刷刷手機，還是要適當的學習一下。
廢柴是真不好當，勞逸結合才是王道。
面試官：你能給我解釋一下javascript中的this嗎
我：（當然可以哇，胸有成竹，咳咳）javascript中的this對象是指函數 運行 時，在函數內部生成的一個對象。
面試官：那你大概說一下它的用法吧
我：（我覺得我需要開始吹水了）
我：好，我大概說幾種使用場景。（下面都是我一個人的戲）
比如下面這個全局函數test
<script>
function test(){
}
</script>（事實勝于雄辯，雖然不能給面試官看結果，但是氣勢上已經拿到一分）
除了作為普通函數使用之外， test全局函數也可以作為構造函數去使用，那么函數內部的this對象指向的是構造函數創建出來的實例 。
在test構造函數中，this.a=10這行是關鍵代碼。
假設我們在不知道this對象是什么的情況下，這行代碼僅僅是給this對象添加了一個屬性a，并且賦值為10 。
然后看測試結果打印出來的對象o，發現o也多了一個屬性a，它的值也為10 。
所以不難想到在test函數運行時，this綁定到了new出來的對象上，即this指向了構造函數創建出來的實例o；
第一種this的使用場景就吹完了，如果這樣啰嗦的回答面試官，估計就直接讓我回家了。
所以總結一下我這樣回答面試官：
在比如下面這個obj對象的increase方法。
var obj = {
a: 10,
increase: function(){
this.a++;
}
}現在我們去調用obj對象的increase方法
obj的increase方法中的關鍵代碼為this.a++，該函數調用完成后，在去打印obj對象，發現obj對象中a的屬性值由10增加為11。
那么increase方法這中的this.a++的效果實際上等效于obj.a++。
所以對于 第二種對象方法中的this，它指向的就是該對象本身。
那么到這里，我已經我的能力范圍內回答完了面試官的問題。
（如果幸運的話，面試官應該還不會趕我走）
面試官：說了這么多，那我這里有幾個實例代碼，你來給我分別說一下這幾個示例代碼輸出都是什么吧。
（接著面試官扔給我幾張寫滿了代碼的A4紙）。
我：（突然心慌慌，但是不能慫，按照前面說的幾種場景往里套唄）
（看到這個心情愉快呀，這不就是我剛說的this的第一種使用場景嗎。而且是將全局函數作為普通函數使用，那函數里的this指向的就是window。那既然函數f中的this指向的是window對象，那this.age就相當于window.age。然后我不慌不忙的回答面試官）
題目一按照代碼執行的輸出順序，第4行的輸出結果為20，第7行的輸出結果也是20（面試官不說話，應該是默認了我的回答是正確的）。
（這個乍一看跟題目一有些相似，只是在第3行中對age的定義有了變化，而且在第6行還多了一個打印輸出。
在往下看，發現函數f依然是作為普通函數去使用的，那既然是這樣，第3行的this.age=40也就相當于window.age=40。
所以第3行代碼執行的時候肯定會覆蓋第1行對age的賦值。到這里我微微一笑，開始回答面試官）
題目二按照代碼執行的輸出順序，第6行輸出結果為20；第4行當輸出結果為40；第8行當輸出結果為40。
（這個題目一看還是我前面說的this的第一種使用場景，只是全局函數作為普通函數使用）
題目三按照代碼執行的輸出順序，第5行輸出20；第8行輸出20。
（額，這個代碼有點長呀，但是不能慌。
看完前8行覺得沒啥問題，第9、10行看完后心里咯噔了一下。
將obj的getName方法賦值給了一個變量fn，然后打印fn()？？？
靜下心想一想，第9行實際上是以聲明式方式創建了一個全局函數fn，然后在第10行調用fn。
接著我陷入了沉思，那調用fn時，這個this到底是指向obj對象呢，還是指向全局的window對象。
大腦飛速旋轉，想到剛開始對面試官說的那句話：javascript中的this對象是 函數運行時 ，在函數內部生成的一個對象。
于是我不斷的重復這句話，然后一個激靈反應上來，既然是this是函數運行時生成的，那我應該關注fn函數運行時的情況呀。
先拋開函數fn是由obj的getName方法賦值生成的這個事情。
fn生成以后，它是一個全局函數，這個毋庸置疑。再者，fn運行時是以普通函數的方式調用的。
那fn函數在運行時，內部的this對象就是window了，那第10行打印就是全局的"babi"了，恩，一定是這樣。
擦擦汗在繼續看，又發現了16行的代碼，感覺和第10行代碼有些異曲同工之處。
接著前面的思路往里套，不管otherObj.getName是怎么創建的，它在運行的時候是作為otherObj對象的方法運行的，那這就符合前面說的第二種使用this的場景：對象方法中的this，它指向的就是該對象本身。
想完這些抬頭看了一下面試官，一言不發甚至有些不耐煩，于是虛虛的回答他）
題目四按照代碼執行的輸出順序，第10 行的輸出結果為"babi"；第17行的輸出結果為"mini"。
（此時看到面試官眉頭舒展，微微一笑）
面試官：好，那這個問題到此結束......
面試官的靈魂拷問結束后，回到家里把記得的示例代碼都驗證了一遍，竟然發現都對了。
于是默默的獎勵自己一個雞腿。
聲明：文章中場景純屬捏造，切勿當真。小小總結，歡迎拍磚。
原文 http://www.cnblogs.com/HouJiao/p/12252885.html
喜歡小編的可以點個贊關注小編哦，小編每天都會給大家分享文章。
我自己是一名從事了多年的前端老程序員，小編為大家準備了新出的前端編程學習資料，免費分享給大家！
如果你也想學習前端，可以觀看【置頂】文章。也可以私信【1】 領取最新前端練手實戰項目
前一節中我們借助于 Chrome devtools 實現了對線上 Node.js 應用的 CPU/Memory 問題的排查定位，但是在實際生產實踐中，大家會發現 Chrome devtools 更加偏向本地開發模式，因為顯然 Chrome devtools 不會負責去生成分析問題所需要的 Dump 文件，這意味著開發者還得額外在線上項目中設置好 v8-profiler 和 heapdump 這樣的工具，并且通過額外實現的服務來能夠去對線上運行的項目進行實時的狀態導出。
加上實際上預備章中除了 CPU/Memory 的問題，我們還會遇到一些需要分析錯誤日志、磁盤和核心轉儲文件等才能定位問題的狀況，因此在這些場景下，僅僅靠 Chrome devtools 顯然會有一些力不從心。正是為了解決廣大 Node.js 開發者的這些痛點，我們在這里推薦大家在使用 Node.js 性能平臺，即原來的 AliNode，它已經在阿里巴巴集團內部承載了幾乎所有的 Node.js 應用線上運行監控和問題排查，因此大家可以放心在生產環境部署使用。
本節將從 Node.js 性能平臺 的設計架構、核心能力以及最佳實踐等角度，幫助開發者更好地使用這一工具來解決前面提到的異常指標分析和線上 Node.js 應用故障定位。
本書首發在 Github，倉庫地址：https://github.com/aliyun-node/Node.js-Troubleshooting-Guide，云棲社區會同步更新。
Node.js 性能平臺其實簡單的說由三部分組成：云控制臺 + AliNode runtime + Agenthub，如下圖所示：
具體的部署步驟可以查看官方文檔：自助式部署 Runtime。借助于 Node.js 性能平臺的整套解決方案，我們可以很方便地實現預備章節中提到的絕大部分異常指標的告警分析的能力。在生產實踐過程中，實際上在筆者看來，Node.js 性能平臺解決方案其實僅僅是提供了三個最核心卻也是最有效的能力：
換言之，Node.js 性能平臺作為一個產品本身功能也在不斷迭代新增修改中，但是以上的三個核心能力一定是第一優先級保障的，其它邊邊角角的功能則相對來說響應優先級沒有那么高。
實際上我們也理解作為使用平臺的開發者希望能在一個地方看到 Node.js 線上應用從底層到業務層的所有細節，然而我個人感覺不同的工具都有應該有其核心的能力輸出，很多時候不斷做加法容易讓產品本身定位模糊化以及泛而不精，Node.js 性能平臺實際上始終在致力于讓原本線上黑盒的運行時狀態，能更加直觀地反饋給開發者，讓 Node.js 應用的開發者面對一些偏向底層的線上疑難雜癥能夠不再無所適從。
I. 配置合適的告警
線上應用的告警實際上是一種自我發現問題的保護機制，如果沒有告警能力，那每次都會等到問題暴露到用戶側導致其反饋才能發現問題，這顯然對用戶體驗非常的不友好。
因此部署完成一個項目后，開發者首先需要去配置合適的告警，而在我們的生產實踐中，線上問題通過錯誤日志、Node.js 進程 CPU/Memory 的分析、核心轉儲（Core dump）的分析以及磁盤分析能夠得出結論，因此我們需要的基本的告警策略也是源自以上五個部分。幸運的是平臺已經給我們預設好了這些告警，大家只需要選擇一下即可完整這里的告警配置，如下圖所示：
在 Node.js 性能平臺 的告警頁面上有 快速添加規則，點開選中后會自動生成告警規則的閾值表達式模板和報警說明模板，我們可以按照項目實際監控需求進行修改，比如想要對 Node.js 進程的堆內存進行監控，可以選中 Memory 預警 選項，如下圖所示：
此時點擊 添加報警項 即完整了對進程堆內存的告警，并且將出現告警時需要點擊 通知設置->添加到聯系人列表 來添加的聯系人加入此條規則，如下圖所示：
那么在例子中的這條默認的規則里，當我們的 Node.js 進程分配的堆內存超過堆上線的 80%（默認 64 位機器上堆上限是 1.4G）時會觸發短信通知到配置綁定到此條規則的聯系人。
實際上快速添加規則列表中給大家提供的是最常見的一些預配置好的告警策略，如果這些尚不能滿足你的需求，更多定制化的自定義的服務告警策略配置方法可以看官方文檔 報警設置。并且除了短信告警，也支持釘釘機器人推送告警消息到群，方便群發感知線上 Node.js 應用態勢。
II. 按照告警類型進行分析
按照 I 節中配置完成合適的告警規則后，那么當收到告警短信時就可以按照策略類型進行對應的分析了。本節將按照預備節中比較常見的五大類問題來逐一講解。
a. 磁盤監控
這個是比較好處理的問題，在快速添加的規則里實際上我們會在服務器的磁盤使用超過 85% 時進行告警，那么收到磁盤告警后，可以連接到服務器，使用如下命令查看那個目錄占用比較高：
sudo du -h --max-depth=1 /
找到占比比較高的目錄和文件后，看看是否需要備份后刪除來釋放出磁盤空間。
b. 錯誤日志
收到特定的錯誤日志告警后，只需要去對應的項目的 Node.js 性能平臺 控制臺找到問題 實例 去查看其 異常日志 即可，如下圖所示：
這里會按照錯誤類型進行規整，大家可以結合展示的錯誤棧信息來進行對應的問題定位。注意這里的錯誤日志文件需要你在部署 Agenthub 的時候寫入配置文件，詳細可以參見文檔 配置和啟動 Agenthub 一節中的 詳細配置 內容。
c. 進程 CPU 高
終于到了前一節中借助 v8-profiler 導出 CPU Profile 文件再使用 Chrome devtools 進行分析的異常類型了。那么在 Node.js 性能平臺 的整套解決方案下，我們并不需要額外的去依賴類似 v8-profiler 這樣的第三方庫來實現進程狀態的導出，與此相對的，當我們收到 Node.js 應用進程的 CPU 超過我們設置的閾值告警時，我們只需要在控制臺對應的 實例 點擊 CPU Profile 按鈕即可：
默認會給抓取的進程生成 3 分鐘的 CPU Profile 文件，等到結束后生成的文件會顯示在 文件 頁面：
此時點擊 轉儲 即可上傳到云端以供在線分析展示了，如下圖所示：
這里可以看到有兩個 分析 按鈕，其實第二個下標帶有 (devtools) 的分析按鈕實際上就是前一節中提到的 Chrome devtools 分析，這里不再重復講解了，如果有遺忘的同學可以再去回顧下本大章前一節的內容。我們重點看下第一個 AliNode 定制的分析，點擊第一個分析按鈕后，可以在新頁面看到如下所示內容：
這里其實也是火焰圖，但與 Chrome devtools 提供的火焰圖不一樣的地方在于，這里是將抓取的 3 分鐘內的 JS 函數執行進行了聚合展示出來的火焰圖，在一些存在多次執行同一個函數（可能每次執行非常短）的情況下，聚合后的火焰圖可以很方便的幫助我們找到代碼的執行瓶頸來進行對應的優化。
值得一提的是，如果你使用的 AliNode runtime 版本在 v3.11.4 或者 v4.2.1 以上（包含這兩個版本）的話，當你的應用出現類死循環問題，比如由于異常的用戶參數導致的正則回溯（即執行完這個正則要十幾年，類似于 Node.js 進程發生了死循環）這類問題時，可以通過抓取 CPU Profile 文件來很方便地定位到問題代碼，詳細信息有興趣的同學可以看下 Node.js 性能平臺支持死循環和正則攻擊定位。
d. 內存泄漏
與 CPU 高的問題一樣，當我們收到 Node.js 應用進程的堆內存占據堆上限的比率超過我們設置的閾值時，我們也不需要類似 heapdump 這樣的第三方模塊來導出堆快照進行分析，我們還是在控制臺對應的 實例 點擊 堆快照 按鈕即可生成對應 Node.js 進程的堆快照：
生成的堆快照文件同樣會顯示在 文件 列表頁面，點擊 轉儲 將堆快照上傳至云端以供接下來的分析：
與上面一樣，下標帶有 (devtools) 的分析按鈕還是前一節中提到的 Chrome devtools 分析，這里還是著重解析下 AliNode 定制的第一個分析按鈕，點擊后新頁面如下圖所示：
首先解釋下上面的總覽欄目的內容信息：
這部分的信息旨在給大家一個概覽，部分信息需要深入解讀堆快照才能徹底理解，如果你實在無法理解其中的幾個概覽指標信息，其實也無傷大雅，因為這并不影響我們定位問題代碼。
簡單了解了概覽信息的含義后，接著我們來看對于定位 Node.js 應用代碼段非常重要的信息，第一個是默認展示的 可疑點 信息，上圖中的內容表示 @15249 這個對象占據了堆空間 97.41% 的內存，那么它很可能就是一個泄漏對象，這里又存在兩種可能：
要判斷是哪一種情況，以及追蹤到對應的代碼段，我們需要點擊圖中的 簇視圖 鏈接進行進一步觀察：
這里繼續解釋下什么是簇視圖，簇視圖實際上是支配樹的一個別名，也就是這個視圖下我們看到的正是前面一節中提到的從可疑泄漏對象出發的支配樹視圖，它的好處是，在這個視圖下，父節點的 Retained Size 可以直接由其子節點的 Retained Size 累加后再加上父節點自身的 Shallow Size 得到，換言之，在這個視圖下我們層層展開即可以看到可疑泄漏對象的內存究竟被哪些子節點占用了。
并且結合前一節的支配樹描述，我們可以知道支配樹下的父子節點關系，并不一定是真正的堆上空間內的對象父子關系，但是對于那些支配樹下父子關系在真正的堆空間內也存在父子節點關系的簇節點，我們將真正的 邊 也用淺紫色標識出來，這部分的 邊 信息對于我們映射到真正的代碼段非常有幫助。在這個簡單的例子中，我們可以很清晰的看到可疑泄漏對象 @15249 實際上是下屬的 test-alinode.js 中存在一個 array 變量，其中存儲了四個 45.78 兆的數組導致的問題，這樣就找到了問題代碼可以進行后續優化。
而在實際生產環境的堆快照分析下，很多情況下簇視圖下的父子關系在真實的堆空間中并不存在，那么就不會有這些紫色的邊信息展示，這時候我們想要知道可疑泄漏對象如何通過 JavaScript 生成的對象間引用關系引用到后面真正占據掉堆空間的對象（比如上圖中的 40 多兆的 Array 對象），我們可以點擊 可疑節點自身的地址鏈接 ：
這樣就進入到以此對象為起點的堆空間內真正的對象引用關系視圖 Search 視圖：
這個視圖因為反映的是堆空間內各個 Heap Object 之間真正的引用連接關系，因此父對象的 Retained Size 并不能直接由子節點的 Retained Size 累加獲取，如上圖紅框內的內容，顯然這里的三個子節點 Retained Size 累加已經超過 100%，這也是 Search 視圖和簇視圖很大的不同點。借助于 Search 視圖，我們可以根據其內反映出來的對象和邊之間的關系來定位可疑泄漏對象具體是在我們的 JavaScript 代碼中的哪一部分生成。
其實看到這邊，一些讀者應該意識到了這里的 Search 視圖實際上對應的就是前一節中提到的 Chrome devtools 的 Containment 視圖，只不過這里的起始點是我們選中的對象本身罷了。
最后就是需要提一下 Retainers 視圖，它和前一節中提到的 Chrome devtools 中解析堆快照展示結果里面的 Retainers 含義是一致的，它表示對象的父引用關系鏈，我們可以來看下：
這里 globa@1279 對象的 clearImmediate 屬性指向 timers.js()@15325，而 timers.js()@15325 的 context 屬性指向了可疑的泄漏對象 system / Context@15249。
在絕大部分的情況下，通過結合 Search 視圖 和 Retainers 視圖 我們可以定位到指定對象在 JavaScript 代碼中的生成位置，而 簇視圖 下我們又可以比較方便的知道堆空間被哪些對象占據掉了，那么綜合這兩部分的信息，我們就可以實現對線上內存泄漏的問題進行分析和代碼定位了。
e. 出現核心轉儲
最后就是收到服務器生成核心轉儲文件（Core dump 文件）的告警了，這表示我們的進程已經出現了預期之外的 Crash，如果你的 Agenthub 配置正常的話，在 文件 -> Coredump 文件 頁面會自動將生成的核心轉儲文件信息展示出來：
和之前的步驟類似，我們想要看到服務端分析和結果展示，首先需要將服務器上生成的核心轉儲文件轉儲到云端，但是與之前的 CPU Profile 和堆快照的轉儲不一樣的地方在于，核心轉儲文件的分析需要我們提供對應 Node.js 進程的啟動執行文件，即 AliNode runtime 文件，這里簡化處理為只需要設置 Runtime 版本即可：
點擊 設置 runtime 版本 即可進行設置，格式為 alinode-v{x}.{y}.{z} 的形式，比如 alinode-v3.11.5，版本會進行校驗，請務必填寫你的應用真實在使用的 AliNode runtime 版本。版本填寫完成后，我們就可以點擊 轉儲 按鈕進行文件轉儲到云端的操作了：
顯然對于核心轉儲文件來說，Chrome devtools 是沒有提供解析功能的，所以這里只有一個 AliNode 定制的分析按鈕，點擊這個 分析 按鈕，即可以看到結果：
這里第一欄的概覽信息看文字描述就能理解其含義，所以這里就不再多做解釋了，我們來看下比較重要的默認視圖 BackTrace 信息視圖，此視圖下展示的實際上是 Node.js 應用在 Crash 時刻的線程信息，許多開發者認為 Node.js 是單線程的運行模型，其實這句話也不是完全錯誤，更準確的說法是 單主 JavaScript 工作線程，因為實際上 Node.js 還會開啟一些后臺線程來處理諸如 GC 里的部分任務。
絕大部分的情況下，應用的 Crash 都是由 JavaScript 工作線程引發的，因此我們需要關注的也僅僅是這個線程，這里顯然 BackTrace 信息視圖中將 JavaScript 工作線程做了標紅和置頂處理，展開后可以看到 Node.js 應用 Crash 那一刻的錯誤堆棧信息：
因為就算在 JavaScript 的工作線程中，也會存在 Native C/C++ 代碼的穿透，但是在問題排查中我們往往只需要去看同樣標紅的 JavaScript 棧信息即可，像在這個簡單的例子中，顯然 Crash 是因為視圖去啟動一個不存在的 JS 文件導致的。
值得一提的是，核心轉儲文件的分析功能非常的強大，因為在預備節中我們提到其生成的途徑除了 Node.js 應用 Crash 的時候由系統內核控制輸出外，還可以由 gcore 這樣的命令手動強制輸出，而本小節我們又看到核心轉儲文件的分析實際上可以看到此刻的 JavaScript 棧信息以及其入參，結合這兩點，我們可以在線上出現 CPU Profile 一節中提到的類死循環問題時直接采用 gcore 生成核心轉儲文件，然后上傳至平臺云端進行分析，這樣不僅可以看到我們的 Node.js 應用是阻塞在哪一行的 JavaScript 代碼，甚至引發阻塞的參數我們也能完整獲取到，這對本地復現定位問題的幫助無疑是無比巨大的。
本節其實給大家介紹了 Node.js 性能平臺 的整套面向 Node.js 應用開發的監控、告警、分析和定位問題的解決方案的架構和最佳實踐，希望能讓大家對平臺的能力和如何更好地結合自身項目進行使用有一個整體的理解。
限于篇幅，最佳實踐中的 CPU Profile、堆快照和核心轉儲文件的分析例子都非常的簡單，這部分的內容也更多的是旨在幫助大家理解平臺提供的工具如何使用以及其分析結果展示的指標含義，那么本書的第三節中，我們會通過一些實際的生產遇到的案例問題借助于 Node.js 性能平臺 提供的上述工具分析過程，來幫助大家更好的理解這部分信息，也希望大家在讀完這些內容后能有所收獲，能對 Node.js 應用在生產中的使用更有信心。
作者：奕鈞
于如何運營一個社區，本文作者總結了一個“七步運營”的方法，七個環節分別為：熟悉產品——競品分析——社區氛圍與種子用戶——拉新與促活——留存與轉化——老用戶召回——站好最后一班崗。
首先給大家分享一個案例，大約在2014年初的時候，我曾經接手過一個地方門戶網站的家居論壇。這是一個縣區級城市的地方門戶網站，當地的常住人口在百萬左右，城區人口30萬左右，該門戶網站在當地做得十分成功，屬于當地的強勢門戶，日瀏覽量超過46萬次，日獨立IP1.5萬左右。這個網站的家居版塊一直沒有做起來，數據不溫不火，在上一任運營離開后，基本瀕死。
2月底我接手時，因為上一任運營人員已離職近一個月，論壇基本上一直處于無人管理的狀態，UV不到200，PV不到500。論壇里基本沒有什么用戶發言，更不要說有優質的內容了，滿屏都是各種亂七八糟的廣告貼，以及SEO們發的外鏈貼，整個論壇基本癱瘓。我花了4個月的時間，將論壇的各項基本功能恢復，訪問量上升到UV1500，PV過萬。
首先我花了一兩個星期左右來熟悉論壇以及整個門戶的各方面情況，然后對這個社區論壇存在的問題做出了一個初步判斷：由于運營的斷層，家居論壇人氣很低，但是仍有用戶在關注；論壇的基本體制還是健全的，只是缺乏管理。于是，我通過下面的運營方法和手段，逐步地將這個論壇挽救了過來。
社區里的廣告帖、外鏈帖等垃圾帖，對于論壇整體環境的危害是母庸置疑的。充斥著廣告、外鏈的版面，是很難吸引到用戶的。就好像一個小區里，遍地都是垃圾的話，還會有人愿意來住嘛？所以，我首先做的是將社區打掃干凈，這樣才好招徠八方游客。
刪帖的工作，一般論壇都會有防水墻自動處理，但還是會有一些帖子會成為漏網之魚，需要人工操作刪帖。這個工作我從剛開始接手論壇一直做到離開前，不僅僅是刪除每天新出現的垃圾帖，因為強迫癥的緣故還在空閑的時候將之前的舊帖篩選出來刪除掉，這大概是一個社區論壇運營管理人員最基本的工作了吧，像百度貼吧的運營總監就曾經說過，百度貼吧每天要刪除近200萬的垃圾帖，可謂是運營不息，刪帖不止。
在社區論壇的環境打掃干凈之后，我就開始著手內容的運營，首先用到了社區運營里最常用的手段：用馬甲以用戶的身份發帖。這種方法在新社區運營初期時最為常用，運營工作人員不僅要做發帖的樓主，制造有爭議性的話題，還需要用馬甲來自己為自己喝彩鼓掌，精分成好幾個不同立場的用戶發起討論。要說明的是，這里用馬甲的目的只是生產一些內容，活躍論壇的氣氛，并不會涉及惡意造假的行為。
大部分人都是愛看熱鬧的，就像生活中如果有人在吵架的話，很快就會有一大群不明真相的群眾來圍觀。而表現在網絡上時，就是我們都愛看“吵架”帖，吵得越厲害越好，嗯，“前排兜售瓜子板凳，強勢圍觀”。所以，在社區運營時，有爭議性的話題是一直需求的，如果能有一些知名人士、意見領袖來參與，那就更好了，更容易引爆氛圍，吸引大量用戶。
大約是在3月初的時候，經理和負責招商的主管一起策劃了一場大型的線下團購活動，我開始做線上的活動預熱。
當時采取的都是一些比較常規的動作，比如發活動預熱帖、活動主題報名帖、話題炒作帖等，同時還通過利用公司內部的資源，申請了總站首頁和論壇主板置頂的一些政策。
我當時對這樣的做法持保留意見，在我看來，在社區論壇剛剛做好第一步和第二步的時候，就開展大型的線下活動，有些操之過急的感覺，覺得應該在開展線上活動和線下小活動之后，一方面到時候論壇有一定的氛圍人氣，另一方面有之前的資源和經驗積累，舉辦大型活動時也更駕輕就熟一些。不過，這次線下活動的實際效果還是非常好的，也成為了家居論壇成長的一個轉折點。之后我一直在考慮，有可能是我過于保守，在社區人氣不夠的情況下，通過大型活動來吸引人氣，也是一種值得一行的策略。
在大型線下活動的預熱征集帖上線后不久，在經理的指導下，我們又開始策劃線下常規活動作為補充，一方面繼續拉新，一方面為大活動造勢。
在我看來，社區運營中常規型的線上線下活動，有助于讓用戶對社區的黏度大大提高，同時可以形成一定的品牌效應，有助于用戶記住社區的亮點，利于傳播。
3·15前后，我們的大型線下活動落地并取得了不錯的效果，參與用戶的數量和轉化率讓大老板和參與的商家都十分滿意。由于這篇是討論關于社區運營方面的工作，就不在這里細說了。
活動舉辦后，我提出對參與活動的用戶進行跟蹤報道。本來比較理想的情況是用戶在參加活動后自發的進行內容產出，然而由于之前家居論壇的基礎運營不夠，用戶自發發帖的主動性仍不高，另一方面是參與活動的用戶群體并不是預期中的8090后的年輕人，而是40歲以上的年齡偏大的群體，對于論壇發帖不是很熟悉。因此為了吸引用戶，只能自己去做采編工作，回來后以第三人稱視角去描述裝修過程。
對于社區中的用戶來說，他們很容易產生如同在現實社區中生活的心理，因此會在很多時候表現的像現實生活中一樣非常關心鄰居家的雞毛蒜皮的小事，關注他人的故事，所以如同裝修論壇里的裝修日記、親子社區里的寶媽日記、旅游社區里的游記等等這樣的內容，雖然常常內容非常簡單，文案配圖也不夠專業，但是卻能吸引眾多的用戶點擊互動。所以我在用戶還無法做內容產出時，代為做這些內容產出。
4月前后，公司領導在與一個地方兄弟站學習交流后，對論壇的整合型內容輸出加大了要求，于是我們在運營時投入了相當一部分精力來做各種大的裝修攻略，整合各種裝修知識帖。
與碎片化的內容相比，整合型內容（大型攻略帖、集合帖）具有較高的整體性，同時對文案編輯的要求較高，因而一般情況下是沒有用戶來做這個的，但是這些干貨內容是支持社區的內容骨架，就像主食一樣，味淡卻又不可缺失。
由于這個論壇之前有運營一段時間，雖然接手前流失了很多用戶，但是我還是從之前的帖子中找到了一些由于論壇冷清而離開的意見領袖，一個個與他們進行溝通交流，召回了一部分。同時，在論壇中尋找一些積極份子，培養他們成為新一批的意見領袖、發帖達人。這一部分人，在之后都貢獻了許多優質的內容，同時也在日常發帖中帶動了論壇氣氛，在線下活動中也為我們提供了非常多的助力。
做社區的時候，有一批人是繞不開的，那就是意見領袖，意見領袖對社區的重要性眾所周知，因而社區運營人員需要和他們保持良好的關系，成為朋友。
畢竟是地方上的家居論壇，與本土商家聯系很緊密，自身盈利的需求使得我們無法避免的要為商家做宣傳。同時商家本身也有在論壇中發言的需求和意愿，因此如何避免商家在社區中盲目的發布廣告帖，成為了我們面臨的一個問題。
我們采取的做法是堵不如疏，與其陷入“商家發廣告帖——我們刪帖——商家向我們抱怨”的怪圈，不如對商家進行引導。我們對商家進行培訓或者說是忽悠，告訴他們在廣告泛濫的時代，單純的廣告帖在論壇中不僅無法起到推廣的作用，還只會破壞論壇的環境，失去用戶。因此，符合規范的發言才有利于商家在社區論壇中獲得更好的回報。
我們在規范商家發言的時候，發現之前的版規已經不太適合當時的環境了。實際上，我們本該在制定好社區規則之后，再做商家的規范化要求，甚至應該說，我們本應該在第一步清理垃圾帖之后就將新的社區規則發布出來。
在運營一個社區時，社區規則的制定是必須的，完成的越早越好，同時還需要根據環境的變化不斷做新的調整和補充。
四月中旬的時候，終于有一批用戶在論壇中發一些優質的內容——裝修日記。在優質內容產出后，我們不僅對帖子進行一些加精華、送分送花的操作，鼓勵他們；同時還用馬甲號進行互動，以滿足用戶的心理需求，激勵他們繼續發帖。為了讓他們的發帖積極性更高，我們做了一期裝修日記評比，并臨時抽調了一批禮品贈送給他們。
做社區的同仁大概都會發現，如果單純靠運營編輯來產出內容的話，畢竟數量有限，而且內容多樣性遠遠不夠，而社區中可謂臥虎藏龍，社區中的用戶如果能夠充分調動起來，可以讓社區更富活力，同時更有多樣性。
當論壇的人氣上漲，氛圍漸好時，用戶會出于種種需求發布一些優質的內容，這是論壇開始有活力的標志，這第一批種子需要運營人員像呵護幼苗一樣驚心呵護，像幼兒園老師鼓勵小朋友發言一樣鼓勵他們繼續說下去。
在裝修日記評比活動后，我們陸續做了幾期線上活動，主要以“話題討論”為主。在這里需要說明的是，按照一般情況來說，我們的線上活動嚴重滯后了，但是由于之前領導層對整合型攻略十分重視，放棄了社區運營中常見的如“搶樓”、“投票”等線上活動，因而直到5月份策略有所松動時，才開始做線上活動。不過線上活動如“搶樓”、“投票”、“話題討論”、“評選”、“比賽”等對于拉動社區論壇的氣氛、活躍人氣還是非常有效果的。
在商家入駐的越來越多后，我們學習了兄弟站的經驗推出了商家庫，開辟了獨立的版面以滿足商家的宣傳需求，培訓商家如何做整合型的大帖以及如何正確的與社區中的用戶進行溝通交流。同時為了各方面的需求，對部分商家做了人物專訪。
在社區的用戶越來越多，氛圍越來越好，合作的商家也漸多之后，我們開始籌備做大型的線上活動——裝修日記大賽。
但是在籌備階段中，我突然想到隨著社區逐漸火熱，涌入的新人也越來越多，越來越多的新人可能面臨著操作上的疑問，因此開始做社區新手指南以及FAQ。
嗯，這個東西本來應該是和社區規則一起出臺的。
舉辦裝修日記大賽這樣的大型線上活動，一方面是為了商業化的利益，另一方面更是為了吸引用戶產出更多的優質內容，同時讓內容的產出保持常態化。當時我們已經積累了一部分優質的用戶與原創的內容，論壇的氛圍也非常活躍，因而裝修日記大賽的推動已經是水到渠成。7月初裝修日記大賽活動上線后，家居論壇的數據已經達到UV1500，PV上萬。
以上，就是我在接手家居論壇后的四個月里，所做的一些運營工作。
在這里要說明的是，這是我第一次做社區運營工作，因此這十四步中有許多步驟的前后順序相當值得商榷，比如社區規則的制定、社區新手指南及FAQ的推出、意見領袖的召回以及培養、線上活動的開展等等，都應該放在運營早期就做。當時由于缺乏經驗，基本上是摸著石頭過河，這些運營工作有的是在經理的指導與建議下做出的，有的是借鑒學習別的地方站，還有的就是自己平時混跡百度貼吧、豆瓣、天涯、貓撲時，覺得社區本來就應該這么做。因而做的時候一些地方都是懵懵懂懂，知其然不知其所以然，缺乏整體的規劃與統一的思路。不過本著紀實的角度，還是一步步的從頭記錄下來。
后來我一直都有在對那四個月的社區運營工作進行反思，也和別的社區運營人員溝通交流過，也研究了一些知名的社區的運營歷程與思路。總結了一些想法，和大家一起討論：
由于直到我離職的時候，都還不知道什么是運營，什么是產品，因此這些運營有的是在經理的指導與建議下做出的，有的是借鑒學習別的地方論壇，還有的就是作為一個資深網民，覺得社區本該如此。故而現在看來，運營思路缺乏整體的規劃與清晰的思路。
后來，當我初步了解互聯網產品的運營知識后，也研究了一些知名社區的運營歷程與思路，與其他社區運營同學交流之后，產生了一些新的想法：
（1）務虛和務實兩種社區類型的比較
社區運營時，一種是像百度貼吧、豆瓣、知乎這樣，傾向于務虛，偏向于討論一些陽春白雪的主題，另一種則是如十九樓、萬家熱線這樣的地方論壇，傾向于務實，偏向于討論一些親民、接地氣的話題。
而我個人認為，在社區產品中，后期生長出的百度貼吧、豆瓣小組、知乎的一個顯著優勢就是在于，它們將用戶的興趣聚焦為一個點，而不是地方論壇或是天涯、貓撲這樣的聚集為面。用戶的需求是越來越多元化的，一個個百度貼吧、豆瓣小組、知乎問答，將用戶的需求不斷細化，根據不同的需求，有相應的產品空間。在聚焦為面的論壇中，有一個問題即是用戶的多元化需求并不能在籠統的一個版塊很好的得到滿足。
不過地方論壇的優勢在于接地氣，越是接地氣的論壇，越是容易受當地網民的喜愛。它有一種具象化的特質，將論壇中的一個個虛擬的網友轉化為現實生活中同處于一座城市的朋友的傾向，從線上到線下的轉化更有優勢。
（2）社區與資訊的比較
社區與資訊最大的區別，大概就是UGC要比PGC內容空間大很多。另一方面，資訊要求的是權威性，可靠性，新聞性，而社區內要接地氣，要雞毛蒜皮，講述身邊人的故事，資訊中是一種中心化的視角，聚光燈圍繞著精英分子、知名人物，而社區則是每個人都有自己的故事。
（3）我對產品社區的一些想法
現在做APP產品的很多，一般都會有做配套的產品社區。我覺得產品社區，不僅僅是對產品的體驗社區，不僅僅是用戶提交各種使用產品后的體驗報告的地方，而是用戶用來交流的地方。用戶為了什么而使用產品，那么就讓用戶為了什么而交流。
如果是做互聯網家裝的產品社區，那么要的是裝修日記、裝修故事、裝修問題等，如果是做私廚的產品社區，那么要的是美食方面的美食故事、美食經驗、菜譜等等；如果是旅游類的產品社區，比如像攜程的社區——旅游攻略社區，就是為用戶提供鮮活、真實的旅游攻略、游記。
如果把社區當作一個大院兒，我們要做的大概就是召集鄰居，辦一個篝火晚會，聽他們挨個說自己的故事。講故事的人想獲得掌聲或是安慰，聽故事的人則要滿足人類的窺探欲，人們都需要交流，我們需要他們在我們的社區交流。
現如今，經過兩年多來不斷的學習、交流與總結，在對運營工作歷練更多，對產品領域系統學習之后，我對于如何運營一個社區總結了一個“七步運營”的方法，七個環節分別為：熟悉產品——競品分析——社區氛圍與種子用戶——拉新與促活——留存與轉化——老用戶召回——站好最后一班崗。下面對這七個環節做一個系統介紹：
作為運營人員，與產品團隊、技術團隊相比，相對來說接觸產品要晚一些。可能是社區產品進入研發期才開始介入，也有可能是產品1.0版上線后，公司因為種種需要才開始搭建產品社區，甚至還有可能是前任社區運營離職，臨時加入或者調崗補坑。無論哪種情況，當我們接手這個社區產品的運營工作時，需要做的第一件事情就是熟悉產品。
就像神槍手上陣前要檢查槍支彈藥，賽車手比賽前要檢查座駕一樣，社區運營人員在運營前需要對所運營的產品有一個深度的了解。
總的來說，有以下幾點：
現如今的互聯網行業，已經很難找到一個沒有競爭對手的細分市場了。如果真的是接手了一個沒有競爭對手的社區產品的話，那么恭喜你，挑戰與機遇并存。
孫子兵法有云：“知己知彼百戰百勝”，在對所要運營的產品各方面都非常了解之后，做競品分析就很有必要。對于競品的運營分析，可以從下面幾個維度來進行：
如果時間充裕的話，還可以競品用戶的身份深入使用產品，加入競品的種子用戶群，與競品的種子用戶、運營人員接觸交流。
競品運營分析只是手段，通過競品運營分析，可以讓我們
對于社區產品來說，良好的社區氛圍至關重要，而良好社區氛圍的打造與第一批種子用戶的質量也有極大的相關性。
比如知乎在最早期，通過嚴格的邀請制度使得種子用戶全部為互聯網行業以及投資圈、媒體圈的大佬，這批種子用戶被邀請后在獲得榮譽感的同時，也對自己的種子用戶身份高度負責，為知乎產出了一批高質量的內容，幾乎奠定了知乎的社區氛圍。
在早期社區氛圍培養時，常用的模式就是馬甲運營，運營工作人員以馬甲的身份產出優質內容，進行互動，形成一個我們所需要的社區氛圍的雛形，吸引種子用戶。
此外還需要對內完善如社區規則、新手指南、FAQ等“社區基礎設施”；對外完善如百科、問答、文庫、經驗等“品牌基礎設施”。當然如果是接盤俠，那么還需要像我之前做的那樣，對社區論壇進行大掃除，清理違規貼和垃圾帖。
在早期運營的時候，還需要多多收集用戶反饋與意見，與產品團隊合力探尋產品與市場的完美契合，驗證PMF。
種子用戶以在目標用戶群體的意見領袖為最佳，一般種子用戶的獲取方式有以下幾種：
獲取種子用戶后，需要與種子用戶多多溝通，多多交流，建立種子用戶群，讓種子用戶對社區更有參與感。
在良好的社區氛圍建立后，種子用戶不斷的吸引新用戶加入，PMF也驗證完成，就可以開始大規模的用戶拉新了。制定拉新方案前需要明確目標用戶群體的密集區、如何達到用戶、如何吸引用戶等問題。
常用的拉新手法：
（1）內容拉新
如之前所說的，在早期是通過社區運營人員產出大量優質內容，向目標用戶群體進行內容擴散，吸引新用戶；對種子用戶群體產出的內容中，進行優質篩選，編輯整理后進行擴散，可以參考的案例如“知乎日報”、“貼吧精選”。
（2）活動運營
舉辦活動，也是拉新的常用方式。結合自身產品特征和活動目標、活動預算、運營能力去開展活動吧，不管是大型活動、常規活動、小型活動，還是線上活動、線下活動，千萬記得多多做預案，做過程記錄，活動完了最后要做好掃尾工作和復盤。
（3）病毒營銷
可能是一篇優秀的文案，一個走心的視頻，也可能是一個有趣的互動H5，亦或是精妙的活動，讓你的產品在社交媒體上大肆傳播。
（4）借勢營銷
可以是內容的熱點借勢，也可以是在活動中添加熱點元素，關鍵是要契合自身產品特質與用戶屬性，一些負面屬性的熱點如無把握還是不要追的好。
（5）打造網紅
如果能夠像知乎那樣有一批自帶粉絲光環的優質種子用戶的話是最好的了，如果沒有的話，在已有的種子用戶中選出兩三個優質用戶，將他們打造成網紅，通過他們的光暈效應來提高產品本身的品牌曝光度，進而吸引新用戶。
（6）其他拉新手法
例如SEO/SEM；地推；PR報道；線下廣告等方式；還有如對社區中的內容進行原創保護，轉載時須注明內容出處及原作者，像“知乎”就是這么干的；讓社區中的內容可以一鍵分享，讓產品有更多機會傳遞到社交網絡中；優化不友好的注冊頁面等等。
拉新時需要注意平臺的承載能力以及產品的服務范圍，更重要的是，拉新之后一定一定要立馬促活，拉新只是手段，沒有激活的用戶等于白白浪費先期投入。
① 新手關懷
新用戶來到一個新的社區內就像一個剛出生的孩子一樣，運營人員要像父母帶寶寶一樣關懷她。設置新手提示、新手指南，教會她如何在社區愉快的玩耍，讓她看到社區的精妙所在；在她注冊后24小時內，給她發一封歡迎的郵件；給新用戶新手禮包，一些限時的高階道具等等，都是很好的新手關懷，當然最好的就是社區內有良好的氛圍，老用戶對于新用戶非常的友好并樂于幫助新人。
② 及時響應
在新用戶注冊后，能夠及時得獲得老用戶的互動或者是關注，可以通過機器人馬甲實現，也可以通過加大新用戶的推薦權重來實現；在新用戶回復或者發帖后，能夠及時得到老用戶或者社區運營人員的響應，讓他們有一種被關注的感覺。
③ 魔法數字
通過數據分析，找到用戶在使用產品時穩定下來的標準。比如說對“知乎”來說，據說這個“魔法數字”是3，也就是如果一個新用戶在短期內回答了三個問題，那么他就會成為知乎的活躍用戶。想辦法讓新注冊的用戶盡快達到魔法數字吧，比如說在注冊時推薦感興趣的話題小組或是社區風云人物等。
④ 激勵體系
與產品同學合力，建立一套良好的激勵體系，讓新用戶的每一步都被肯定，讓老用戶樂意于傳播產品，幫助新用戶。可以參考游戲化思維，設置經驗值、等級、勛章、道具、老帶新獎勵等等。
一般來說，用戶在產品上付出的時間與精力越多，離開成本就越高；沉淀的關系鏈越多，離開成本就越高；產出的內容，留下的個人印跡越多，離開成本就越高。
因此，運營人員可以通過活動、社群、建立私人聯系等等方式，讓用戶更有參與感，讓用戶之間有更多建立關系鏈的機會，讓用戶在產品中產出更多內容。讓用戶滿意，給用戶驚喜，提高用戶的忠誠度，這樣他們才愿意留下來。還有一個常用的促進留存的方法就是“簽到”，簽到升級、簽到送積分、簽到抽獎等等，此方法對于強迫癥人群尤其有效。
目前社區產品的轉化方式一般是：廣告模式、電商模式、服務模式，典型的案例如地方論壇、下廚房、O2O產品社區等。
運營在做用戶轉化時，要多多衡量商業價值與微笑價值，盡可能的選擇對用戶體驗傷害低的轉化方式，結合自身產品特征思考出更高明的轉化方式，典型的負面案例就是某吧。
老用戶可能因為種種原因，離開了社區。然而召回一個老用戶的成本，要遠低于拉攏一個新用戶。老用戶的價值更是遠遠高于新用戶：老用戶熟悉產品，老用戶有更為豐富的關系鏈，老用戶尤其是在社區產品中，會留下許多內容產出與個人印跡。
常用的召回模式如郵件/短信召回、活動召回、獎勵召回等，讓老用戶獲得如付費道具一定時間內免費用的權益，或是贈與額外道具、勛章等；通過關系鏈讓活躍用戶召回老用戶，并給予雙向獎勵，這都是不錯的召回方式。
每一個產品都有產品周期，從產品上線到拉新促活，再到留存轉化，再到收割，最后下線。不過很少有產品會走到這一步，為了整個運營流程的完整性，在這里姑且寫出來吧。
當產品下線提上日程時，一個方面成本回收，這個時候有可能產品和技術團隊已經先撤了，運營團隊慢慢的也會逐漸收編；另一個方面由于社區產品會有大量的用戶產出，因此需要考慮如何妥善處置，可能是數據遷移到自家公司的另一個產品上，也可能是數據遷移到友商那。無論是怎樣的情況下，運營人員都需要站好最后一班崗。
在這七個運營環節中，對于運營人員有四個貫徹始終的需要擁有的能力：
運營是個技術活，也是個細致活，還是個體力活，然而所有的付出，在看到數據上漲，收到用戶贊賞，產品漸漸長大時，都會化作點點滴滴的喜悅，支持著我們一路前行！
最后還要感謝《人人都是產品經理》的作者蘇杰老師、《產品前線》的作者蘭軍老師、《經·理@互聯網產品經理的進階修煉》的作者楊曉平老師、 “運營控”的作者飛魚船長、“今日雞血”的作者薄荷老師、“類類有話說”的作者類延昊老師、《用戶力》的作者郝志中老師、《產品的視角：從熱鬧到門道》的作者Luke老師等，本文的一些觀點援引自各位老師的著作，也是通過對各位老師前輩的作品的學習，才能讓我在今天可以對社區運營有如今這樣的認知。
作者：唐向陽，先后在騰訊家居、地方論壇、搜房家居、創業公司、傳統企業等多種類型公司從事運營工作。
本文選自蘭軍等編著的《運營前線2》一書 ，點擊鏈接了解更多優質內容：https://item.jd.com/12164754.html
未經出版社或作者書面授權，禁止轉載，違者追究法律責任。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
