1. Atlassian平台扩展全景
在开始任何定制开发之前，必须先回答一个基础问题：我要改的东西，究竟属于“配置”还是“扩展”？Atlassian 三件套（Jira、Confluence、Bitbucket）都提供了大量开箱即用的配置能力，同时也各自暴露了不同层次的扩展点。混淆这两者，往往导致两种典型失败：用代码去实现本可以点几下就完成的需求，或者用配置去硬凑一个本质上需要插件才能支撑的场景。
一、三款产品的定位差异决定了扩展方式
Jira 是事务与流程驱动的平台，核心对象是 Issue，核心机制是工作流引擎。它的扩展点围绕“事务如何流转、字段如何校验、权限如何收敛”展开。Confluence 是内容协作平台，核心对象是 Page 与 Space，扩展点更多集中在宏（Macro）、内容渲染、蓝图（Blueprint）和空间权限上。Bitbucket 是代码托管与流水线平台，核心对象是 Repository、Pull Request 和 Pipeline，扩展点集中在合并检查（Merge Check）、Webhook、CI/CD 钩子和应用链接上。
三者共享同一套底层扩展框架——Atlassian Connect 与 Forge，但各自暴露的 API 面和事件模型完全不同。理解这一点，才能判断一个跨产品需求应该落在哪个平台、用哪种扩展方式实现。
二、配置与扩展的边界
判断标准可以归纳为三条：
- 是否改变数据模型：新增自定义字段、修改工作流状态、调整权限方案，属于配置；引入全新的对象类型或跨系统同步，属于扩展。
- 是否引入外部逻辑：调用第三方 API、执行自定义计算、触发外部系统，属于扩展；仅使用内置条件、校验器、后置函数，属于配置。
- 是否可被平台原生承载：如果平台已经提供了对应的 UI 入口和存储机制，优先配置；否则才考虑扩展。
三、工作流引擎在三款产品中的位置
Jira 的工作流引擎是最完整、最值得深入的对象。一个工作流由状态（Status）、转换（Transition）、条件（Condition）、校验器（Validator）、后置函数（Post Function）五类元素构成。状态是事务在某一时刻的归属；转换是状态之间的有向边；条件决定“谁能执行这次转换”；校验器决定“执行前必须满足什么”；后置函数决定“执行后系统自动做什么”。
Confluence 没有严格意义上的工作流引擎，但它的内容状态（草稿、发布、归档）和审批流（通过 Comala 等应用或原生 Page Approval）承担了类似职责。Bitbucket 的Pull Request 状态机（Open → Merged / Declined）配合 Merge Check 和 Pipeline 触发，构成了代码合并的流程控制。
下图展示了三款产品的扩展点分布与工作流引擎的定位关系：
四、如何选择扩展方式
面对一个具体需求，可以按以下顺序判断：
- 先查原生配置：Jira 的工作流编辑器、字段配置、权限方案是否已经覆盖？Confluence 的宏和蓝图是否够用？Bitbucket 的 Merge Check 和 Pipeline 是否已满足？
- 再看 REST API：如果需求是“在外部系统中同步数据”或“批量操作”，REST API + Webhook 通常是最轻量的方案，不需要部署应用。
- 最后考虑 Forge/Connect：只有当需要自定义 UI、在平台内部嵌入交互、或需要持久化存储时，才引入应用开发。
五、一个判断示例
假设需求是：“当 Jira 事务从‘进行中’转为‘已完成’时，自动在 Confluence 中创建一条发布记录，并通知 Bitbucket 触发一次构建。”
拆解：Jira 侧需要工作流后置函数或 Webhook 监听转换事件；Confluence 侧需要 REST API 创建页面；Bitbucket 侧需要 Pipeline 触发接口。这个需求跨越三个产品，无法用单一配置完成，必须通过 Forge 应用或外部中间服务串联。此时，扩展的边界就清晰了：Jira 的工作流引擎负责“事件源”，Confluence 和 Bitbucket 的 API 负责“消费端”，Forge 负责“编排”。