复用通用业务逻辑模块需从模块设计、路径组织、加载方式和跨平台适配四层面协同：统一存放纯函数于shared目录或私有npm包；用相对路径或ts path别名导入；导出兼容commonjs与esm；结合通信场景提供dto和预处理能力。
在Node.js微服务架构中，复用通用业务逻辑模块的关键不是“到处复制代码”，而是让逻辑真正可被多个服务按需加载、独立演进、类型安全调用。这需要从模块设计、路径组织、加载方式和跨平台适配四个层面协同考虑。
统一存放共享逻辑，避免重复实现
把校验、计算、格式化等不依赖具体框架或运行环境的纯函数抽离为独立包，例如：
- 放在项目根目录下的
shared/文件夹（如shared/validation.ts、shared/utils.ts） - 或发布为私有 npm 包（如
@myorg/core-utils），供各微服务通过npm install引入 - 确保这些模块不引入 Express、NestJS 等框架特有对象（如
req、res、Context），只接收原始参数并返回确定结果
用相对路径或别名导入，保持引用清晰
不同微服务项目结构可能不同，但导入方式应一致且可维护：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 在 Express 服务中：
import { validateEmail } from '../../shared/validation'; - 在 NestJS 服务中：
import { validateEmail } from '@shared/validation';（配合tsconfig.json的paths配置） - 避免硬编码长路径或使用
require('shared/validation')这类未声明的全局别名，防止构建失败或 IDE 无法跳转
导出方式兼容 CommonJS 和 ESM
考虑到部分微服务仍在用 CommonJS（如旧版 Express 项目），而新项目多采用 ESM，模块需兼顾两者：
- 推荐使用
export default+export const xxx的标准 ES 模块写法 - 若需支持 CommonJS 消费方，可在
package.json中同时声明"type": "module"和"exports"字段，明确指定 ESM 入口与 CJS 入口 - 避免混用
module.exports = {}和export default，否则会导致 TypeScript 类型丢失或运行时报错
结合微服务通信场景做轻量适配
共享模块不处理网络调用，但可为通信提供标准化输入输出：
- 定义统一的 DTO 类型（如
AccountValidationInput），被账户服务和交易服务共同引用 - 在 RPC 或 HTTP 客户端封装层里，先用共享模块校验请求参数，再发起调用，减少无效通信
- 对跨服务数据格式（如时间戳、金额精度）做预处理，避免每个服务重复转换
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
