1. 只要核心功能藏在登录、邀请码、付费墙或其他门槛后面，Google Play 审核人员就必须能走进去。Play Console 帮助把这件事称为应用访问说明（App access instructions）：你要写清楚审核员如何打开受限制功能。他们进不去时，常见结果是登录问题拒审，或按最低功能（Minimum Functionality）判定——因为已声明的核心流程从未跑通。
2. 在 Play Console 填写凭据：政策 → App 内容（App content）→ 应用访问（App access）。若任何功能需要登录、验证码、邀请或特殊角色，请选择「部分或全部功能受限制」，并在送审前补上一组说明。不要在审核员一打开就是登录页的情况下，仍把应用访问标成「无需特殊访问即可使用全部功能」。
3. 说明文字要写成陌生人也能跟着做的路径：用户名和密码（或一次性审核码）、如何处理两步验证（2FA）、到达受限制页面的应用内路径或深层链接（deep link），以及测试环境 / 租户 / 地区备注。示例结构：「用下方账号登录 → 首页 → 钱包 → 转账。使用此处列出的预发环境。此账号请勿开启 2FA。」
4. 需要登录时，提供专用的演示或测试账号，并且账号里已经备好行使全部已声明核心功能所需的数据和权益。空账号、过期账号、或「新用户没有任何内容」的账号，即使密码正确也常被拒——因为审核员仍然看不到你提交的产品。
5. 去掉或绕过审核员在其设备上无法完成的校验：短信验证码、发到你邮箱的魔法链接、硬件密钥、绑定本人手机的验证器，以及过强的图形验证码。若第二因素无法关闭，必须在同一份应用访问说明里写上当前可用的验证码或书面绕过方法，并保持有效。卡在「等你手机短信」的登录，会被当成「因登录问题无法审核」。
6. 所列凭据必须在整段审核窗口内有效——至少数天；若使用代管发布（Managed Publishing）或可能再次提交，则要更长。不要在审核中途改密码、登录几次就锁账号，或把演示用户限制到审核员无法匹配的国家。若必须改密码，先在同一次操作里更新应用访问说明，再重新提交。
7. 产品允许时，提供无需登录的路径：游客模式、「不登录继续」，或能不凭账号打开核心功能的审核构建——并在应用访问里写明这条路径，避免审核员只能走你本意并不是唯一入口的登录。受限内容（Restricted Content，例如年龄门槛、付费目录、按地区锁定的媒体）仍然需要一条可走通的路线；游客模式不能代替内容分级或合法的年龄核验。
8. 若已经收到「We couldn't review your app because of login issues」（因登录问题无法审核你的应用），先修好应用访问表单再重提：在干净设备上确认用户名/密码可用，粘贴精确的导航步骤，关闭演示账号的 2FA，并确认该账号能到达每一项已声明的核心功能。不更新应用访问就重提，通常会再次被同一理由拒绝。