前言 随着web的发展，网站资源的流量也变得越来越大。据统计，60% 的网站流量均来自网站图片，可见对图片合理优化可以大幅影响网站流量，减小带宽消耗和服务器压力。 有时候你花大力气去配置 webpack 使打包体积减少，不如好好优化几张图片，这篇文章就是让你明白如何选择正确的图片，并且让你明白这么多图片格式，在什么场景下使用什么格式，如果想看答案，那么直接滑到文末看图即可。 我的更多文章可以看 GitHub博客, 基本概念 在进入正题之前，先聊聊一些图片相关的基本概念。 一张照片（位图）不断放大之后，会看到一个个小格子，这些小格子，叫像素。 一个格子（像素），在计算机中，用二进制来表示，使用的二进制位数越多，像素的色彩就越丰富。 举个例子，如果一个像素用一位二进制数表示，能有多少种颜色呢？ 两种，一个二进制位，要不放 0（表示黑色），要不放 1（表示白色） 下图展示了一个像素二进制的位数最多可以展示多少种颜色。 在对图片有了基本的了解之后，接下来对图片进行分下类，有利于理解各种格式图片的特点。 根据图的类型分类 点阵图(位图) 矢量图 位图(点阵图) 位图，也叫做点阵图，像素图。构成点阵图的最小单位是像素，位图就是由像素阵列的排列来实现其显示效果的，每个像素有自己的颜色信息，在对位图图像进行编辑操作的时候，可操作的对象是每个像素，我们可以改变图像的色相、饱和度、透明度，从而改变图像的显示效果。 前面介绍中的那种不断放大会有小格子的图就是属于位图。 常见的比如：jpg、png、webp等，我们平时遇到的大多数都是位图。 矢量图 矢量图，也叫做向量图。矢量图并不纪录画面上每一点的信息，而是纪录了元素形状及颜色的算法，当你打开一幅矢量图的时候，软件对图形对应的函数进行运算，将运算结果图形的形状和颜色显示给你看。 无论显示画面是大还是小，画面上的对象对应的算法是不变的，所以，即使对画面进行倍数相当大的缩放，其显示效果仍然相同(不失真)。 常见的就是 svg 格式的。 根据压缩分类 无压缩。 无损压缩。 有损压缩。 无压缩 无压缩的图片格式不对图片数据进行压缩处理，能准确地呈现原图片。BMP 格式就是其中之一。 有损压缩 指在压缩文件大小的过程中，损失了一部分图片的信息，也即降低了图片的质量，并且这种损失是不可逆的，我们不可能从有一个有损压缩过的图片中恢复出原来的图片。 常见的有损压缩手段，是按照一定的算法将临近的像素点进行合并。压缩算法不会对图片所有的数据进行编码压缩，而是在压缩的时候，去除了人眼无法识别的图片细节。因此有损压缩可以在同等图片质量的情况下大幅降低图片的尺寸。其中的代表是 jpg。 无损压缩 在压缩图片的过程中，图片的质量没有任何损耗。我们任何时候都可以从无损压缩过的图片中恢复出原来的信息。 压缩算法对图片的所有的数据进行编码压缩，能在保证图片的质量的同时降低图片的尺寸。 png 是其中的代表。 小结 使用有损压缩处理图像，是去除某些像素数据，无法找回原图。 使用无损处理图像，是对像素数据进行压缩，可以找回原图。 常见的图片格式解析 GIF 关键词：无损压缩、索引色、透明、动画 GIF(Graphics Interchange Format) 的原义是“图像互换格式”，是一种基于 LZW 算法连续色调的无损的基于索引色的压缩格式。其压缩率一般在 50% 左右，它不属于任何应用程序所以几乎所有相关软件都支持它，公共领域有大量的软件在使用 GIF 图像文件。 GIF 是一种无损压缩，所以它只是对像素数据进行压缩，其实 LZW 算法只是一个压缩数据的算法，如果你懂哈夫曼算法的话，可能就比较好理解压缩数据是怎么回事儿了。 GIF 的特性是帧动画。...

最近 996.ICU 太火了。我本来不太想蹭这个热点，因为我的观念与很多人可能不相同，所以担心被骂，最近有读者问我为啥最近没有更新，最近我在准备晋升的事儿，所以也没怎么准备技术上的内容，但是对于 996 这件事儿上，我最近还是有很多想法，跟大家交流下吧！ 后面我会将最近晋升的一些心得总结出来跟大家交流一下，毕竟涨工资呀，所以希望对大家有帮助。 一、反对 996 的本质原因 为什么要反对 996，说到底，就是钱给的不够。 这句话可能说到了心坎里去，咱们来理一理这个逻辑。 如果，发工资不按照一个月一个月发，不按照一天一天的算，而是按照小时、或者分钟、甚至秒来算，你会不会愿意每天多工作一阵子。 加入你现在工资每个月 10000，那么每天的日薪差不多是 480 左右，一天八小时，时薪就是 60。你每多工作一小时就可以多得 60 块，如果你不是三和大神(不知道三和大神的搜索一下，不然你可能不太好理解)的话，你大概率不会只工作 8 个小时。 所以，我觉得说到底，反对的就是企业搞 996，加班不给加班工资导致的问题。 对于头条，阿里这样的企业，虽然知道他们加班很严重，但是工资高呀，所以很多人拼了命的想去。 今天我在小道消息里看到这样一个观点，加班的时候不愿意加，看到别人拿年终奖拿得多又羡慕；自己体会这句话吧。 二、我的一些观点 讨论完了本质，我再说一下我的一些观点。 **首先声明，我是极力反对 996 的。**但是对于现在很多人的行为不是太赞同，所以写出来跟大家讨论下。 1. 不喜欢就走 在这场革命(说得似乎有点严重了)中，不少人想到终于有机会吐槽自己的公司了，垃圾公司，压迫员工，还搞 996。 对于这种行为我的观点是既然觉得在公司干得不爽，为何不走呢？ 心里可能想着：我也想走呀，但是没其他公司要我咋办。 这种想法我感觉是一种弱者的态度，即表现出了自己弱，然后又抱怨现状。这种行为就像这样一群人，整天自己不努力，然后抱怨世界不公平，为什么我的爸爸不是王健林；为什么同一个老师教的，他的成绩那么好；为什么同一个班的，他的工作那么高；为什么一起进公司的，他为什么涨工资。 如果你有能力，不喜欢这个公司的制度，不能忍受 996，选择离开就行了呗。 所以，提升自己，让自己变得更强，不喜欢就走。 2. 其实我们已经很幸运了 作为程序员的我们，其实已经很幸运了，还有假期，还有双休，已经很不错了。有很多行业，根本没有休息，一年可能就只有过年的那几天会放，没错，我爸爸的职业就是这样，建筑工人，他们没有周末，没有节假日。 另外你在外面看到的环卫工人，外面开早餐店，饭店的，有过双休吗？ 我说这点其实主要是想表达，我们应该少点抱怨，我们还是不错了，咱们让自己变得更强，多为社会做点有价值的事儿，让更多的人拥有双休，拥有节假日。这肯定不是取去革命能解决的事儿，不是去抵制资本家能干的事儿。 3. 多花时间来提升自己的工作效率 说实话，大部分人工作时间的三分之一都没有为公司产生价值。 这三分之一的时间你可能会早上用来刷下咨询，各大群水一下，看看各大新闻网站等待。也许还会去抽抽烟，跟同事聊聊天，以及有一些时间你无法专心工作等。 当然，不可能有人做到每天都百分之百的投入，但是投入的比例就是人与人之间的差距，这是一个影响效率的地方。 众所周知，在公司级别比你高的，经验比你丰富的，代码敲得比你快，完成任务比你好，这肯定嘛，别人工资拿得也高，所以干活也多。反过来也成立，活干得多，工资拿得高。你给公司创造的价值越大，那么你就应该拿更多的工资，后面我将晋升也会说到这个。 所以我们已经想办法提高自己的工作效率，在一定的事件内干更多的活，那么你就需要提高自己的能力，这样你就能在规定的事件内完成任务，当然就不需要加班了。 可能有人说，公司就是给你的任务是无论怎么做都做不完的，那么这种公司对于资源不合理安排，你可以选择第一点，不喜欢，咱就走。 三、这件事情我思考了哪些？ 我在跟我周围讨论相关话题的时候，我感觉我思考的问题跟他们不同。比如： 为什么这个仓库，或者说这个网站会传播得这么快？在最开始的几十，几百颗 star 是怎么来的？为什么同样类似的项目，godie996(方应杭的项目，地址是：https://godie996.com)没有火起来呢？当时我们讨论了两个原因：一个是各大群的宣传，另一个是 996.ICU 界面做得好看。另外的原因供大家思考，欢迎在评论区给出你的答案。 为什么那么多人不满意自己的公司，而不选择离开呢？ 为什么会这么多公司会搞 996 呢？ 同样是互联网公司，为什么国外的大厂不搞 996 呢？ 等等很多问题我觉得才是我们应该去思考的地方，我们只有去思源，才能从根本上解决问题，从表面现象去解决问题很多时候会走很多弯路。 对于这个我举个例子，古代的铁匠都知道百炼成钢，把铁红了，然后拿出来锤，然后又拿进去烧，反复几次，就会发现做出来的铁具很硬，但是不知道为什么，其实就是因为铁里面融入了炭。所以近现代的就直接在熔铁的过程中加入炭，就不需要反复锤炼了。...

文章首发于个人网站：前端桃园 很多人总是抱怨面试官问一些平时不常用的知识点，比如算法呀，网络(TCP)等等，也就是大家常说的：面试造火箭，工作拧螺丝。 但是有没有想过为什么整个前端圈，或者绝大部分面试，不仅是前端，各种职位都是这样呢？难道就没人来解决这个问题吗？ 我觉得，事实上，这是一种合理的行为，并不是因为存在即合理，而是本来就应该这样，接下来我以两个方面阐述我的观点。 一、 考验对专业知识的掌握的扎实程度 在张鑫旭的十问十答里的一个问题是，「前端开发基础扎实的标准是什么？」 这里面他对「扎实」的解释我觉得很适合来答这个问题。 「扎」其实可以理解为深度，你可以想象一个用一根针，扎你的皮肤，对一个点的压力，可以让你痛不欲生。 那么如何理解知识的深度呢？ 我还是拿前端面试来举例，比如考一个快速排序，很多人就觉得这有什么好考的嘛，平时又用不到，引擎底层已经写好了 sort 方法，什么数量级用什么排序底层也已经实现好了，没必要考了呀。 但是其实面试官并不是想考你快排的代码是如何写的，说实话，花个十分钟，最多半小时，一个快排的代码你肯定可以记住。但是其实考察快排的真正原因可能不仅仅是考察代码，而是考察它的思想，分而治之(分治法)，划分算法的运用。 另外可能会再问你，它的时间复杂度是多少，如何计算等这些问题，这些问题也不是来考你这一个算法的计算，而是通过这一个算法来看你知道怎么算时间复杂度不？以此来引导你为什么快速排序快，为什么同样是分治法的归并排序没有这么快。等等相关的算法方面的知识。 面试官所考察的问题只是各种底层思想的一个运用，通过这个实例应用来考察对底层思想的理解程度。所以很多时候大厂的面试总是从浅入深的问问题，直到把你问到不知道为止。 再谈谈「实」，实则可以理解为满，考察知识的广度。 想象一下什么样的情况你才会说一个东西实，给你一晚装满的米饭，并且还压一压，再放进去一些米饭，直到压不下去了为止，这个时候你会说满满的一晚米饭，很实在。 所以对「实」的理解就可以理解为满，全。 如何来体现你对知识的广度呢，也就是实。 比如可以考察一些你平时不常用的，但是你也许会用到的知识点。比如一些简单的算法和数据结构，链表呀，网络里面的 tcp/ip 协议族呀，函数式编程呀等等，一些 html5 的特性(比如 web-compoennt)等等。 你可能在平时编程中没用到，或者大多数前端工程师平时不会用到，但是这些是基本功是需要知道的，比如 React 源码中就用到一些简单的数据结构，链表(Fiber 树就是用链表的结构存的，是一个单链表，以及里面还有循环列表的增删改查)，如果不知道树可以用链表存，如何对链表进行操作，那么可能你看源码就很成问题。里面还有一些位运算等，位运算平时也不常用吧，但是 fb 的工程师就用它来解决实际问题。 再比如 web-component，这已经是 w3c 提出的一个前端组件化的标准了，我国也有大佬用 web-component 实现了一些库，比如腾讯出的 OMI。 地址： https://github.com/Tencent/omi 所以狼叔在 「2019 大前端技术趋势深度解读」里提到可能他是下一代框架的标准。 我们前端变化得快，新东西也多，如何不跟上时代，多了解(主要了解，不是每个新东西都要去深究，因为你没那么多时间，大多数时间还是要用在平时用得到的地方)一些新东西。跟不上时代，也行就会慢慢的被淘汰，所以现在前端招聘基本上都会需要你会一门框架，不管是 React 、Vue、Angular，这些都是趋势，数据驱动，不再是以前拿起 jQuery 就是干了。 小节 在工作中常用的知识点，那些是最重要的，那么大家都会这些，**如果你不知道点，别人不知道的东西，这些东西比别人掌握得更深一点，面试官为什么要你？**也许你还是个双非（非982、211）。 我觉得在任何领域都适合一个定律，就是「T」字形发展，先把专业搞深一点，然后往两边扩展。 二、醉翁之意不在题 另外面试官也许会考你一些软技能，考你的不仅仅是面试题完成了那么简单。这点注意，越简单的题越不简单(好好理解这句话)。 我拿我自己的经历来举例，之前做小米的笔试题(是那种把题目发给你，两天内做好了发给他)的时候，有一道题是：求最大公约数的题目。 很多人看到这道题觉得很简单嘛，几行代码就搞定了，当时跟我一起做笔试题的几位竞争者也是，他们就写了一个算法。 而我当时想到，我觉得面试官在检查这道题的时候如果看代码还是有点麻烦，所以我就写了一个界面，界面上提供了可以点击的数字，还有输入框，还有几个计算按钮，一个结果框，用户可以通过点击数字，或者在输入框里输入数字进行计算最大公约数，还做了一些错误提示等。 这相当于做了一个应用，一个可以给用户使用的应用，所以最后因为这道题，我被录取了。 我被录取的原因，这些都是进去之后，老大告诉我的，当时很惊讶，竟然是因为这个。 所以之后我就越来越注重用户体验，多一些思考，让别人用自己做的东西的时候更舒服，更方便。 我期望的面试官 声明：我没当过面试官，所以以上内容大多是我思考(猜测)的，也可以用说用一种合理的解释，来解释了现在这种现象。 我期望的面试官是这样的，或者说如果我以后当了面试官我会怎么做。 作为面试官不是把面试者考倒，而是尽量挖掘面试者擅长的地方，然后去打破砂锅问到底的看对擅长的地方研究有多深，考察深度。 在考察的时候先考察广度，再考察深度，从广度的问题中提取擅长的点，然后再问下去。 一些小提示 一般面试官不会因为你某道题没答出来就否定你的。 面试官不喜欢简历上写的啥都会，一问每个知识点都掌握得很浅。 对于平时常用的框架，至少要知道核心原理。 这些是之前我们组面试官在讨论的时候提到的，希望能给大家帮助。...

简介 PM2 是 node 进程管理工具，可以利用它来简化很多 node应用管理的繁琐任务，如性能监控、自动重启、负载均衡等，而且使用非常简单。 安装 npm install -g pm2 快速使用 pm2 start app.js 常用命令 启动 参数说明： --watch：监听应用目录的变化，一旦发生变化，自动重启。如果要精确监听、不见听的目录，最好通过配置文件。 -i --instances：启用多少个实例，可用于负载均衡。如果-i 0或者-i max，则根据当前机器核数确定实例数目。 --ignore-watch：排除监听的目录/文件，可以是特定的文件名，也可以是正则。比如--ignore-watch="test node_modules "some scripts"" -n --name：应用的名称。查看应用信息的时候可以用到。 -o --output <path>：标准输出日志文件的路径。 -e --error <path>：错误输出日志文件的路径。 --interpreter <interpreter>：the interpreter pm2 should use for executing app (bash, python…)。比如你用的coffee script来编写应用。 重启 pm2 restart app.js 3.3 停止 停止特定的应用。可以先通过pm2 list获取应用的名字（–name指定的）或者进程id。 pm2 stop app_name|app_id 如果要停止所有应用，可以 pm2 stop all 停止 类似pm2 stop，如下 pm2 stop app_name|app_id pm2 stop all 从进程列表删除进程 // pm2 delete [appname] | id pm2 delete app // 指定进程名删除 pm2 delete 0 // 指定进程id删除 删除进程列表中所有进程 pm2 delete all 查看进程状态 pm2 list // 或者 pm2 ls 查看某个进程的信息 pm2 describe 0 负载均衡 命令如下，表示开启三个进程。如果-i 0，则会根据机器当前核数自动开启尽可能多的进程。...

我发布了我的第一个 npm 组件，一个基于 react 的 3d 标签云组件。在这途中我也是遇到了很多的坑，花在完善整个发布流程的时间远多于写这个组件本身的时间，所以我记录下我觉得一个正常的 react 组件的发布流程 最后记录这篇文章花的时间比我完成整个组件的时间都多，最终希望能给新手带来帮助 在整个发布组件的过程我做了如下几件事儿： 开发组件 编写 Readme 推送到 github，并且把 demo 放到 github page 上 发布组件到 npm 上 开发组件 创建项目文件夹并初始化 npm package ，确保你创建的组件名称没有在 npm 上被使用过， 这里我们用 react-demo 作为示例 mkdir react-demo cd react-demo npm init npm init 是生成初始的 package.json 的命令，在 npm init 的时候，你可以根据你自己的需要进行填写你的组件信息。或者直接使用 npm init -y 采用默认的，后面自己再去修改。 首先安装 react 相关的包： npm i react react-dom -D 采用 babel 编译相关的依赖： npm i @babel/cli @babel/core @babel/preset-env @babel/preset-react -D 采用 webpack 做构建，webpack-dev-server 作为本地开发服务器，所以需要安装如下依赖：...