在把多个业务模块统一放进同一个仓库后沟通成为了Zui关键的一环。若处理不当，代码会被循环引用、接口频繁变动，甚至导致构建速度直线下降。下面我把自己在大型交易系统里踩过的坑和的经验，用一种略带情绪化的口吻呈现给你。

一、先理清依赖层次——“谁Ke以依赖谁”

把所有包想象成一座金字塔：底层是基础设施，上层是具体业务。遵循以下两条铁律：

上层Ke以向下依赖。业务代码Ke以直接引用 shared 中的常量或工具函数。

下层绝不向上依赖。shared 永远不应该 import trade 或 account 的实现。

用一段伪代码快速展示：

// packages/trade/package.json
{
  "dependencies": {
    "@repo/shared": "workspace:*",
    "@repo/data-center": "workspace:*"
  }
}
// packages/shared/package.json ❌ 错误示例
{
  "dependencies": {
    "@repo/trade": "workspace:*"
  }
}

为什么要这么划分？

① 防止循环依赖导致编译报错；② 基础库改动后只需要一次发布，所有业务包立刻受益；③ 构建缓存命中率大幅提升，CI 时间从十几分钟降到几分钟。

二、常用通信模式大盘点 1. 事件总线

适用于“某件事发生后需要多个模块感知”的场景，如订单提交成功后刷新持仓列表。

// packages/shared/events/index.ts
import mitt from 'mitt';
export const enum EEvent {
  ORDER_SUCCESS = 'orderSuccess',
  USER_LOGIN = 'userLogin',
}
export type TPayload = {
  ?: { orderId: string; type: string };
  ?: { userId: string };
};
export const bus = mitt;

发送方

// packages/trade/order/submit.ts
import { bus, EEvent } from '@repo/shared/events';
export function notifyOrder {
  bus.emit;
}

监听方

// packages/portfolios/components/list.ts
import { onMounted, onUnmounted } from 'vue';
import { bus, EEvent } from '@repo/shared/events';
function refresh {/* … */}
onMounted => bus.on);
onUnmounted => bus.off);

2. 公共服务

当多个业务需要访问同一套数据或统一的业务逻辑时把它抽象成单例服务放在 shared 或 data‑center 包里。

// packages/shared/services/data-center.ts
import { Singleton } from '@repo/shared/utils/singleton';
export class DataCenter extends Singleton {
  static tag = 'DataCenter';
  async getStockInfo {
    // 调用后端接口…
  }
  async getQuotes {
    // ...
  }
}
export { DataCenter };

业务方只需要拿到实例即可：

// packages/trade/utils/stock.ts
import { DataCenter } from '@repo/shared/services/data-center';
export async function fetchStock {
  const dc = DataCenter.getInstance;
  return await dc.getStockInfo;
}

3. 公共 API

每个子包dou提供一个根入口 index.ts，只导出「对外」的内容。内部实现永远藏在子目录里不让别的包直接触碰。

// packages/trade/index.ts
export * from './data/constant';      // 常量
export { canFillSearch } from './utils'; // 工具函数
export type { IOrderForm } from './types'; // 类型
export { default as OrderPanel } from './order/index.vue'; // UI

这样其他包只Neng这样使用：

import { canFillSearch } from '@repo/trade';
# ❌ 错误写法：import { canFillSearch } from '@repo/trade/utils';

三、Zui佳实践清单

把所有共享类型和常量放进 @repo/shared.

业务专属的工具函数或枚举留在对应业务包内部。

不要在业务包里直接 import 某个子目录路径，而是通过根入口导出。

若出现循环依赖，立刻抽取公共部分到 shared，再让两个原始包各自引用它。

事件监听要记得在组件销毁时解除订阅，防止内存泄漏。

Lerna/Yarn Workspace 的 version lock 应统一管理，避免出现 “package A@1.0.0” 与 “package B@1.1.0” 同时存在的尴尬局面。

CI 中加入 lint 检查：禁止 import '@/store/*' 等跨层级路径。

Eslint + eslint-plugin-import 的 settings 配置Ke以帮助捕获非法依赖方向。

四、一步步改造案例：从“乱糟糟”到“井然有序” 把订单状态枚举搬到 shared

// 原始位置：packages/trade/data/constant.ts
// 改为：
export enum EOrderVerify {
  NOT_LOGIN = 'not_login',
  // ...
}
# 移动后在 trade 包中仅通过 @repo/shared/constants 引入。

将验证函数提取为共享工具

// packages/shared/utils/verify.ts
import type { IUserStore } from '@repo/shared/interfaces';
export async function preVerify: Promise {
   if  {
      user.goLogin;
      return false;
   }
   return true;
}

geng新业务调用

// packages/trade/utils/order.ts
import { preVerify } from '@repo/shared/utils/verify';
import { useUserStore } from '@/stores/user';
const userStore = useUserStore;
await preVerify;

清理旧引用

删除 package.json 中对其他业务包的 workspace 引用；

`npm run lint` 报错即代表还有残留路径，需要全部迁移至公共 API。

完成以上步骤后你会发现构建时间缩短了约30%，IDE 自动补全也geng友好——这才是 Monorepo 真正Neng带来的价值！ 🎉

五、让沟通geng顺畅，让项目geng轻盈 🚀

Monorepo 本身并不是魔法，它只是提供了一个“大屋子”。Ru果我们不提前规划好各房间之间的走廊，就会出现乱七八糟的门锁和堵塞的走道。本文给出的依赖层次原则、事件总线与共享服务两大核心模型，以及“一条入口、统一导出”的公共 API 策略，dou是帮助团队保持代码清洁、提升协作效率的不二法门。

记住：**先定义好谁Neng靠谁，再挑选Zui合适的通信方式**——如此，你才Neng真正体会到 Monorepo 带来的开发快感，而不是被循环依赖绊倒在路口。祝你的项目沟通顺畅，迭代如虎！ 🐅

©2026 SEO 专家 出品 | 本文基于真实项目经验撰写，仅供参考。 .

---