生产环境是否推荐使用npm link？使用存在哪些风险？

核心结论 #

npm link 仅适用于本地开发调试场景，绝对不能用于生产环境。它的设计定位就是方便本地开发时快速调试本地依赖包，没有为生产环境的稳定性、可复现性做任何适配。

生产环境使用npm link的典型问题 #

• 依赖版本不可控：npm link 本质是创建操作系统级的软链接，指向你本地的包开发目录，只要这个目录的代码被修改、删除、覆盖，所有关联了这个软链接的生产项目都会立刻受影响，完全无法锁死依赖版本，极容易出现无预兆的线上故障。
• 部署流程不可复现：每部署到一台新机器，你都需要手动维护对应包的目录路径、手动执行npm link命令，任何一步出错都会导致项目启动失败，不符合生产环境标准化、可自动化、可复现的部署要求。
• 运行/构建异常：不同版本的Node.js、打包工具（如Webpack、Vite）对软链接的依赖解析逻辑存在差异，可能出现依赖重复打包、模块找不到、上下文不一致的问题，这类问题在本地很难复现，排查成本极高。
• 安全风险：软链接可能带来权限逃逸隐患，如果被链接的包目录配置了过高的读写权限，攻击者可以通过篡改包代码直接入侵线上业务。

生产环境复用私有包的推荐方案 #

• 发布到私有npm源：如果是团队内部复用的包，可以在内网搭建私有npm源，将包发布后在业务项目中直接通过npm install <包名>安装，还可以通过package.json的版本号精确锁定依赖版本，稳定性有保障。
• 本地路径/压缩包依赖：如果不想搭建私有源，可以将包打包为tar压缩包，在package.json中直接指定依赖的本地路径，npm安装时会直接复制包代码而非创建软链接，不会受本地目录变更影响。
• Monorepo架构管理：如果多个关联项目都在同一个代码仓库中，可以使用pnpm Workspace、Turborepo这类Monorepo工具管理内部依赖，天然支持内部包的高效复用，不需要额外配置软链接。

npm link 正确使用姿势 #

只有本地开发调试时使用即可：在公共包的开发目录执行npm link创建全局软链接，然后到需要调试的业务项目目录执行npm link <包名>关联，调试完成后及时执行npm unlink <包名>解除关联，再安装正式发布的包版本即可。

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