JavaScript模块化中文件作用域天然隔离，需通过export/import显式共享，禁用window赋值、非严格模式this、with/eval，旧脚本可用IIFE模拟作用域。
模块化开发中，JavaScript 文件作用域本身就是一道天然屏障——每个 .js 文件默认就是一个独立的作用域，顶层声明的 let、const、function 不会自动变成全局变量。关键在于用对机制、不绕过封装，才能让这道屏障真正起效。
ES 模块（ESM）是默认隔离的基础
启用模块系统后，文件作用域自动生效：
- 在 HTML 中用
<script type="module">加载，或在打包工具（Vite/Webpack）中以模块方式解析，JS 引擎就会将该文件视为一个模块作用域 - 即使写
const api = 'https://api.example.com';在文件顶部，它也只在本文件内可访问，不会挂到window上 - 想被其他文件使用？必须显式
export；想使用别人的功能？必须显式import—— 没有“默认暴露”这回事
避免破坏模块封装的常见操作
即使开了模块，有些写法仍会悄悄逃出作用域：
- 不要在模块顶层直接给
window或globalThis赋值，比如window.utils = {...}—— 这等于主动把东西塞回全局 - 慎用
this：在模块顶层函数里，非严格模式下this可能指向window，造成隐式污染；加"use strict"可让顶层this为undefined，提前拦截风险 - 避免
with和eval：它们会动态扩展作用域链，使变量查找脱离模块边界，极难追踪泄漏点
跨模块共享需通过 export/import 显式约定
模块间通信不能靠“大家都去读 window.config”，而应由接口定义契约：
立即学习“Java免费学习笔记（深入）”；
- 配置集中管理：新建
config.js，export const API_URL = '...'; export const TIMEOUT = 5000; - 工具函数统一导出：
utils.js导出debounce、deepClone等，其他文件按需import { debounce } from './utils.js' - 禁止“半模块化”：不要一部分用
import，另一部分又靠script标签引入未模块化的老库并依赖其全局变量，这种混合容易让模块的隔离形同虚设
兼容旧环境时的平滑过渡策略
若项目暂未全量模块化，可在非模块脚本中模拟文件作用域效果：
- 对单个传统脚本，用 IIFE 包裹：
(function() { "use strict"; /* 原有代码 */ })();，人为创建私有作用域 - 对第三方库，优先选用其 ESM 版本（如
import Chart from 'chart.js'），而非<script src="chart.min.js">全局加载 - 必须加载全局脚本时，立即将其挂入命名空间并清理：加载后执行
const MyChart = window.Chart; delete window.Chart;，后续只通过MyChart访问
