2. Confluence空间架构设计

空间（Space）是 Confluence 中最高层级的组织容器，它同时承担三件事：内容归属、权限边界和协作范围。空间架构设计得好，用户能凭直觉找到文档、权限能按组织关系自然继承、跨团队协作有明确通道；设计得差，就会出现“文档到处建、权限逐个配、搜索找不到”的典型混乱。本节围绕划分维度、命名标识、权限继承和跨空间协作四条主线展开。

一、先选划分维度：产品线、项目、团队还是职能

四种维度各有适用场景，关键判断依据是“内容的生命周期由谁决定、访问范围由谁定义”。

• 按产品线划分：适合产品边界清晰、各产品有独立研发与运维团队的组织。空间内容以产品需求、设计、接口、发布记录为主，生命周期与产品版本同步。缺点是公共规范容易重复建设。
• 按项目划分：适合项目制、交付制团队。空间随项目启动创建、随项目结项归档，边界干净。缺点是长期沉淀的知识（如通用组件说明）无处安放。
• 按团队划分：适合稳定的职能团队（如前端组、测试组、平台组）。空间是团队的“知识主页”，成员变动时权限调整成本低。缺点是跨团队项目需要额外协作空间。
• 按职能划分：适合流程与规范类内容，如研发规范、测试规范、安全合规、运维手册。这类内容变更慢、读者广、需要统一入口。

实践中很少只用一种维度。推荐采用“主维度 + 少量职能空间”的混合结构：以产品线或团队作为主维度承载日常研发文档，再单独建立 2～4 个职能空间承载跨产品通用的规范与流程。混合结构下，职能空间只放“稳定且通用”的内容，避免变成第二个杂物间。

二、空间命名与标识（Key）设计

空间名称面向人，空间标识（Key）面向 URL 和权限配置，两者要一起设计。命名建议采用“维度前缀-对象名”结构，例如 产品-订单中心、团队-支付研发、规范-研发流程。前缀让用户在空间列表里一眼分辨类型，也便于后续批量管理。

空间标识一旦创建不可修改，且会出现在所有页面 URL 中，因此必须提前规划。推荐规则：

产品线空间：PRD-{产品缩写}      例：PRD-ORDER
项目空间：  PRJ-{项目缩写}{年份}  例：PRJ-PAY2024
团队空间：  TEAM-{团队缩写}      例：TEAM-FE
职能空间：  STD-{职能缩写}       例：STD-DEVPROC

标识统一使用大写字母与短横线，长度控制在 3～12 字符。禁止使用中文、空格和连续短横线，避免 URL 转义和权限脚本解析异常。命名与标识应在治理规范中固化，新建空间需走申请流程，由空间管理员审核，防止出现 test、temp、newspace 这类无意义标识。

三、权限继承：用组而非个人，用层级而非平铺

Confluence 空间权限由“空间权限 + 页面限制”两层构成。空间权限决定谁能进入空间，页面限制决定谁能看某棵子树。设计原则是：空间权限只授予用户组，页面限制尽量少用。逐个给个人开权限会导致人员流动时权限残留，而页面限制过多会让权限模型难以推理。

推荐按“角色组”建模，每个空间配置三类组：

组名建议与空间标识对齐，例如 PRD-ORDER-admins、PRD-ORDER-editors、PRD-ORDER-viewers。这样在权限审计时，能通过组名直接定位到空间，避免出现“某个人为什么能看这个空间”的排查困境。若组织使用 LDAP 或 SSO 同步组，应优先复用已有组织组，减少手工维护。

四、跨空间协作规则

跨空间协作有三种常见模式，应按协作强度选择：

1. 只读引用：A 空间文档被 B 空间页面通过“包含页面”宏引用。B 空间用户无需加入 A 空间即可看到内容，但无法编辑。适合规范、接口说明等单向消费场景。
2. 协作空间：为跨团队项目单独建空间，双方成员都加入编辑组。项目结束后归档，权限随空间关闭。适合有明确起止时间的联合项目。
3. 共享页面树：在 A 空间下划出一棵子树，通过页面限制开放给 B 空间只读组。适合长期共享但不宜全空间开放的内容。

无论哪种模式，都要明确“内容归属空间”原则：文档只在一个空间里维护，其他空间通过引用或链接消费，禁止复制粘贴多份。复制会导致版本分叉，后续无法判断哪份是最新。跨空间引用时，建议在页面顶部标注来源空间与负责人，便于读者追溯。

五、落地检查清单

空间架构设计完成后，可用以下清单自检，确保方案可执行、可审计：

• 每个空间都有明确的主维度和负责人，不存在“无主空间”。
• 空间标识符合命名规则，无中文、空格、无意义缩写。
• 空间权限只授予组，不授予个人；组名与空间标识对齐。
• 页面限制数量可控，每个限制都有书面理由。
• 跨空间引用有来源标注，无重复维护的副本。
• 新建空间有申请与审核流程，归档空间有明确处理方式。

空间架构不是一次性设计，而是随组织调整持续演进的过程。建议每半年做一次空间审计：统计空间数量、活跃度、权限组配置和页面限制分布，及时合并僵尸空间、清理冗余权限。把审计结果纳入治理规范，空间架构才能真正支撑研发文档的长期秩序。