linux运维中node.js依赖管理首选pnpm，因其部署一致性高、磁盘占用低、权限可控；须用--frozen-lockfile安装、集中store路径、每日audit巡检并monorepo下filter精准部署。
在 Linux 运维场景中，管理 Node.js 服务端的包依赖，核心目标是：**稳定、可复现、低风险、易维护**。npm 和 pnpm 都能完成基础任务，但运维侧更看重部署一致性、资源控制和长期可维护性——pnpm 在这些方面有明显优势。
部署阶段必须用严格安装模式
生产环境绝对不能用 npm install 或 pnpm install（无参数），否则会根据 package.json 动态解析依赖，可能引入意外版本或跳过 lock 文件校验。
-
npm 推荐命令：
npm ci --no-audit --prefer-offline
强制按package-lock.json安装，清空旧node_modules，禁用安全扫描（避免 CI/CD 卡住），优先走本地缓存 -
pnpm 推荐命令：
pnpm install --frozen-lockfile --no-optional
严格比对pnpm-lock.yaml，拒绝任何自动更新；--no-optional跳过可选依赖（如 fsevents），减少 Linux 环境兼容问题
多项目共存时磁盘与权限要统一规划
运维常需在同一台服务器部署多个 Node.js 服务（如 API 网关、定时任务、监控上报等）。npm 每个项目都复制全套依赖，极易撑爆 /var 或 /home 分区；pnpm 的全局 store 机制天然适合这种场景。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- pnpm 默认 store 路径为
~/.pnpm-store，建议改为集中路径，例如：sudo mkdir -p /opt/pnpm-storeecho "store-dir=/opt/pnpm-store" >> ~/.pnpmrc
再用sudo chown -R deploy:deploy /opt/pnpm-store统一属主 - 避免用 root 全局安装包（如
pnpm add -g pm2）。应以部署用户（如deploy）身份操作，并通过~/.bashrc配置PATH加入~/.local/share/pnpm
依赖审计与漏洞响应要闭环
服务上线后，不能只管启动，还要持续跟踪依赖安全状态。npm 和 pnpm 都支持 audit，但结果解读和处置逻辑不同。
-
npm audit --audit-level=high输出高危及以上漏洞，配合npm audit fix --force可自动升级（但可能破坏兼容性，不建议直接用于生产） -
pnpm audit --audit-level=critical更精准，只报关键级；若需修复，优先用pnpm update <pkg> --interactive</pkg>手动确认版本，或结合pnpm patch <pkg></pkg>打临时补丁（适合无法立即升级的 LTS 服务） - 建议将
pnpm audit加入每日巡检脚本，输出到日志并触发企业微信/钉钉告警
Monorepo 服务部署要启用 workspace 隔离
越来越多后端服务采用 Monorepo 结构（如一个仓库含 auth、user、notify 多个子服务）。此时不能简单跑 pnpm install，否则所有子包依赖都会混在一起。
- 确保根目录
pnpm-workspace.yaml正确定义范围，例如：packages:<br> - "packages/*"<br> - "services/**"
- 部署单个服务时，进入对应目录执行：
pnpm --filter ./services/auth... install --prod
（...表示包含其所有依赖） - 配合
pnpm run build --filter ./services/auth构建，生成精简产物，避免把 devDependencies 打包进 Docker 镜像
