NocoBase 本周更新中，一个值得关注的变化是新增了“默认空间”配置：管理员可以指定默认空间，新用户创建后自动加入。这个功能看似只是少了一次手动分配，实际解决的是多空间系统中的初始化一致性问题，让邀请注册、管理员建号和批量导入等入口拥有统一的落点。
默认空间解决了什么问题
在支持多个空间的系统里，用户账号和空间成员关系通常是两层数据。过去创建账号后，管理员可能还要补充成员关系，否则新用户登录后会遇到没有可访问空间、首页为空，或者必须等待人工授权等情况。
默认空间把这段流程收敛为一个明确规则：
- 管理员配置一个默认空间。
- 系统创建新用户。
- 创建成功后，系统自动建立该用户与默认空间的成员关系。
- 用户首次登录即可进入预设的协作环境。
它尤其适合公司门户、内部工单、CRM 和项目管理等场景。在这些系统中，大部分员工通常需要先进入同一个公共工作区，再根据职责获得额外空间权限。
需要注意的是，“加入空间”和“获得业务权限”不应被视为同一件事。默认空间负责确定协作边界，角色、数据范围和操作权限仍应通过权限模型单独控制。
三个分支应该怎么选
NocoBase 当前更新分为 main、next 和 develop 三条分支，选择时应按照环境用途，而不是单纯追逐最新提交。
| 分支 | 定位 | 建议用途 |
|---|---|---|
main |
当前最稳定的版本 | 生产环境和常规安装 |
next |
包含即将发布的新功能，已完成初步测试，但可能仍有问题 | 测试环境、功能验证和反馈收集 |
develop |
持续开发中的代码 | 开发调试、兼容性研究，不建议直接承载生产业务 |
如果默认空间会影响真实用户注册，建议先在 next 测试环境验证完整生命周期，再等待稳定版本进入 main 后部署到生产。验证不能只看“用户是否创建成功”，还要检查成员关系、默认角色、重复执行和失败回滚。
查看本地仓库分支时，可以运行：
git fetch --all --prune
git branch -a
git log --oneline --decorate -n 10 origin/main
git log --oneline --decorate -n 10 origin/next
切换分支前，应提交或暂存本地修改，并按照项目实际升级文档执行依赖安装、数据库迁移和构建流程。
可以这样验证默认空间流程
来源摘要没有给出具体配置 API 或字段名，因此下面是一个可直接改造的概念性验收脚本，假设测试环境提供管理员配置、创建用户和查询空间成员的 HTTP 接口。运行前需要根据实际 NocoBase 版本修改三个接口路径、认证方式和 JSON 字段。
#!/usr/bin/env bash
set -euo pipefail
BASE_URL="${BASE_URL:-http://localhost:13000}"
TOKEN="${TOKEN:?请设置管理员 TOKEN}"
DEFAULT_SPACE_ID="${DEFAULT_SPACE_ID:?请设置默认空间 ID}"
TEST_EMAIL="default-space-$(date +%s)@example.com"
curl -fsS -X PUT "$BASE_URL/api/admin/default-space" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d "{\"spaceId\":\"$DEFAULT_SPACE_ID\"}"
curl -fsS -X POST "$BASE_URL/api/users" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d "{\"email\":\"$TEST_EMAIL\",\"nickname\":\"Default Space Test\"}"
curl -fsS \
"$BASE_URL/api/spaces/$DEFAULT_SPACE_ID/members?email=$TEST_EMAIL" \
-H "Authorization: Bearer $TOKEN"
验收时至少覆盖以下情况：正常创建的新用户自动入组；已有用户不被重复添加；默认空间被删除或停用时系统给出明确结果；成员关系创建失败时不会留下难以修复的半成品状态；通过邀请、后台创建和批量导入等不同入口创建的用户遵循一致规则。
上线前要划清权限边界
默认空间应选择权限较低、内容适合广泛可见的公共空间。不要把包含财务、人事或客户敏感数据的空间设为默认入口，也不要因为用户自动成为空间成员，就默认授予管理员或编辑权限。
生产采用时可以按这份清单执行：
- 在隔离测试环境验证，并记录当前分支与具体版本。
- 确认默认空间的基础角色遵循最小权限原则。
- 测试所有用户创建入口，而不只是后台手动建号。
- 检查重复请求、并发创建和失败重试是否产生重复成员关系。
- 准备关闭默认空间配置后的回退方案。
- 生产环境优先使用
main，将next用作预发布验证，避免直接部署develop。
默认空间配置的价值不在于多一个管理选项，而在于把用户初始化从人工操作变成可预测的系统规则。真正上线前，还需要把它与角色分配、数据权限和异常处理一起验证，才能避免“自动加入”意外扩大访问范围。