7.技巧如何制作配图及相关素材

这一节着重讲下技术写作中可以帮助文章质量变得更好的素材的使用技巧和制作方法。

这里的素材包括下面这几类：

• 代码片段；
• 辅助图片；
• 演示视频；
• 在线案例。

下面一个一个介绍下。

代码片段

关于代码片段，其实没什么好说的，复制粘贴，基操皆会。

这里额外说两个可能不太注意的小点。

优先使用代码块功能

尽量不要直接往编辑器中粘贴代码。

几乎所有的写作平台，专业的技术写作平台就不用说了，包括公众号、头条号这样的全行业自媒体平台都提供了插入代码块的功能（下图截自掘金写作编辑器），使用这个入口插入代码块，代码的排版会更好，样式会更美丽。

除非是平台没有提供代码块的能力，如百家号，那我们才需要尝试复制已经高亮好的代码块粘贴到编辑器中。

代码需精简

技术文章中的代码块务必要精简，除非是专门提供给读者复制用的完整代码。

按照我个人的写作经验，大多数的代码块都是帮助读者更好地理解技术用的，注意这里的作用，是帮助理解，不是给用户白嫖！

所以，代码一定要把不必要的干扰去除，保留核心，在不影响读者理解的情况下尽可能地精简。

我见过太多的技术文章，先是介绍一个技术点，然后“啪”地一下子甩过来一整屏密密麻麻的代码，看得眼睛生疼，结果有用的就中间一段内容。

是作者不知道这样不友好吗？不是的，实在是不愿意多花这份精力，做事呢，总是八十分万岁，多一分受罪的心态，无法做到极致。🤷‍♂️

这里我多讲两句吧，希望不要嫌我啰嗦，其实无论是代码精简也好，还是下面要讲的配图制作也好，为什么很多人做不下去，因为它属于预期精力开销以外的东西，虽然做这些事情花的时间其实并不多。

这是人的正常心理，比方说你今天去小广场吃牛肉拉面，预期是 20 块钱，结果发现要 28 块钱一碗，你还会吃吗？很多人就不会去吃，因为这个价格超出了心理预期。

但是日料店的豚骨拉面 68 元一份却吃得很欢，一点也不觉得贵，就是因为价格预期高。

实际上理性思考下，这种心态其实是不对的，钱就是钱，68 元的东西一定比 30 元的贵，不会因为预期高低而发生变化。

我们日常做事也是如此，你要想做到极致，一定会有很多意想不到的细节工作去做，这些都属于超出预期的精力，很多人就不愿意做，他宁可花大把的时间和精力做十件平庸的事情，也不愿意做一件极致的事情，非常的不理性，典型的用身体上的勤劳来慰藉心理上的懒惰，最终往往一事无成，反而还抱怨世间不公。

配图很重要

按作用分，技术文章的配图大致分为这几种：示意图、表情图和视觉图。

其中，示意图是技术文章中最重要也是最常见的配图，多以截图为主，毕竟截图省心省力，一些用心的创作者还会自制示意图，比方说我经常就会使用 PS 或其他工具绘制示意图。

关于截图

在 Windows 系统，我都是使用 FastStone Capture 进行截图的，可以给截图添加水印、高亮、模糊和箭头示意，很方便的小工具。

在 OS X 系统下，可以使用 iShot 这个截图工具，我用过，还不错。

另外，一些聊天工具的截图功能也是很好用的，例如 QQ 或者企业微信，优点是本身就有，不需要额外安装，该有的基本功能都有。

如果大家也有自己认为不错的截图工具推荐，可以通过评论的方式告知。

自制线框图

无论你是要绘制流程图还是逻辑图，无可争议，最好用的一定是 FigJam，这是一个在 Figma 中使用的白板协作工具。

跨平台，免安装，体验极为流畅。

在浏览器地址栏输入网址 figjam.new 或 figma.com/jam 即可访问。

上一小节出现的写作框架示意图就是使用这个工具绘制的。

关于表情图

合适的表情包可以让文章更加生动有趣，但是需要注意一点，表情包图片一定不要多，尤其那种会动的 GIF 表情包要谨慎使用。

一是因为动图太多吸引过多的注意力会让人心生厌烦，二是动图的尺寸都很大，会严重影响文章内容的加载速度。

另外我还观察到了一个常见的问题，就是文章段落中插入的表情图尺寸太大了，一个表情图就占了一整个手机屏幕，这肯定是不行的。🙅‍♀️

表情包属于锦上添花的东西，目的是传达情绪，营造氛围，占据这么大篇幅，显然喧宾夺主了。

我猜测可能是因为平台没有提供图片尺寸拉伸的能力，比方说掘金的写作平台，此时，可以多上点心，使用工具提前优化图片的尺寸。

足够用心的人，甚至会将所有的表情包图片限制成一个尺寸规格。

版权问题

配图素材不容忽视的一个大问题就是版权问题。

其中，版权风险最大的就是视觉图。

很多平台会提供文章头图的功能，发布后会显示在文章的最上方，这个头图就属于视觉图，起到美化装饰的作用。

还有一类视觉图是出现在正文中的，避免一看眼过去全是文字，缓解视觉疲劳，提高阅读体验。

这些图片多是优美的实物图片，或优美的风景，或精致的人物，虽赏心悦目，却暗藏版权风险。

有人会说，我这图片都是从 pixabay 这类免费网站下载的，是可以免费商用。

太单纯了，这些图片都是用户上传的，版权并不能得到保证，尤其是那些有人物出现的照片，一定要谨慎使用，尤其当你希望通过写作获得收益的时候。

另外，严格来讲，所有的表情包图片都是有版权的，除非是你自制的图片，因此，如果你是商业写作，一定要避免使用。

还有 emoji 图片（非 emoji 字符）也是有版权的，不要随便使用。

当然，风险归风险，如果你是单纯地出于学习目的的创作，那些烂大街的表情包和梗图其实是可以放心使用的，因为被追责的概率小到可以忽略不计。

全中国这么多网友使用这些表情包，再怎么追责也不会轮到你这个小透明。

但是，那种明显经过专业设计的表情图、人物摄影照片需要引起重视，能不使用就不使用。

另外，有些自媒体平台在创作的时候提供了免费的素材库资源，请注意，这些资源只能在当前平台使用，切勿共享到其他平台，否则可能会有版权纠纷。

视频的局限

大多数情况下，我们使用静态截图去示意讲解的内容就足够了，但是，如果是某些交互效果的实现，你想让用户知道你最终实现的效果，或者深入分析原理的时候希望用户知道你描述的现象，那么一定是 GIF 录屏或者视频录屏的效果更好。

录屏工具推荐

在 windows 系统中，对技术写作最友好的录屏工具，无可争议，一定是 screenToGif，这是一个开源软件，GitHub地址：https://github.com/NickeManarin/ScreenToGif

用一句话形容 screenToGif 的话就是“强到爆炸💥”，不仅录屏可以转 GIF，还可以转 APNG 和 MP4，体积小到难以置信，非常适合在 Web 中传播！

对于Mac设备，虽然原生的 QuickTime 提供了录屏能力，但是默认是 MOV 格式的，体积相当大。

此时可以试试使用上面提到的截图工具 iShot，支持录屏为 MP4 格式。

但是 iShot 并没有保存为 GIF 格式的能力，一种方法是使用 MP4 转 GIF 的工具，但这样处理太麻烦了，我的话是使用的 GIPHY CAPTURE 实现 GIF 录屏的。

GIPHY CAPTUR 这个软件……怎么说呢，能用吧，可以满足基本的需求，但是和 screenToGif相比还差了十个 iShot。

GIF 还是 MP4？

如果你的录屏画面颜色简单，没有那种绚丽的色彩，则毫无疑问，一定是使用 GIF 录屏。

因为 GIF 动图最多支持 256 色，颜色过于丰富会严重失真，同时 GIF 的体积特别的大，此时，肯定是使用 MP4 视频是最好的，颜色高保真，体积只有 GIF 的十分之一（screenToGif 多年使用亲测）。

然而，视频素材有一个非常现实的问题，那就是几乎所有的写作平台都不支持上传视频，顶多是支持外链视频。

因此，视频演示虽好，但是却是牛奶拌豆腐——白搭，用不了，只能使用 GIF 演示。

然后很多平台会自动给图片加水印，静态图还好，但如果是 GIF 图片，由于本身颜色位数就有限，再去融合带有半透明信息的水印图片，GIF 图片会进一步失真，甚至可以严重到了无法预览的地步，比方说大片的绿色的色块一闪而过。

此时还不如上传几个关键帧序列图来得友好。

这个时候，就可以体现自建写作平台的优势了，比方说我的博客就经常内嵌 MP4 演示视频，因为没有限制，所以理论上什么资源都可以往上放。

注意，这里是理论上，实际上并不是，我只有在 GIF 示意图大于 200K 的时候才会使用视频，原因很简单，省钱。

因为我是自建平台，所有流量费都是从自己的腰包里出来的，因此必须关注资源的开销。

这里讲个大家可能不知道的事情，我博客中的所有 PNG 和 JPG 图片的体积都是最优的，提前手动压缩好的。

如果是超过 100K 的 GIF 动图，我会显示静态 PNG 图，点击才去加载 GIF。超过 500K 的 MP4 视频要么不放，要么就是使用 iframe 内嵌外部视频网站的视频。

所有的图片都会写上 Alt 占位信息，所有的图片显示宽度绝不会超过 728px。适合使用 GIF 示意的场景一定会录制 GIF，绝不会偷懒使用静态图片。

以上这些工作都是要花费额外的精力的，虽然每件事情的精力不是很多，但是非常琐碎与枯燥，多了之后，非常挑战人的毅力，很多人就没法做到这一点，正如上面提到的代码精简和自制示意图。

所以，请思考一下，那么多同主题的文章，为什么别人更愿意看你写的文章？普通文章和精品文章的区别在哪里？为什么精品文章那么少，会不会和很多人无法做到尽善尽美有关？

在线演示

一图胜千言，一例胜千图，也就是100 张截图不如一个案例演示来的更直观。

比方说我们要介绍某种很酷的动画效果，你粘贴代码，截图示意，远不如提供一个在线演示页面地址的帮助大。

包括说，你工作中遇到不理解的或者无法解决的技术问题，想要请教别人，最好的方式就是给对方发现个在线地址，别人一点击就看到你写的代码，大家都省心省力。

千万不要说是发个 rar 压缩包过去，非常得不友好。

这里，推荐几个适合在线演示的网站。

● 如果是偏视觉、偏交互效果的在线演示，推荐使用 https://codepen.io/ 这个平台。

● 如果是 JS 代码运行，可以试试https://jsbin.com/这个站点，优点是即开即用，非常爽气，缺点是好久没更新了，对于新特性的识别有问题，适合纯 Web 演示。 还有个同时期的名叫jsfiddle.net的网站，这个网站并不推荐用在技术写作中，因为不知道触犯了哪条红线，国内访问一直有问题。

另外，jsbin 还有个非常哇塞的优点，就是其本身是个纯开源的项目，可以零成本搭建在自己的平台或者公司内部。

● 如果运行代码依赖于框架或环境，可以试试 codesandbox.io 这个平台，不仅支持纯 JavaScript 的运行，还可以模拟在 Vue、React/Preact、Svelte 等框架，或者在 Node.js 等环境下的运行。

● 如果是 Node.js 运行，也可以考虑https://runkit.com/ 这个平台，不过我自己没使用过，不做评价。

由于大多数的写作平台都不支持内嵌 iframe，因此，直接在文章中外链这些演示页面的地址就好了，读者是不介意多点击一次，或者在地址栏中多粘贴一次地址的。