问题——模块“出口”混乱成为高频故障源 随着Node.js在服务端开发、工具链和工程化体系中被广泛使用——模块导出机制上的细微差别——越来越容易变成影响项目稳定性的关键点；实践中，不少开发者在编写模块接口时混用exports与module.exports，甚至为了省事直接给exports整体赋值，导致调用端通过require()拿到的内容与预期不一致：轻则方法缺失，重则出现“对象不可作为函数调用”等类型错误，排查成本随之上升，交付节奏也会被拖慢。 原因——引用关系与“覆盖”操作被忽视 问题的核心在于：exports与module.exports并不是两个独立的“出口”。模块初始化时，exports只是module.exports的一个引用，通常指向同一个默认对象。此时，在exports上追加属性，本质上就是在module.exports指向的对象上扩展成员，调用端也就能按预期访问。 但一旦对exports重新赋值（例如让exports直接指向一个新对象或一个函数），就会发生“引用断开”：exports改指向新的内存地址，而module.exports仍保持原指向。由于require()返回的是module.exports而不是exports，调用端最终拿到的还是旧的module.exports内容，常见结果是导出变成空对象或缺少方法，进而引发运行时异常。换句话说，模块对外接口最终由module.exports决定。 影响——从单点报错扩散到工程维护风险 这种差异看似不大，但在工程规模扩大后往往会被放大： 一是可读性变差。团队对导出约定理解不一致时，同一仓库里可能同时出现“用exports挂载属性”和“用module.exports整体覆盖”的混搭写法，提高理解成本。 二是兼容性风险增加。有的模块希望导出函数便于直接调用，实际却得到对象；或期望拿到方法集合，却只得到单一函数，接口契约因此变得不稳定。 三是排障成本上升。问题通常在运行时才暴露，定位时需要沿着导出链路回溯，在多层依赖、动态加载等场景下更容易出现“顺藤摸错瓜”。 四是质量治理更难。如果缺少统一规范和静态检查，这类问题容易在评审中漏掉，往往上线后才集中暴露。 对策——明确导出策略，按场景选择“追加”或“覆盖” 更通行的做法是围绕“导出接口长什么样”建立明确约定： 第一，需要导出多个能力点、以对象作为命名空间时，可用exports追加属性，例如exports.area等。关键是只做属性追加，不要对exports整体重新赋值。 第二，导出单一函数、类或构造器时，建议直接对module.exports整体赋值，让调用端拿到的就是可调用或可实例化的对象，减少一层属性访问，也更符合接口语义。 第三，不要把exports当作最终出口去做覆盖式赋值。若确实需要改变导出整体形态，应明确修改module.exports，保证require()拿到的就是最终接口。 第四，推进工程化约束。可通过代码规范、评审清单和自动化检查，明确“导出对象用exports追加、导出单体用module.exports覆盖”的规则，并在模板和脚手架中固化，减少个人习惯带来的不确定性。 前景——以规范化降低复杂系统的偶发性风险 随着Node.js生态向更大规模、更复杂依赖关系的工程演进，模块接口是否清晰，直接影响协作效率和系统可靠性。伴随代码规范、类型系统和测试体系的普及，CommonJS导出规则的最佳实践有望继续沉淀为团队标准，让接口设计更一致、依赖关系更透明、线上故障更可控。由此，稳定的模块边界将成为提升工程质量的重要抓手。
模块导出看似细节，实则关系到系统对外契约是否可靠；弄清“exports是引用、module.exports定最终结果、require()返回module.exports”的基本逻辑，再配合统一规范与测试保障，才能让模块化真正支撑大型工程的稳定运行与持续演进。