一、关于 npm ls --prod / --dev 的使用条件结论几乎没有苛刻条件是最安全、最通用的依赖查看命令。1. 基础环境只要正常安装了 npm随 Node.js 安装项目根目录有 package.json 和 node_modules 即可执行。2. 核心作用◦ npm ls --prod只展示 dependencies 里的依赖树过滤掉 devDependencies帮你快速确认“生产环境真正装了哪些包”。◦ npm ls --dev只展示 devDependencies 里的依赖树帮你梳理“开发工具链依赖”。3. 特殊场景适配◦ 若项目用 yarn可替换为 yarn list --prod / --dev逻辑一致。◦ 若想精简输出可加 --depth 0只看顶层依赖不展开深层比如 npm ls --prod --depth 0更易阅读。4. 避坑提醒◦ 不要在全局安装的目录如 /usr/local/lib/node_modules执行只在项目根目录执行。◦ 若 node_modules 损坏先执行 npm install 重建再执行该命令。二、关于 depcheck 的“不准”与依赖删除逻辑depcheck 确实有局限性它的“missing dependency”不能直接当“可删”依据核心原因如下1. depcheck 的本质局限◦ 它是静态语法分析只扫代码里的 import/require对动态引入如 require(variable)、Webpack 别名alias、配置文件引用比如 webpack.config.js 里的 loader完全无感。◦ 它把 dependencies 和 devDependencies 混为一谈无法区分“生产必须”和“开发工具”。2. 正确的依赖删除逻辑结合你的场景◦ 第一步先做依赖分类用 npm ls明确 dependencies 生产必须上线后代码运行必需devDependencies 开发工具打包、测试、lint 用。◦ 第二步用 depcheck 做“辅助排查”只看它报的 unused devDependencies开发工具里没用到的可以安全删除对 unused dependenciesdependencies 里的一律忽略必须人工验证◦ 第三步人工验证最关键对 dependencies 里的包问自己一句“生产环境如果删掉这个代码会报错吗”◦ 若报错比如 react、axios、antd→ 保留◦ 若不影响运行比如旧版测试工具、废弃的 loader→ 可删。3. 为什么 depcheck 报 missing 不准missing 表示“代码里 import 了但 package.json 没装”这是依赖缺失问题跟“无用依赖”完全是两码事不能用来判断“能不能删”。
