概述 Webpack 的运行机制，不会讲解如何配置或者使用 Webpack。



## 基本概念

在了解 Webpack 原理前，需要掌握以下几个核心概念，以方便后面的理解：

*   **Entry**：入口，Webpack 执行构建的第一步将从 Entry 开始，可抽象成输入。
*   **Module**：模块，在 Webpack 里一切皆模块，一个模块对应着一个文件。Webpack 会从配置的 Entry 开始递归找出所有依赖的模块。
*   **Chunk**：代码块，一个 Chunk 由多个模块组合而成，用于代码合并与分割。
*   **Loader**：模块转换器，用于把模块原内容按照需求转换成新内容。
*   **Plugin**：扩展插件，在 Webpack 构建流程中的特定时机会广播出对应的事件，插件可以监听这些事件的发生，在特定时机做对应的事情。

## 流程概述

简单来说，Webpack 的构建流程可以分为以下三大阶段：

- 初始化：启动构建，读取与合并配置参数，加载 Plugin，实例化 Compiler。
- 编译：从 Entry 发出，针对每个 Module 串行调用对应的 Loader 去翻译文件内容，再找到该 Module 依赖的 Module，递归地进行编译处理。
- 输出：对编译后的 Module 组合成 Chunk，把 Chunk 转换成文件，输出到文件系统。

这是一个串行的过程，从启动到结束分为好几个阶段，每个阶段会发生很多的事件，Webpack 会把这些事件广播出来，所谓的 Plugin 就是在监听到特定的事件后执行相关代码，这期间插件还可以调用 Webpack 提供的 API 来改变 Webpack 的运行结果。

## 详细流程

详细的步骤我们参照下图来说：

<img src="https://picgo-1254029119.cos.ap-beijing.myqcloud.com/blog/images/webpack/webpack-02.jpg title:webpack整体流程图" style="max-height: 300px">

> 注：图中并未展示所有事件，可参考 [Webpack 文档](https://webpack.docschina.org/api/compiler-hooks/#%E7%9B%B8%E5%85%B3%E9%92%A9%E5%AD%90)。图片来源见文末。

### 初始化

- 初始化参数

这个阶段 webpack 会将用户配置的 `webpack.config.js` 和 `shell` 脚本传过来的参数整合成 `options` 对象传到了下一个流程的控制对象中。合并参数过程中 webpack 也会根据参数中的信息来执行插件实例化语句`new Plugin()`。

```js
// options 作为最后返回结果，包含了之后构建阶段所需的重要信息。
{ 
  entry: {},//入口配置
  output: {}, //输出配置
  plugins: [], //插件集合(配置文件 + shell指令) 
  module: { loaders: [ [Object] ] }, //模块配置
  context: //工程路径
  ... 
}
```

- 实例化 Compiler

用上一步得到的参数初始化 Compiler 实例，Compiler 负责文件监听和启动编译。Compiler 实例中包含了完整的 Webpack 配置，且全局只有一个 Compiler 实例。这个时候，真正的 webpack 对象才刚被初始化，具体的初始化逻辑在 `lib/webpack.js` 中：

```js
function webpack(options) {
  var compiler = new Compiler();
  ...// 检查 options,若 watch 字段为 true,则开启 watch 线程
  return compiler;
}
...
```

- 加载插件

有了 Compiler 实例之后，开始加载插件，依次调用插件的 apply 方法，让插件可以监听后续的所有事件节点。同时给插件传入 compiler 实例的引用，以方便插件通过 compiler 调用 Webpack 提供的 API。

- entry-option

遍历配置文件中所有入口，为每个 Entry 实例化一个对应的 EntryPlugin，为后面该 Entry 的递归解析工作做准备。

- after-plugins

调用完所有内置的和配置的插件的 apply 方法。

- after-resolvers

根据配置初始化完 resolver，resolver 负责在文件系统中寻找指定路径的文件。

### 编译

webpack 的实际入口是 Compiler 中的 run 方法，run 一旦执行后，就开始了编译和构建流程 ，其中有几个比较关键的 webpack 事件节点。

- compile：开始编译

`compiler.run` 后首先会触发 compile 事件 ，这一步会构建出 Compilation 对象。

- compilation 对象

当 Webpack 以开发模式运行时，每当检测到文件变化，一次新的 Compilation 将被创建。一个 Compilation 对象包含了当前的模块资源、编译生成资源、变化的文件等。这个对象有两个作用，一是负责组织整个打包过程，包含了每个构建环节及输出环节所对应的方法，在每一个节点都会触发 webpack 事件去调用各插件。二是该对象内部存放着所有 module ，chunk，生成的 asset 以及用来生成最后打包文件的 template 的信息。

在编译阶段中，最重要的要数 compilation 事件了，因为在 compilation 阶段调用了 Loader 完成了每个模块的转换操作，在 compilation 阶段又包括很多小的事件，它们分别是：

```
build-module：使用对应的 Loader 去转换一个模块。
normal-module-loader：在用 Loader 对一个模块转换完后，使用 acorn 解析转换后的内容，输出对应的抽象语法树（AST），以方便 Webpack -后面对代码的分析。
program：从配置的入口模块开始，分析其 AST，当遇到 require 等导入其它模块语句时，便将其加入到依赖的模块列表，同时对新找出的依赖模块递归分析，最终搞清所有模块的依赖关系。
seal：所有模块及其依赖的模块都通过 Loader 转换完成后，根据依赖关系开始生成 Chunk。
```

### 输出

- should-emit：所有需要输出的文件已经生成好，询问插件哪些文件需要输出，哪些不需要。
- emit：确定好要输出哪些文件后，执行文件输出，可以在这里获取和修改输出内容。
- after-emit：文件输出完毕。
- done：成功完成一次完成的编译和输出流程。
- failed：如果在编译和输出流程中遇到异常导致 Webpack 退出时，就会直接跳转到本步骤，插件可以在本事件中获取到具体的错误原因。
在输出阶段已经得到了各个模块经过转换后的结果和其依赖关系，并且把相关模块组合在一起形成一个个 Chunk。 在输出阶段会根据 Chunk 的类型，使用对应的模版生成最终要要输出的文件内容。


## 最后

要详细的把 Webpack 的整个流程说下来，一篇文章肯定是不够的。这篇文章只是大概的梳理了一下，讲的很粗糙，后续有了新的理解还会更新。作者水平有限，还请轻喷~

## 参考

- [淘宝前端团队](http://taobaofed.org/blog/2016/09/09/webpack-flow/#comments)
- [Webpack运行机制](https://github.com/jerryOnlyZRJ/webpack-loader/blob/master/docs/webpack-principle.md)
- [深入浅出Webpack](http://webpack.wuhaolin.cn/)

Webpack 运行机制

知识系统化最主要的最难的步骤在`深入而持久的思考`，不断问为什么，并用实践来验证思考的对错。



## 前言

我之前的知识管理习惯是使用笔记软件来收集整理平时遇到的好文章、好观点，然后定期整理、归纳。但时间一长就会感觉自己像一只仓鼠，收集整理的内容并不能完全记住和理解，感觉自己的知识管理方法需要更新迭代了，急需一种更科学的、可行的并且适合我的个人知识管理方法。

有一个需要注意的点：`知识和信息是有区别的`。知识是有价值观基础的、逻辑化、结构化了的信息。我之前所收集整理的，充其量只是信息，算不上知识。

## 目标

- 理论跟实践结合的系统化知识结构
- 通过持久而且深入的思考，能够找出事件背后隐藏的规律性，可以预知并避免问题的发生
- 积累到一定程度后实现这个过程的流程化、系统化，然后持续优化迭代

## 流程

- 收集、记录
    - 主题阅读、经典著作，形成个人信息库
- 定期整理、总结
    - 做笔记、思维导图等，根据个人目标形成知识地图
- 思考、实践、操作
    - 技术类的问题还好说，经验性的东西这一步真的好难
- 输出
    - 写博客、教学、做PPT，多谈论和分享心得
- 流程化、系统化，养成习惯和节奏
    - 持续优化迭代


把自己的知识系统化最好的方法就是主动输出，多多分享、教学，这会强迫自己去思考和形成系统性。知识系统化最主要的最难的步骤在`深入而持久的思考`，不断问为什么，并用实践来验证思考的对错，在这之后想要进行输出的话也就很容易了。

## 具体做法

- 每天晚上整理为知笔记，每周日集中整理、总结
- 周日不收集任何新信息，读书除外
- 博客每周最少一更

## 参考

- [如何把学到的知识系统化，即知识管理](https://www.zhihu.com/question/20737761)
- [怎么样整理、巩固平常积累的零碎知识](https://www.zhihu.com/question/23198256)

关于个人知识管理

前面五大模块，把做一个产品五大块的思考框架介绍了一遍。
最后三节课，权当聊天，作者介绍了一下产品体系的三个层次和个人平时的一些感受。




## 28 看产品的微观、中观与宏观视角

这节课把好产品用三个层次介绍一下，分别是中观、微观、宏观。

- 中观套路：学习招数
	- 有大量的套路：用户画像、痛点和痒点、整体流程图、用户体验地图和服务蓝图。
	- 有很多讲套路的书：用户需求、产品策略、功能定义、流程图制作、产品原型制作、项目管理、数据分析、产品运营。..
	- 大公司是学习套路的好地方。
		- 比如：联想出销售、腾讯出产品经理、阿里出运营、百度出技术。
	- 套路是有价值的，练好套路可以自我排查问题，便于和团队沟通。
	- 但套路也会把你角色化，让你只能作为系统的一个角色，习惯系统内的生存。
	- 套路可以让你更有章法地展现自己，更容易搞定面试官，成为系统内按指令行事的公司中层。
	- 靠套路成不了高手


- 微观体感：成为高手
	- 微观体感：真实地感知每一个微小瞬间
	- 每一个微小的动作选择叠加起来，就是你拿出来的产品，就是你活出来的样子。
	- 产品是一种被动的艺术。一个产品只能在被动中，默默把握每一个微小的主动机会，在每一个接触的瞬间，每一次的交互里，让用户顺畅地深入下来。
	- 建立细微的微观体感
		- 要不断练习，在最不容易建立观察的地方，建立每一个微小处的觉察。
		- 反思什么样的设计才能让用户满足？
		- 复盘用户是否产生了防御心？
		- 为什么会在这里卡顿？
		- 产品应该怎么做才自然？
	- 拥有了中观套路的人，一定要补微观体感。否则，说起来都对，做事却都不到位。
	- 如果能够同时拥有微观体感和中观套路，那就是一个产品好手了。


- 宏观能力：打大仗
	- 在这套课里的点线面体、创新模式都是宏观能力。
	- 锤子手机的微观体感和中观套路如何？很好啊。比起小米手机，差在宏观能力。
	- 易到用车当时的用户体验和口碑如何？很好啊。比起滴滴，差在宏观能力。
	- 几家定位相似、体验相似的产品，靠优化用户体验，其实是无法终结战争的。大仗拼胜负，靠的是宏观能力。


- 练好套路，在大公司做到中层没问题。
- 要想自己为结果负责，开门立户创业，必须有长在自己身上的微观体感。
- 没有微观体感，靠套路判断，就是自欺欺人。但打大仗，做顶级高手，则要求宏观能力也要强。


## 29 人生逻辑大于商业逻辑

- 大王：确定性，小王：依赖
- 雷军和“风口论”
	- 抢风口，背后的一个核心能力是抢资源的能力
	- 争夺最好的团队，争夺最大笔的投资，争夺公众最大化的关注，争夺合作伙伴最优质的资源与配合。..
	- 2014 年到现在，咱们看到了几次风口，O2O 上门服务、打车大战、外卖大战、网络金融、共享单车。.....
	- 所有的“风口争夺战”挺到最后并飞上天的， 其实真没有谁是碰了运气的猪 ，全部是创业了好久，磨炼了好久的老手。
- 确定性和不确定性
	- 马云的组织观
		- 三级组织：是共同规则。
		- 二级组织：是共同利益。
		- 一级组织：是共同信仰。
		- 顶级组织：是至情至性。
	- 无法持续输出确定感，无法让人依赖，不管做人做产品都很难成功
		- 世界是多维的，到处是此起彼伏的点线面体，各种机会呈现出的就是各种变幻，各种不确定。
		- 你会因为对于机会和利益的判断，而在各种不确定中坚持多久呢？
		- 那什么样的人、东西、感觉会给你确定感，让你觉得可依赖，其实是极其重要的。
		- 持续收到确定感的反馈，就会觉得安全，觉得可以依赖。如果突然变得不确定，就会有被伤害的感 觉。


- 确定性依赖
	- 观察我们的父母，身边的伴侣，认识的创业合伙人，谁是完美的？他们之间有没有抱怨、不满？肯定的。他们之间有依赖吗？有的。
	- 所谓“完美的产品”“极致的产品”就像“完美的人”一样，只是一种追求，但世上并不存在。
	- 重要的不是完美，而是对方要的那个确定性你是否还能提供，对方是否还依赖你，这才是关系的关键。


- 4 张牌
	- 红桃 K：是“不确定性”。它是生活的一部分，是我们不能畏惧，需要勇敢拥抱的东西。
	- 黑桃 K：是“点线面体”。是宏观格局的判断，是你做人生选择题时可以采用的思考框架。
	- 小王：是依赖。
	- 大王：是确定性。
	- 这就是我们最后确定的 4 张牌。


- 人生逻辑大于商业逻辑
	- 如果你内心没有“确定感”，如果没有人依赖你，你也没有人可以依赖，点线面体、价值网、三级火箭这些创新战略，即使你看到了，也是空无而不可持续的。
	- 商业是以利润为中心，人生是以意义为中心。 商业并非人生的全部。
	- 人死前盘点自己的一生，其实没有人看这一生赚了多少利润。
	- 做你有内心确定感的事，人生逻辑大于商业逻辑。


## 30 产品连接客观世界、过去与将来

- 所谓自信是在不断的创造与反馈中建立的。
- 产品经理的荣耀
	- 2011-2018 这 7 年，因为智能手机的普及，微信这种超级应用的拉动，中国 8 亿人成为了高频的网民
	- 今天你已经习以为常，成为生活依赖的应用，放到 7 年前，其实统统都是还没有的。
	- 你有专业化视角，你有专业化能力，你可以从大海里取出盐，你可以在一间会议室里做出微信，你可以在一个小屋子里定义出小米手机。
	- 自此，无数人有了不同的机会，无数人的生活因此改变。
	- 2018 年以后，新公司应该是以互联网为基础设施的科技公 司，新品牌公司。
	- 今天的中国不少领域的产品人，在中观套路、在微观体感、在宏观视野，都已经不输于那些国际大厂的产品经理。
	- 如果你抛开惯性化的仰视和妄自菲薄，我们客观评估一下，曾经横吞了整个中国日化、消费品类的那些国际大牌，你会感受到中国还在孕育奇迹。
	- 我们一定会孕育出下一个宝洁，下一个雀巢，下一个 ZARA。
- 不辜负这个伟大的时代：
	- 愿你伟大时代，置身局内
	- 这是另外一个伟大的时代，你我，都不应该置身局外。
	- 愿你拥有专业化视角和专业化能力。看到时代的浪潮，不再抱怨波涛滚滚的凶险，而能看到大海的本身就是资源。
	- 不需要哀怨自己没有出身背景，没有干爹，在这个时代，只要你拥有一个用户，你就拥有了一个开始。
	- 愿你能够使用这套方法，建立自己的动手能力。动动手，你所在的小世界就会优化一点点。
	- 愿你在这个时代，把握真正属于你的那个机会。
	- 把你一生积累的认知、审美、好恶全部用上，为这个世界提供一个不一样的产品，向世界交付你的价值。


完。

《产品思维 30 讲》：结课辞

《产品思维 30 讲》第五模块：创新模式

本文为 Git 学习的笔记。参考课程为极客时间的[《玩转 Git 三剑客》](https://time.geekbang.org/course/intro/145?code=o9e8mlOfOwtb-R97tPjzT2oifElj8ToMC7H2CDYtWOQ%3D&amp%3Bamp%3Butm_term=SPoster)以及[《Pro Git》](https://git-scm.com/book/zh/v2)这本书。笔记有很强的主观性，如果你要拿来学习的话，仅供参考！



## 课程综述

### 版本管理的演变

`版本管理系统`英文缩写 —— VCS

- VCS 出现前
	- ⽤⽬录拷⻉区别不同版本
	- 公共⽂件容易被覆盖
	- 成员沟通成本很⾼，代码集成效率低下
- 集中式 VCS（CVS、SVN）
	- 有集中的版本管理服务器
	- 具备⽂件版本管理和分⽀管理能⼒
	- 集成效率有明显地提⾼
	- 客户端必须时刻和服务器相连
- 分布式 VCS（Git）
	- 服务端和客户端都有完整的版本库
	- 脱离服务端，客户端照样可以管理版本
	- 查看历史和版本⽐较等多数操作，都不需
	- 要访问服务器，⽐集中式 VCS 更能提⾼版
	- 本管理效率
- Git 特点
	- 最优的存储能⼒
	- ⾮凡的性能
	- 开源的
	- 很容易做备份
	- ⽀持离线操作
	- 很容易定制⼯作流程

### 课程内容

- Git
	- 工作原理
	- 如何使用
- GitHub
	- 全球最大开源社区
	- GitHub 生态
- GitLab
	- 一般的公司会基于 GitLab 做自己平台的二次开发


## 初次运行 Git 前的配置

安装完 Git 应该做的第一件事就是设置你的`用户名`与`邮件地址`。 这样做很重要，因为每一个 Git 的提交都会使用这些信息，并且它会写入到你的每一次提交中，不可更改：

```
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
```

`config` 的三个作用域：

```
// 只对仓库有效（权限最高）
$ git config --local

// 对目前登录用户所有仓库有效（权限次之，默认就是 local）
$ git config --global

// 对系统所有用户有效（权限最低）
$ git config --system
```

查看设置：

```
$ git config --list --local
```

清除设置：

```
$ git config --unset --local user.name
```

### 给文件重命名的简便方法

常用方法：

在`工作区`重命名文件，此时执行`git status`会提示添加新文件和删除旧文件。然后我们添加新文件到`暂存区`，并删除旧文件，步骤繁琐，并且重命名的过程并不直观。

简便方法：

```
git mv 旧名称 新名称
```

直接在暂存区修改，一步到位！

### `.git`目录、commit、tree 和 blob

:::tip
这几节课程作者开始讲解关于 Git 原理的东西，但是讲的很没有章法。想更好的理解这一部分的知识点，可以参考《Pro Git》的`Git 内部原理`这一章。
:::

下面对于 Git 的原理进行基本梳理：

首先要弄明白一点，从根本上来讲 Git 是一个内容寻址
（content-addressable）文件系统，并在此之上提供了一个版本控制系统的用户界面。

Git 进行版本管理的信息全部存放于`.git`文件夹。

```
$ ls .git

branches/
config
description
HEAD
hooks/
info/
objects/
refs/
```


未完待续...