在 NocoBase 中，插件把一项功能封装为独立的包，由 App 按需接入。编写插件主要有两个原因：代码复用和模块化组织代码。两者满足其一，就可以考虑使用插件。
1. 代码复用
当多个应用需要相同的功能时，可以把公共部分封装为插件，避免在每个应用中重复开发和复制代码。
例如，多个业务应用都需要对接同一个短信服务。可以将短信发送、服务商配置和错误处理封装成插件，由各个 App 安装并使用。订单应用决定何时发送订单通知，审批应用决定何时发送审批提醒，底层的短信能力共用一份实现。
这样，修复问题或增加功能时，可以集中维护插件，再由各应用按需要升级。插件负责提供稳定的公开接口，App 负责自己的业务组合与配置。
复用已有能力时，先检查是否已有合适的插件，见管理插件。只有现有能力不能满足需求时，才需要开发自己的实现。
2. 模块化组织代码
即使只有一个 App，也可以通过插件组织代码。把职责相关的页面、接口、服务和数据逻辑放在同一个模块中，能够让功能边界更清楚，方便安装、配置、维护和升级。
例如，一个业务 App 包含订单、库存和报表功能。随着功能发展，可以将它们分别组织为插件：
my-app/
├── client/ # App 的界面组合与入口
├── server/ # App 的服务组合与入口
├── packages/
│ ├── app-plugin-orders/ # 订单模块
│ ├── app-plugin-inventory/ # 库存模块
│ └── app-plugin-reports/ # 报表模块
├── package.json
└── pnpm-workspace.yaml每个插件可以维护自己的实现、公开入口、配置和测试。App 决定接入哪些插件，以及怎样将它们组合起来。团队成员也可以围绕模块分工，减少对其他功能内部实现的依赖。
模块之间仍可能存在依赖。例如，报表插件需要订单数据时，应通过明确的公开接口获取，而不是直接导入订单插件的私有源码。拆成插件的目的是让这些关系更清晰，便于后续维护。
在 App 中开发插件
先通过 create-app 创建应用，再在 App 中开发插件。App 支持 monorepo，本地插件放在 packages/ 下，通过 pnpm 工作区依赖接入，与应用一起开发和构建。
插件可以只服务当前 App，不需要先发布到 npm。 将来需要提供给其他应用时，再考虑分发、版本和兼容性。代码复用和模块化也可以逐步结合：先把当前应用的一项功能组织为插件，成熟后再供其他应用使用。
插件的大小由功能决定。它可以只提供一个 CLI 命令，也可以包含客户端页面、服务端接口和数据库逻辑，不必具备全部能力。目录与入口的具体说明见插件的结构。
选择合适的组织方式
插件是组织功能的一种方式。简单的页面或业务逻辑可以直接写在 App 中；仅通过 import 复用的函数、类型和工具，可以使用普通模块或共享包。当希望把一项功能作为可接入、可维护的整体，或提供给多个应用使用时，就可以考虑插件。
下一步阅读创建插件，使用 @nocobase/create-plugin 生成骨架；理解插件的结构后，再跟随编写第一个插件完成实现、注册和验证。
需要跨 App 共享并独立管理版本时，继续阅读发布插件。仅在当前 App 中使用时，无需发布。