Task or Action
在整个开发生命周期内，有不少外部工具链提供诸如编译、打包、部署等能力，这些工具多是通过命令行来执行，如果一个个临时手动执行是一件比较繁琐的事情。为提高便捷性，vs code 制定了任务的标准规范，以task（以下皆称之为任务）为组织形式，通过脚本或进程的方式来执行外部工具链，完成任务目标，同时，vs code提供扩展开发以及统一的UI交互支持任务的开发和执行。通俗来讲，任务就是为了完成某一目标所提供的功能，和vs code提供的功能菜单类似，只不过这些"功能"要么是vs code提供，要么来自于用户自定义。
不过对于一个编辑器或者IDE而言，能够执行一个明确功能，同时又能在界面上触发它的，通常会是一个toolitem、menuitem，有的IDE更抽象的统称为action，用其表达一个IDE触发的动作。诚然，task经常在IT领域表示为一个命令的执行、一个进程，但在IDE的语境下，笔者觉得action比task更符合惯例。
任务的来源
因为存在tasks.json配置文件的缘故，给人的印象是任务都来源于这个配置文件，且会让人误解任务都需要在配置文件中自定义。其实，任务并非都出自自定义，这也会让一部分经常在应用开发中task开发人员有点不太适应。
vs code中的任务来源有三处，vs code自动侦测的任务、vs code插件自动侦测的任务、自定义任务。操作系统的任务可以有系统任务和用户任务，vs code的任务当然也可如是分类，只不过vs code自动侦测的任务、vs code插件自动侦测的任务相当于系统任务。
vs code目前针对Gulp, Grunt, Jake, Npm,Typescript 可以自动侦测任务，说的通俗一些就是vs code为这些技术内置了一些功能（任务），当vs code发现有与其对应的配置文件时，点击Run Task功能菜单，vs code会展现为该技术提供的任务，不仅如此，vs code会分析配置文件中的脚本命令自动识别成任务。如当打开一个npm工程，vs code会提供npm install任务，同时分析package.json文件，将配置文件中scripts声明的命令识别成任务。
vs code本身并不能完全支持所有开发场景，但是好在其支持插件扩展机制。目前有很多针对不同开发环境的vs code插件，通过任务提供器等API，插件可以提供相应的任务。当点击Run Task时，所有处于激活状态的插件将自动侦测，并向vs code提供当前可用的任务。如安装了c/c++开发插件，插件发现当前工作空间里有cpp文件，插件将向vs code提供c++文件编译等任务。
当vs code或其插件自动侦测出的任务无法满足需求时，就需要用户自定义任务了。自定义的任务就真的需要认真按规范配置.vscode/tasks.json了，并由vs code识别解析生成任务。
这么看来，对于大部分开发者而言，任务(task)理解为功能(function)是不是更加符合他们的习惯，毕竟vs code的使用者目前多聚焦在前端。对大部分开发者而言，很容易理解一个系统有内置的系统功能，并且也习惯给系统扩展自定义的功能。
任务和tasks.json之间的关系
上面说清楚了任务的来源范围，在此要强调的是，tasks.json里的任务并不是vs code当前所有的任务，它包含了两类任务，一是所有的自定义任务，二是经过个性化配置的自动侦测的任务（vs code自动侦测的任务、vs code插件自动侦测的任务），请对照任务的来源这节来理解这个范围。
也就说tasks.json里的任务是个性化配置后的任务，所以tasks.json的命名并不是很精准，这是个让部分用户不太适应的地方。凡是要让开发人员编辑的配置文件，往往是包含了工程中某类全部实体，比如npm的package.json 里面所依赖的包一定是全集，xml里声明的持久层的mapper一定是当前环境下的所有mapper，基于这样的习惯，tasks.json如果命名为configured_tasks.json就名副其实了。
vs code并不要求所有任务都必须在tasks.json中配置，运行任务的入口在Run Task菜单，如果要查看当前所有可用的任务，可以点击Run Task菜单来查看。
任务的配置
个性化配置任务的方式有二，一是直接编辑tasks.json文件，但是这个难度相对较高，需要很熟悉tasks.json的schema规范。常用的方法是通过Configure Tasks菜单，如果工作空间里没有tasks.json文件，vscode弹出配置向导，选择进入Create tasks.json file from template，向导会显示task模板，vscode默认提供四种模板：MSBuild、maven、.Net Core、Others，Others是一个通用模板，在不清楚哪种合适的情况下可以选择Others。
vs code在这个环节的交互有点反人类，本来通过配置向导来配置任务就是为了使用其模板能力，但是，如果已经存在了tasks.json文件，点击Configure Tasks却直接打开了tasks.json文件，vs code让你自己手动配置，使用者为什么就不能再次通过模板加个自定义任务呢？另外，在导航交互上也设计的让人摸不着头脑，点击Configure Tasks后向导显示的是根据当前环境vs code推断出的你可能想配置的任务（后面再加上Create tasks.json file form template选项），不了解这种展现规则的用户会不太适应，因为这种推导需要各种触发条件，比如当前打开的文件类型。本来vs code本意是好的，想让用户更加方便，但是推导的任务一会儿有一会儿无，让用户失去秩序感，你不能指望用户记住所有可能的触发条件。使用习惯后，用户才搞明白：哦，这些任务是推导出来的，不是每个场景都有，如果我想配置这个任务，我需要找到触发场景让vs code把它调出来。天啊，太不好用了。如果这个界面直接按着任务类型显示所有可用模板就更直接更好用了，实在是想秀一把智能推荐的能力，那就在上面标注一下：推荐。
