Better Auth 1.7 中的账户变更
Better Auth 1.7.0 在账户表中新增了必填字段 issuer。这意味着，即使应用只使用密码或 GitHub 登录，也必须更新数据库。1.7.3 版本取消了这一要求，但已经添加该字段的用户仍需清理数据库。
对于因此导致的登录失败和额外数据库工作，我们深表歉意。升级 1.x 时，你应该能够不用迁移 Better Auth 的核心表。我们在 1.7 中没有达到这一预期，而遵循了我们先前说明的用户现在还要面对第二次变更。
我需要更改数据库吗？
我在 1.7.0 到 1.7.2 之间创建或迁移了数据库。 部署 1.7.3 之前，请按照清理步骤操作。
我直接从 1.6 升级到 1.7.3。 无需清理 issuer。其他变更请参阅升级指南。
为什么一个简单的应用也需要迁移？
我们引入 issuer，是为了让连接到同一登录服务的多个连接能够共享同一用户的账户。将它设为必填核心字段，导致不需要账户共享的应用也必须迁移。我们没有充分评估这对现有数据库造成的成本。
有人提出了兼容性选项，可以保留旧的账户匹配方式，但仍然需要新增字段并进行迁移。一些说明还提到了尚未在已发布的 CLI 中提供的命令。那时用户已经开始迁移，导致回退变得更加困难。
为什么我们撤销了架构变更
1.x 的承诺没有改变：升级不应要求迁移 Better Auth 的核心表。需要核心表迁移的变更应放在 2.0 中。插件和可选功能仍可有各自的升级要求。
1.7.3 恢复了 1.7 之前使用的账户架构，通过配置的提供商 ID（providerId）和该提供商的用户 ID（accountId）来识别账户。令牌颁发者验证仍然有效；它不依赖于在账户表中存储 issuer。
由于 1.7.3 不再写入 issuer，仍要求该字段的数据库可能会拒绝新账户。Better Auth 初始化时会开始进行架构验证。如果检测到不兼容的架构，就会阻止身份验证请求。
如何清理已经迁移的数据库？
先备份数据库，并在恢复后的副本上测试针对数据库的清理步骤。清理会移除 issuer 索引，并将该列设为可选或将其移除。请一并修改任何 Prisma 或 Drizzle 架构，并在应用这些变更前检查重复的账户键。
切换期间暂停身份验证和后台写入，并在部署后重启每个应用实例。恢复写入前，请规划好恢复方案：1.7.3 创建不含 issuer 值的账户后，仅回退软件包并不是安全的回滚方式。
如果多个公司登录共用一个账户，该怎么办？
如果多个单点登录（SSO）连接共用一个账户，仅清理列可能会导致某个连接无法登录。升级前，请检查每个连接如何访问现有用户。SSO 用户解析器可以使用受信任的身份保留该关联；请勿仅根据电子邮件地址关联账户。
如何确认清理成功？
使用每个提供商测试现有会话、新登录和注册，并确认回访用户能够访问其现有账户。还应测试账户关联、令牌刷新和取消关联（如果支持）。对于由 SCIM 管理的用户，还要验证禁用用户会阻止其访问，而启用用户会恢复其访问权限。
保持 1.x 升级稳定
我们将在审核和发布流程中增加防护措施，以便：
- 在核心架构变更随 1.x 版本发布之前发现它们。
- 使用由已发布版本填充的数据库检查升级，包括升级后的现有登录和账户所有权。
- 检查升级说明是否适用于用户实际可用的确切软件包和命令。
- 在发布影响现有部署的变更前，审查恢复方案。