整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
.前言
关于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小时内与您取得联系。
