在 package.json 中配置 main 字段时，应将其指向项目的入口文件路径。对于使用 es modules (esm) 的项目，通常建议将 main 指向编译后的 esm 格式文件（如 .mjs 或带 .js 扩展名且顶层包含 export 的文件），同时配合 type: "module" 声明或文件名后缀来确保 node.js 正确解析。这样做能让依赖方通过标准的 import 语法引入你的模块。
Node.js 环境下的 main 字段与 type 声明如何配合？
在 Node.js 环境中，main 字段的值决定了模块加载的起点。如果项目根目录的 package.json 设置了 "type": "module"，那么所有 .js 文件默认都被视为 ESM，此时 main 可以直接指向一个 .js 文件。如果没有设置 type，则 .js 文件默认为 CommonJS (CJS)，此时若要通过 main 暴露 ESM，必须使用 .mjs 后缀，或者在 package.json 中使用 exports 字段进行更精细的控制。最稳妥的方式是明确指定文件类型，避免歧义。
{
"name": "my-esm-package",
"version": "1.0.0",
"type": "module",
"main": "./dist/index.js",
"exports": {
".": "./dist/index.js"
}
}
上述配置中，"type": "module" 告诉 Node.js 将所有 .js 文件当作 ESM 处理。main 指向 ./dist/index.js，这是构建后生成的 ESM 入口文件。当其他项目使用 import { ... } from 'my-esm-package' 时，Node.js 会读取 package.json，找到 main 指定的路径，并以 ESM 模式加载该文件。如果未设置 type，则需将 main 指向 ./dist/index.mjs。
浏览器环境下 main 字段与 exports 字段的关系是什么？
在现代前端开发中，仅靠 main 字段已不足以覆盖所有场景，尤其是浏览器和打包工具（如 Webpack、Vite）对 ESM 的支持。推荐使用 exports 字段来定义不同环境的入口点。main 字段主要向后兼容旧版 Node.js 和包管理器，而 exports 提供了子路径导出能力。对于纯 ESM 库，可以将 main 和 exports["."] 都指向同一个 ESM 文件，确保一致性。浏览器通过 <script type="module" src="..."></script> 引入时，也会遵循 exports 的定义。
{
"name": "my-esm-package",
"version": "1.0.0",
"type": "module",
"main": "./src/index.js",
"exports": {
".": "./src/index.js",
"./utils": "./src/utils.js"
}
}
在这个配置中，main 指向 ./src/index.js，作为默认入口。exports 对象定义了主入口 "." 和子路径 "./utils"。当开发者导入 import { helper } from 'my-esm-package/utils' 时，包管理器会查找 exports 中匹配的键，并返回对应的文件路径。这种结构确保了 ESM 语义的完整性，避免了 CJS/ESM 混合带来的问题。注意，exports 中的路径必须精确匹配，不支持通配符以外的复杂模式。
当 main 字段指向的文件不存在时会发生什么？
如果 main 字段指向的文件在磁盘上不存在，Node.js 或包管理器在解析模块时会抛出 MODULE_NOT_FOUND 错误。例如，若 main 设置为 "./dist/index.js"，但构建步骤未生成该文件，运行 node -e "import('my-esm-package')" 将失败。为避免此问题，应在发布前确保构建流程完整，或使用 files 字段明确包含所需文件。此外，exports 字段中的路径同样需要存在，否则子路径导入也会报错。建议在 CI/CD 流程中加入文件存在性检查，确保发布的包结构正确。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
