用户的三种来源
组织管理员在 Administration → Users and service accounts（旧版本入口为 Administration → Users，以实际界面为准）管理成员，用户进入组织通常有三条路：
- 直接添加：Server Admin 在用户管理中点击 Add user，填写登录名、邮箱与组织角色。
- 邀请：点击 Invite，通过邮件或直接复制链接给对方；被邀请人接受邀请前，不算正式成员。
- 外部认证自动注册：用户首次通过 OAuth、SAML 或 LDAP 登录时自动建号，落入
grafana.ini指定的组织，详见认证与登录集成。
角色速览
每个用户在「当前组织」内持有一个基本角色，能力矩阵见角色与权限（RBAC），这里只给一句话版本：
| 角色 | 一句话定位 |
|---|---|
| Viewer | 只能看仪表盘、用 Explore 查询 |
| Editor | 能创建与修改仪表盘、配置告警 |
| Admin | 能管理本组织的用户、团队与数据源 |
提示： 除了组织角色，Grafana 还有「全局角色」（Viewer、Admin、Super Admin 等），决定用户能否跨组织操作。日常授权只需要关心组织角色。
服务账号不是人类用户
服务账号（Service Account）是专供 API、脚本与自动化使用的机器身份，与人类用户的差别在于：
- 没有登录密码，也不能交互式登录，只通过 Token 鉴权。
- 令牌有明确的创建时间与过期时间，可以单独吊销，比「借用某人的 API Key」安全得多。
- 同样持有 Viewer/Editor/Admin 等组织角色，按需给最小权限。
Grafana 官方已用服务账号取代旧的 API Key，新自动化任务应一律使用服务账号令牌：
# 创建一个 Editor 角色的服务账号
curl -X POST "https://your-grafana/api/serviceaccounts" \
-H "Authorization: Bearer <admin-token>" \
-H "Content-Type: application/json" \
-d '{"name": "ci-bot", "role": "Editor", "isDisabled": false}'批量管理
人多时优先用 API 或配置即代码，而不是在界面上一个个点。除上面的服务账号端点外，常用的还有 POST /api/orgs/<org-id>/users（组织加人）与 PATCH /api/orgs/<org-id>/users/<user-id>（改角色）。若用户体系由外部系统主导，建议改用 LDAP/OAuth 自动同步，把「建号」这件事彻底交给身份源。批量接口的完整用法见HTTP API 与自动化。
常见坑：用户看不到仪表盘
按命中率排序：
- 不在同一个组织：对方登录后的当前组织里没有这个仪表盘。让用户点左上角组织名切换确认。
- 文件夹权限没放开：仪表盘所在的文件夹没有授予其团队/角色，即使有 Editor 角色也进不去。
- 看得到但改不动：这是 Viewer 角色的正常行为，不是 bug；需要编辑就升级为 Editor。
- 邀请过期：邀请链接默认有效期有限（可在
grafana.ini的[invite]段调整），过期后需重新邀请。
下一步
- 按项目组批量授权，看团队（Team）。
- 权限模型全貌与排查思路，看角色与权限（RBAC）。
- 自动化建号与令牌，看HTTP API 与自动化。