嗨，这个问题我之前踩过坑，其实本质是npm脚本的执行环境设计和项目依赖一致性这两个核心原因导致的，给你拆解清楚：

1. npm脚本的PATH搜索优先级问题 #

当你运行npm test这类脚本时，npm会构建一个专属的执行环境，它会把项目根目录下的node_modules/.bin目录放到环境变量PATH的最前面。这意味着，当脚本里调用ts-node或者tsc命令时，npm会优先在本地的node_modules/.bin里找对应的可执行文件——如果本地没装，它不会自动去全局包的目录（比如npm prefix -g输出路径下的bin文件夹）里搜索，直接就抛出「Cannot find module 'typescript'」的错误了。

简单说：npm脚本的命令搜索逻辑是本地优先，不主动 fallback 到全局。

2. 项目依赖一致性的最佳实践 #

即使能让npm脚本用上全局包，也不推荐这么做。本地安装依赖的核心目的是：让项目的依赖版本完全可控，确保团队里每个成员、甚至CI/CD环境运行项目时，用的都是同一个版本的typescript/ts-node。如果依赖全局包，每个人的全局版本可能不一样，很容易出现「我本地跑没问题，你那边就报错」的尴尬情况。

有没有办法让全局包在npm脚本里生效？ #

如果实在想临时用全局包，有两个小技巧：

• 在脚本里直接写全局包的绝对路径，比如/usr/local/bin/ts-node your-test-file.ts，但这种方式不跨平台，也不灵活；
• 用npx来调用，比如脚本写成npx ts-node your-test-file.ts——npx会先找本地的包，找不到就去全局找，甚至还能临时下载对应版本，不过还是建议本地安装来保证一致性。

内容的提问来源于stack exchange，提问作者chen