幽灵依赖是代码中import/require未在package.json显式声明的包，因npm/yarn扁平化机制侥幸运行，导致构建失败等风险；pnpm通过符号链接与.pnpm隔离目录强制依赖显式化，启用严格模式、depcheck检查及定期审计可系统性规避。
幽灵依赖不是“用了没声明”那么简单，而是项目代码直接 require 或 import 了未在 package.json 中显式列出的包，却因 npm/yarn 的扁平化机制侥幸运行成功——这种侥幸会带来构建失败、安全漏报和环境不一致等真实风险。避免它，核心是让“能用”和“合法可用”真正统一。
用 pnpm 替代 npm/yarn
pnpm 通过硬链接 + 独立 .pnpm 目录结构，从根本上切断了幽灵依赖的路径：
- 只有
package.json中dependencies或devDependencies声明的包，才会出现在node_modules/根目录下（以符号链接形式） - 间接依赖（如
a → b → c中的c）只存在于node_modules/.pnpm/的隔离子树中，项目代码 无法直接 require('c') - 一旦你写了
require('c')，pnpm 会立刻报错Cannot find module 'c'，强制你在package.json中补上依赖
启用严格模式与检查工具
即使继续用 npm，也能大幅降低幽灵依赖风险：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 运行
npm ls <package-name></package-name>查看某个包是否属于直接依赖，还是仅由其他包带入（输出中带extraneous或显示多层缩进即为间接引入） - 添加脚本到
package.json："check-phantom": "npm ls --depth=0"，只列出顶层依赖，快速核对代码中使用的包是否都在其中 - 配合
depcheck工具扫描未声明但被引用的包：npx depcheck --ignore-bin-package --ignores=@types/*
养成显式声明的习惯
不要因为“现在能跑通”就跳过声明步骤：
- 只要代码里
import或require了某个包，不管它是不是别人依赖的子依赖，都应执行npm install <pkg> --save</pkg>（或pnpm add <pkg></pkg>） - 特别注意：像
lodash/cloneDeep、axios/lib/adapters/http这类子路径导入，本质仍是使用该包，必须声明主包依赖 - 对类型包（
@types/xxx）也需显式安装到devDependencies，否则 TypeScript 编译可能误用隐式类型
依赖锁定与定期审计
幽灵依赖常在更新中悄然出现，靠一次清理不够：
- 确保
package-lock.json（npm）或yarn.lock存在且提交到仓库，它能固定间接依赖的实际版本，防止 CI 环境中因提升顺序不同导致幽灵包消失 - 每月执行一次
npm audit --audit-level=moderate，它会扫描整个依赖树（含幽灵依赖），及时发现隐藏漏洞 - 升级大版本前，先运行
npm outdated，再结合npm ls <pkg></pkg>检查该包是否从间接变为了直接使用，决定是否需要同步调整声明
