在ES模块中，import语句会完整执行目标文件的顶层（top-level）同步代码，因此类定义外的 new HomeTask().init() 会在导入时立即运行，与是否使用该类无关。
在es模块中，`import`语句会完整执行目标文件的顶层（top-level）同步代码，因此类定义外的 `new hometask().init()` 会在导入时立即运行，与是否使用该类无关。
当你编写如下代码：
// homeTask.ts
export class HomeTask extends ITask {
run = async (): Promise<Record<string, any>> => {
// 实际业务逻辑
}
}
new HomeTask().init(); // ⚠️ 顶层副作用：导入即执行！并执行：
import { HomeTask } from '../tasks/homeTask';TypeScript/JavaScript 并不会“仅加载类声明”，而是完整解析并执行整个模块脚本——包括所有顶层表达式、函数调用、变量赋值等。这是 ES 模块规范（ECMAScript Modules）的明确行为：模块是单例、一次性求值的，其顶层语句在首次 import 时同步执行。
✅ 正确做法：消除顶层副作用
所有非声明类/函数/类型/导出语句的可执行逻辑都应封装进函数或条件分支中，确保按需触发：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
// homeTask.ts
export class HomeTask extends ITask {
run = async (): Promise<Record<string, any>> => {
// 保持核心逻辑不变
}
}
// ✅ 方案1：导出初始化函数（推荐用于测试/调试）
export function initHomeTask(): void {
new HomeTask().init();
}
// ✅ 方案2：仅在特定环境运行（如 Node.js CLI 场景）
if (typeof require !== 'undefined' && require.main === module) {
// 仅当该文件被直接执行（node homeTask.ts）时才运行
new HomeTask().init();
}
// ✅ 方案3：延迟初始化（配合 DI 或启动生命周期）
export function createAndInitHomeTask(): HomeTask {
const task = new HomeTask();
task.init();
return task;
}随后在使用处显式调用：
import { HomeTask, initHomeTask } from '../tasks/homeTask';
// ✅ 按需调用，不再自动触发
// initHomeTask();
// 或实例化后手动控制
const task = new HomeTask();
task.init(); // 显式初始化更清晰、可测试、易调试⚠️ 注意事项
-
不要依赖
import的“惰性”：ESM 没有“仅类型导入”或“仅声明导入”的运行时概念（type-onlyimport 如import type { X } from 'y'是编译期擦除，不触发执行，但不可用于运行时实例化）。 -
避免在工具链中误用
require()替代：require()是 CommonJS 行为，与 ESM 不兼容；混合使用易导致循环依赖或执行顺序混乱。 -
构建工具无法自动优化掉副作用：即使你只用
import { HomeTask }，Webpack/Vite 等打包器默认仍会保留并执行模块顶层代码（除非配置sideEffects: false且文件纯声明，但含new调用则必然视为有副作用）。
✅ 总结
模块顶层的 new HomeTask().init() 不是“类的一部分”，而是独立的副作用语句。ES 模块的设计哲学是“导入即执行”，而非“导入即声明”。解决根本问题的方式只有一个：将所有非声明性逻辑移出顶层作用域，封装为导出函数或受控入口。这不仅修复了意外执行问题，也显著提升了代码的可测试性、可维护性与职责清晰度。
