Play Console 里的每一个操作都由权限把关，而 2026 年的权限体系分成三个维度：人的访问层级、授权范围，以及可选的访问到期日。组合对了，外包开发者只能上传封闭测试包、看不到任何收入报表；组合错了，本只该回复用户评论的人却能把版本发到正式版。本文按「用户和权限」页面把流程走完 —— 访问层级、账号级与应用级的区别、权限组、到期与移除，最后讲清三处「权限并不在 Play Console 里」的例外。
三种访问层级，其中一种无法替代
在添加任何人之前，先想清楚你要给出的是哪一种层级，因为三者中只有一种不可替代。
- 账号所有者（Account owner） —— Play Console 中首个注册的账号。它拥有全部访问权限，并且是唯一能邀请、移除用户以及管理单个权限的层级；也是唯一能关联付款资料以销售付费应用的账号，唯一能打开和修改「付款设置」页面的账号。开发者账号信息的修改同样只允许账号所有者操作。
- 管理员（Admin） —— 持有 Admin (all permissions) 权限的账号。管理员可以被限定为全部应用或指定应用，能邀请和移除用户、管理单个权限，且无需支付 25 美元的注册费。
- 用户（User） —— 其他任何层级的访问权限，同样可以限定为全部应用或指定应用。用户不能邀请他人、不能修改权限，也无需支付注册费。
落到运营上就是一条规则：账号级至少保留一个管理员，这样用户管理不会依赖某一个登录账号。把某人加成用户并不等于转让账号所有权，无论为其打开多少权限都一样。
第一步 —— 先决定是账号访问还是应用访问
每一份授权要么是账号级（作用于账号内所有应用，包括你之后新增的应用），要么是应用级（只作用于你勾选的应用）。Google 官方文档明确指出，有些权限只存在于其中一级，因此同一个概念会以略微不同的名字出现两次：
- View app information (read-only) 是应用级权限，其账号级对应项是 View app information and download bulk reports (read-only)。
- Edit and delete draft apps（应用级）对应 Create, edit, and delete draft apps（账号级）。要真正新建草稿应用，必须用账号级那一个，并且还需要同时拥有账号级的只读查看权限。
- View financial data（应用级）对应 View financial data, orders, and cancellation survey responses（账号级）。
- 游戏服务相关的 Edit Google Play games services projects 与 Publish Google Play games services projects 只有账号级。
注意这两个草稿应用权限都「发布不了任何东西」。Google 有意把「准备好一个版本」和「发布到正式版」拆开，权限名称本身就写明了这条分界。
第二步 —— 添加用户并开关权限
- 进入 Play Console 的 用户和权限（Users and permissions） 页面。要修改已有成员，直接点该成员所在行的任意位置；要新增成员，输入其邮箱地址，并在访问是临时性质时设置访问到期日。
- 选择授权范围。逐个应用授权用 应用权限（App permissions） 标签页 —— 点 Add app 选择应用后点 Apply；要覆盖账号内所有应用则用 账号权限（Account permissions） 标签页。
- 点 Invite user 发出邀请。执行这一步本身就需要账号级的 Admin (all permissions) 权限。
有两个细节最容易踩坑。被邀请人必须使用你邀请时填写的那个邮箱地址登录 —— 不能用别名，也不能在你邀请企业邮箱的情况下改用个人 Gmail。另外，如果到期日留空，访问权限不会自行失效，会一直保留到有人主动移除为止。
权限组：面向团队，而不是面向个人
当需要同一类权限的人超过几个之后，就别再逐个改人了，改用 权限组（Permission Groups）。路径是：用户和权限 → Permission Groups → Create permission group，填写组名，按需勾选 Set access expiry date，写一段只有该账号管理员可见的内部说明，选择该组要携带的应用权限和账号权限，再到 Users in this group 标签页把成员加入，最后点 Create group。组内成员统一继承这些权限，删除该组则一次性收回所有成员的权限。如果没设到期日，权限组发放的权限也不会自动过期。
邀请与访问到期日
- 邀请发出后，该邮箱的状态会显示为 Invite sent；对方接受后状态变为 Active，账号所有者会收到确认邮件。
- 邀请发出后 30 天内未被接受并登录，邀请即失效，管理员需要重新发送。权限不会丢，但也不会生效。
- 延长访问：用户和权限 → Manage users，勾选成员，点 Extend access，选择延长时长，再依次点 Extend access 与 Confirm。只改单个人时，打开其所在行，勾选 Set access expiry 直接填写具体日期。
- 移除访问：在同一页面勾选成员后选 Remove，再点 Save changes；或打开该成员所在行，选择 Remove user。
Admin (all permissions) 这个开关到底给了什么
同一个管理员权限，授予位置不同，能力也不同。以逐应用方式授予的管理员，可以看到所有能访问相同应用的其他用户，但无法移除拥有全局访问权限的用户。以全局方式持有该权限的管理员，则还可以调整访问到期日，并通过 Activity log 查看账号内发生过什么。如果你的内控依赖「有人能审计谁改了什么」，这条区别就是关键 —— 也正因为如此，全局管理员授权值得留下书面理由。
不在 Play Console 里的三处权限
有三个经常被忽略的地方需要一并规划：
- Google 付款中心是独立的。Play Console 的权限不会带来付款中心的报表访问权，需要在付款中心单独添加：付款中心 → Settings → Payments users → Manage Payments Users → Add a new user → Invite。
- 游戏服务项目还需要 Google Developers Console 的对应权限，仅有 Play Console 权限不够。游戏服务的财务数据则要求同时具备账号级财务权限，以及至少一个已关联应用的应用级 View financial data 权限。
- 账号组（Account Group）不等于共享访问权。创建或加入 Account Group 是获得 15% 服务费档位的前提，且由主开发者账号的管理员负责管理该组；但包括主开发者账号在内，任何人都不因此获得组内其他账号的财务数据、发布权限或类似权限，除非那个账号自己的管理员明确把他添加为用户。
权限出错时是什么样
最常见的是 Play Console 里报 Error 403：人已登录、应用也看得见，但某个板块就是加载不出来。这是权限缺失，不是账号坏了，解决办法是请账号所有者授予该应用的对应权限。还有几种模式值得提前识别：能上传文件却不能把版本发到正式版，通常缺 Release to production, exclude devices, and use Play App Signing；反过来，持有该权限的人距离线上发版只差一次误点，因此当岗位只需要测试轨道时，只给 Release apps to testing tracks 就够了 —— 它涵盖草稿上传、测试发布、.obb 文件、内部分发和版本说明，但无法发布到正式版。另外，能处理退款和取消订阅的人，如果没有财务数据权限，依然看不到汇总财务报表。
发放权限前的检查清单
- 这个人需要的是账号级范围，还是只要一个应用？
- 访问是临时的吗？如果是，就在发出邀请时同时设好到期日。
- 岗位涉及发布正式版，还是只涉及测试轨道？
- 需要正式版发布权限，但不需要改商店列表和价格设置吗？
- 需要回复评论、管理政策声明，或处理订单与退款吗？
- 涉及财务数据时，是否也需要在付款中心添加这个人？
- 账号级是否还有第二个管理员，确保用户管理不依赖单一登录？
一句话模型：账号所有者是唯一不可替代、也唯一能管理付款的层级；管理员可以委派，但权力因「全局」还是「逐应用」而不同；每一份权限要么覆盖整个账号、要么只针对单个应用，有些只存在于其中一级；而没有到期日的授权在被人主动移除之前一直有效。给能满足岗位的最小权限，并在开始时就写好结束日期。