本地安装TypeScript时，package.json脚本中直接使用tsc无需npx即可运行的原理及相关疑问

咱们先从你最核心的疑问说起：为啥npm run build能直接用tsc，既不用全局装TypeScript，也不用加npx？

这其实是npm内置的一个贴心设计——当npm执行package.json里的脚本命令时，会自动把项目根目录下的node_modules/.bin目录临时追加到系统环境变量PATH的最前端。而你本地安装TypeScript（也就是npm install typescript -D这步）时，npm会自动在node_modules/.bin目录下生成一个tsc的可执行文件：Windows系统下是.cmd脚本，类Unix系统（比如Mac、Linux）下是可执行的shell脚本，这个文件会直接指向你本地安装的TypeScript包里的真正执行文件。

所以当你的脚本里写tsc时，系统会优先在node_modules/.bin里找到这个本地的可执行文件，自然就能直接运行，完全不需要额外的操作。

接下来聊聊你第二个问题：以后本地安装其他CLI工具，能不能也这么直接用？

当然可以！只要你本地安装的CLI工具（比如ESLint、Prettier、Vite这些）在安装过程中，会自动在node_modules/.bin目录下生成对应的可执行文件，你都可以直接在package.json的scripts里写工具的命令名，不用加npx。

举个实际的例子，你本地安装ESLint后，package.json的scripts可以这么写：

"scripts": {
  "lint": "eslint src/**/*.ts"
}

直接跑npm run lint就能调用项目本地的ESLint，完全没问题。

最后说说你好奇的第三个点：为啥有人明明可以直接用tsc，却还是偏好npx tsc？

这主要分几种常见场景：

• 在终端直接执行命令时：如果不是在npm脚本里，而是直接在终端输入tsc，这时候系统的PATH里并没有包含node_modules/.bin，自然找不到本地的tsc，这时候就得用npx tsc，让npm帮你定位到项目本地的可执行文件。
• 避免版本冲突：有些开发者习惯用npx来明确“我要调用的是项目本地的工具版本”，防止和全局安装的同工具版本冲突——比如你全局装了tsc 4.x，但项目本地用的是5.x，用npx tsc能确保你调用的是本地的5.x版本，不会误用到全局的旧版本。
• 个人操作习惯：还有一部分开发者不管场景，只要是调用本地工具就统一用npx，纯粹是长期养成的操作习惯而已。

内容来源于stack exchange