javascript模块作用域天然隔离变量，每个模块拥有独立顶层作用域，变量默认私有、不共享、不污染全局；es module和commonjs均通过语言机制实现隔离，依赖显式导出导入来共享数据。
JavaScript 模块作用域天然隔离变量，靠的是每个模块拥有独立的顶层作用域，变量默认不暴露、不共享、不污染全局。这不是靠手动管理，而是语言机制决定的——只要用 import/export 或 require，模块边界就自动生效。
ES Module 默认私有，变量不出模块就不可见
每个 .js 文件（被当作 ES 模块加载时）自带独立作用域。里面用 let、const、function 声明的变量，从一开始就不在全局或别的模块里存在。
- 没加
export的变量，外部连名字都查不到，for...in、Object.keys()都遍历不到 - 即使两个模块都声明了
const apiBase = 'https://a.com'，它们互不影响，不是冲突，而是完全不同的绑定 - 模块内
this指向undefined（严格模式下），不会意外挂到全局对象上
CommonJS 也隔离，但需注意函数包裹
require 加载的模块，在 Node.js 中实际被包裹在一个函数里执行（类似 (function(exports, require, module, __filename, __dirname) { ... })），所以顶层声明的变量自然局限在此函数作用域内。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
var foo = 1;、const bar = 2;都不会泄漏到全局 - 真正能被其他模块拿到的，只有显式赋值给
module.exports或exports的内容 - 模块内部的
require是局部的，不会影响其他模块的依赖解析
避免“假共享”：别把模块当命名空间滥用
模块不是容器，不能靠“同名变量”实现跨模块通信。错误做法是：一个模块里改 window.config，另一个去读——这绕过了模块机制，破坏隔离。
- 想共享数据，就用
export明确导出，用import显式引入，让依赖关系可追踪 - 配置类变量建议封装成函数返回值（如
getConfig()），而不是直接export const config = {...}，便于运行时控制 - 不要在模块顶层做副作用操作（比如直接调用
init()），应导出函数，由使用者决定何时调用
动态导入与作用域边界依然清晰
import() 返回 Promise，加载的模块仍遵守相同规则：它的变量只在自己模块内有效，导出什么、怎么用，全由 export 和解构/属性访问控制。
-
import('./utils.js').then(m => m.helper())—— 只能调用它export出来的方法，拿不到它的私有cache或token - 多次
import()同一路径，模块代码只执行一次，但每次返回的都是同一套导出对象，变量状态共享符合预期（不是重复初始化）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
