防护关键在于不让敏感值进入模块导出体系，应通过环境变量加载凭证、闭包封装连接实例、工厂函数返回能力而非明文配置，并遵循最小权限原则与运行时安全管控。
CommonJS 本身不提供运行时隔离或权限控制机制，模块间通过 require 导入导出数据是完全开放的。一旦数据库凭证（如 host、user、password）被写入某个 CommonJS 模块并 module.exports，任何能 require 它的地方就可直接读取——这本质上不是“传递泄露”，而是“暴露即可见”。防护关键不在阻止 require，而在于不让敏感值进入模块导出体系。
把凭证彻底排除在模块导出之外
模块不应以对象属性、函数返回值或全局变量形式向外暴露原始凭证。哪怕只导出一个含 password: 'xxx' 的 config 对象，就等于把钥匙放在门口。
- 配置模块只负责加载和组装，不直接暴露原始字段：例如用工厂函数生成连接实例，内部使用凭证，但对外只返回已初始化的
mysql.createConnection()实例或封装好的 query 方法 - 禁止
module.exports = { dbHost: '...', dbPass: '...' }这类明文导出；改用module.exports = () => createDbClient()，让调用方拿到的是能力，不是凭证 - 若必须导出配置对象，确保其字段已在加载时被移除或替换为占位符（如
password: ''），真实值仅保留在闭包或环境变量中
用环境变量替代模块内硬编码
Node.js 进程启动时从 .env 或系统环境读取凭证，模块内不存字符串字面量。这样即使模块被 require，也不会带出密钥。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 使用
process.env.DB_PASSWORD而非const DB_PASSWORD = '123456' - 搭配
dotenv加载时，确保.env文件未提交至 Git（加入.gitignore），且部署时由运维单独注入 - 在模块中做基础校验：
if (!process.env.DB_PASSWORD) throw new Error('DB_PASSWORD missing')，避免静默失败
利用闭包封装凭证生命周期
把数据库连接逻辑封装在立即执行函数或单例工厂中，让凭证只存在于函数作用域内，不挂载到 exports 或全局对象上。
- 示例：模块内定义
const client = mysql.createConnection({ password: process.env.DB_PASSWORD })，然后module.exports = { query: (sql) => client.query(sql) }—— 密码不出作用域，外部无法访问 - 避免将
client本身导出，防止调用方通过client.config.password反向提取 - 若需多处复用，用单例模式 + 私有变量，而非共享配置对象
配合服务端代理与最小权限原则
CommonJS 模块只是代码组织方式，真正安全依赖架构设计。前端绝不该接触数据库凭证，后端模块也应按职责隔离。
- 数据库连接只在数据访问层（DAO）模块中初始化，业务逻辑层只能调用
getUserById()等抽象方法，不知晓底层凭证 - 运行时限制 Node.js 进程权限：不以 root 启动，数据库账号仅授予必要表的 CRUD 权限，密码不复用其他系统
- 生产环境禁用
console.log输出含凭证的对象，日志统一走结构化采集，自动过滤敏感字段名（如 password、token）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
