npm 默认不将 devdependencies 安装到生产环境，因它们仅用于开发构建测试，不参与运行时逻辑；通过 npm install --production 或 node_env=production 可确保跳过 devdependencies，避免资源浪费与安全风险。
npm 不会、也不应该把开发依赖（devDependencies）自动安装到生产环境——这是设计上的明确隔离，不是操作遗漏。
为什么 devDependencies 默认不进生产环境
开发依赖如 vite、eslint、typescript、jest 等，只在编码、构建、测试阶段起作用。它们不参与最终运行时逻辑，体积大、可能含调试工具或命令行入口，放进生产环境不仅浪费资源，还可能引入安全风险或启动失败。
npm 通过以下机制保障隔离：
-
npm install（无参数）默认只装dependencies和devDependencies——但仅限于你当前执行命令的环境； -
npm install --production或NODE_ENV=production npm install会跳过 devDependencies，只安装dependencies； - CI/CD 流水线或 Docker 构建中常显式加
--production标志，确保精简部署包。
哪些情况会“意外”把 dev 依赖带到线上
不是 npm 的行为出错，而是人为配置或流程疏漏：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在服务器上直接运行
npm install（没加--production），且项目里又没设NODE_ENV=production； - 误把本该是
devDependencies的包装进了dependencies（例如执行了npm install xxx没加-D）； - Dockerfile 中用了
COPY . . && npm install，但没切换环境变量或没清理node_modules缓存； - 某些打包工具（如 Vite）的
build脚本若依赖devDependencies中的插件，而构建过程又在生产机上执行，就会间接“需要”它们——但这属于构建阶段，不是运行时依赖。
如何确认和修复
检查当前已安装的依赖是否混入了开发包：
-
npm list --depth=0：看一级依赖列表，区分哪些标为dev； -
npm ls --production --depth=0：只显示真正会进生产的依赖； - 打开
package.json，核对"devDependencies"字段下的包是否确实不该出现在线上； - 部署前执行：
NODE_ENV=production npm ci --only=production（推荐，比install更干净，且基于package-lock.json）。
真有需求让某个 dev 工具在生产运行？谨慎评估
极少数场景（如运行时动态编译、A/B 测试配置热加载）可能需要类似 esbuild 或 swc 的工具在服务端参与处理。这时应：
- 明确它已是运行时必需能力，移入
dependencies； - 避免用
--save-dev安装； - 在代码中按需引入，并做好错误降级；
- 写清楚文档说明该“原属 dev”的包为何升为生产依赖。
本质上，npm 的依赖分层是语义化的设计，不是限制。守住 devDependencies 的边界，才是稳定交付的关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
