模块化策略应以业务语义为边界，优先按用户任务（如登录流程、订单确认）划分领域组件，UI仅提取跨场景原子元素；复用分层级，项目内用目录+ESM，跨项目才抽离无业务依赖的模块，并通过工具链与规范保障落地。
选模块化策略，关键不是看哪种最“新”，而是看团队当前项目规模、协作节奏和交付压力。ES Module 是标准，但落地方式得按需调整。
先明确组件拆分的边界在哪
别一上来就按“按钮”“弹窗”这种 UI 粒度切，容易陷入过度设计。真正影响复用效率的是业务语义——比如“订单确认流程”里涉及地址选择、优惠计算、支付方式切换，这些逻辑天然耦合，就该打包成一个 领域组件（如 <OrderCheckout>），而不是拆成 5 个独立 UI 组件再手动拼装。
- 优先按业务动作或用户任务划分：登录流程、表单提交、列表筛选导出
- UI 层面只提取真正跨场景的原子元素：图标、加载骨架、空状态提示
- 有状态逻辑（如表单校验、分页请求）尽量和对应 UI 绑定，避免“纯 UI 组件 + 外部 hook”的松散组合
复用策略要区分层级和场景
不是所有代码都适合做成 npm 包。团队内部复用，80% 场景靠目录结构+ESM 就够了；真要跨项目共享，才考虑抽离。
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
-
项目内复用：统一放在
src/components/domain/（如user-profile-card）和src/utils/（如formatCurrency），用相对路径导入，改起来快、查得到源 - 跨项目复用：只抽离无业务强依赖、有明确契约的模块，例如通用表格渲染器、权限指令封装、错误上报 SDK —— 这类必须带类型定义、单元测试和清晰文档
- 避免“伪复用”：复制粘贴一份组件代码到新项目，再各自魔改，比不复用还危险；宁可暂时不抽，也要保证一处修改、多处生效
团队协作时模块化的实际约束
工具链和规范比语法更重要。ESM 写法一致，但 import 路径怎么写、循环依赖怎么报错、谁来维护公共 utils，这些才是卡点。
立即学习“Java免费学习笔记（深入）”；
- 约定绝对导入别名（如
@/components），禁用深层相对路径（../../../utils） - 用 ESLint 插件（如
import/no-cycle）在保存时拦截循环依赖，比等运行时报错更早发现问题 - 每个模块加简短注释说明用途、作者、最后更新时间，尤其工具函数——
debounce和throttle别共用一个文件还叫helpers.js
渐进式落地比一步到位更可靠
老项目迁移不用重写，从“可识别的重复块”开始下手。比如发现三个页面都有几乎一样的搜索栏逻辑，就先把它抽成 src/components/search-bar/index.js，再逐步收敛调用点。
- 第一阶段：识别并标记重复代码（用 IDE 的 Find Usages 功能）
- 第二阶段：抽离为本地模块，替换所有引用，确保功能不变
- 第三阶段：补充 TypeScript 类型、JSDoc、简单测试用例
- 第四阶段：评估是否值得发布为私有包，或加入团队组件库文档
