Bluesky 真正有价值的不是换一个新社交号，而是把你的域名、账号身份和未来迁移能力绑在一起，不再把身份完全押在单一平台。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
在 Bluesky 上最值钱的不是又注册了一个社交账号，而是你终于可以把身份、域名和迁移能力绑在一起。对创作者、媒体团队和长期做内容的人来说，这意味着账号不再只是某个平台给你的一个后缀名，而可以逐步变成自己的资产。可问题也正出在这里：一旦涉及域名 DNS、Handle 验证、PDS 迁移和备份意识，很多人会把它当成“技术人的事”，直到要改 Handle 或换服务器时才发现没有提前准备。
适用场景
- 你想用自己的域名当 Bluesky Handle，而不是一直用
name.bsky.social。 - 你准备给团队成员、记者、栏目或品牌账号分配子域名 Handle。
- 你在意未来迁移到别的 PDS 或从别的 PDS 回到 Bluesky PDS 的可能性。
- 你希望把账号身份做成长期品牌资产，而不是一次性试用账号。
不适用场景
- 你没有自己的域名，也不打算为社交身份维护域名。
- 你只是临时试用 Bluesky，对身份统一和账号可迁移性没有要求。
- 你对 DNS 管理完全没有控制权，也没人能帮你加记录。
- 你准备频繁换域名或把 Handle 当作短期营销素材。
先把身份模型理解对
Bluesky 官方之所以鼓励使用域名做 Handle，不是为了炫技术，而是因为 AT Protocol 把域名当成身份层的一部分。官方 FAQ 和 AT Protocol 文档都强调了“account portability”这个核心能力：你可以换托管服务，但不必把朋友、帖子和身份全部丢掉重来。域名 Handle 的意义，在于你的公开身份不再和某个单一服务器后缀绑死；而 DID 文档、签名密钥和恢复密钥，则构成了你迁移账号时的底层保障。
这套模型也意味着两个现实约束。第一，域名不是越早换越好，而是要在你能长期管理 DNS 和域名续费时再换。第二，迁移不是零风险动作。Bluesky 官方在 2025 年开放“迁回 Bluesky PDS”时明确提醒：账号迁移本身仍然可能是 destructive operation，做之前要先知道自己在迁什么、为什么迁、出了问题还能不能恢复。
准备材料
- 一个由你可长期控制的主域名或子域名。
- DNS 管理权限，能添加 TXT 记录；如果走批量子域名方案，还要能配置
.well-known路径。 - 当前 Bluesky 账号和 DID 信息。
- 一份简单的账号资产清单：当前 Handle、主要登录邮箱、PDS 状态、是否已有恢复材料。
- 计划迁移时的沟通窗口，避免在重大内容发布期切换身份。
步骤一：先决定用主域还是子域，不要一上来就改
官方教程支持两种思路：直接把主域名用作 Handle，例如 @example.com；或者给成员、栏目和团队账号分配子域名，如 @news.example.com 或 @name.example.com。如果你是个人品牌，主域名通常最稳；如果你要给多人或多栏目管理，子域策略更灵活。先把这件事想清楚，后面 TXT 记录和批量管理方式才不会反复改。
- 个人品牌或单一官方账号，优先考虑主域名。
- 团队、栏目、记者号或区域号，优先考虑子域名体系。
- 别把会频繁变更的活动域名拿来做长期 Handle。
- 如果你未来要多个账号共享同一母域，优先规划子域命名规则。
步骤二：按官方流程做 _atproto TXT 验证
Bluesky 官方教程给的验证方式非常直接：在账号设置里选择“我有自己的域名”，系统会显示你的 DID；然后去域名的 DNS 管理里添加 TXT 记录。主域名场景下，记录名是 _atproto；子域名场景下，则是类似 _atproto.me 这种带子域的记录名。值的格式是 did=did:plc:你的值。加完后等待 DNS 传播，再点 Verify DNS Record。
- 如果你的 DNS 实际托管在 Cloudflare，而不是注册商后台，就去 Cloudflare 加记录。
- DID 是公开信息，不是密码，但也别抄错一个字符。
- DNS 传播可能需要时间，不要连点十次就判断失败。
- 验证成功后，旧 Handle 的提及和标签仍会继续指向你的账号。
步骤三：多人子域管理时，别手动堆一百条 TXT
官方还给了一条更适合组织的方案：如果你要管理大量子域 Handle，可以不用每个都加 DNS TXT，而是在对应域名下返回 /.well-known/atproto-did，用 HTTP 200 和纯文本 DID 做解析。对媒体团队或公司来说，这条路线的价值很大，因为它把 Handle 管理从 DNS 表转成了可维护的配置层。前提是你真的有人维护这条路由，而不是加完就忘。
- 账号数量少时，继续用 TXT 记录最省事。
- 账号数量多、且都挂在同一母域时，再考虑
.well-known方案。 - 不论走哪条路，都给每个账号留一份 Handle 到 DID 的对应表。
- Handle 失效并不会立刻抹掉帖子和粉丝，但会影响身份连续性，所以要定期复查。
步骤四：把迁移理解成“带着身份搬家”，不是重新开号
AT Protocol 文档讲得很清楚：用户数据保存在签名的数据仓库里，DID 文档中有 signing key 和 recovery key。恢复密钥应由用户自己保管，例如纸质备份，而不是完全托管给服务商。这个机制的意义就在于，当 PDS 出问题或你想换托管时，你有机会在不丢身份的前提下带着数据搬走。也就是说，迁移的准备工作不是“临迁前再看一眼文档”，而是提前知道你的身份凭什么被证明、数据靠什么被带走。
- 至少记录当前账号的 DID 和使用的 Handle。
- 理解 recovery key 是你迁移能力的一部分，而不只是技术细节。
- 客户端会持续同步一份数据备份，但前提是你确实保有客户端和存储空间。
- 在准备迁移前，先停下频繁改 Handle、改域名和大规模重构资料的动作。
步骤五：回迁 Bluesky PDS 也有条件，不是任何人都能直接回
Bluesky 2025 年开放“迁回 Bluesky PDS”后，确实给了很多用户更强的心理安全感。但官方也写得很明白：这不是给从未拥有 bsky.social 账号的人开的直通车。能用这条路的是此前已经在 Bluesky PDS 上有 bsky.social 账号、后来迁出的人。回迁时，你需要登录现有的 bsky.social 账号，导入 repo，然后重新激活；系统会自动处理与之前状态的差异。
- 确认你以前是否真有过
bsky.social账号记录。 - 准备回迁前，先确认当前 repo 状态和账号访问链路正常。
- 按官方迁移流程导入 repo，再完成 reactivate。
- 把回迁当成高风险维护窗口处理，不要夹在重大发布中间做。
可复制账号资产模板
当前 Handle：
备用旧 Handle：
主域 / 子域：
DID：
DNS 管理位置：
验证方式：TXT / .well-known
是否有 bsky.social 历史账号：是 / 否
当前 PDS：
迁移负责人：
最近一次 Handle 验证日期：
最近一次账号资产复查日期：实际例子：把记者个人号和媒体官方号都挂到统一母域
一个小媒体团队原来每个人都用随机的 .bsky.social Handle，官方号和记者号也没有统一识别。更稳的做法是：官方号先用主域名作为 Handle，记者号和栏目号则规划成子域名；团队维护一份 Handle-DID 对照表，并在需要时用 .well-known 方式集中解析。这样未来不论某个账号是否要迁到其他 PDS，公开身份都更稳定，读者也更容易识别账号真伪。
验收清单
- 主域 / 子域策略已经定好，没有边用边换。
_atproto或子域 TXT 记录已正确添加并验证。- 多人账号时已有 Handle-DID 对照表。
- 团队已理解 recovery key、备份和迁移窗口的重要性。
- 准备回迁的人确认过自己是否符合
bsky.social历史账号条件。 - 重大发布期不会安排高风险迁移动作。
常见坑
- 把短期活动域名拿来做长期 Handle。
- DNS 实际托管在 Cloudflare，却跑去注册商后台反复改。
- 改完记录立刻判断失败，没有给传播时间。
- 多人账号每个都手工 TXT，后期维护失控。
- 把“可迁移”理解成“任何时候随手迁都没风险”。
排错路径
- 域名验证不过：先回查记录名是不是
_atproto或带子域的正确形式，再核对 DID 值。 - 子域多到难维护：考虑改用
.well-known/atproto-did方案。 - 担心迁移后丢身份：先确认 DID、恢复材料和当前 repo 状态，再决定是否继续。
- 想迁回 Bluesky PDS 却失败：先确认自己是否曾有
bsky.social账号，再按官方回迁流程走。 - 团队分不清哪些号是真的：统一域名策略，并把官方账号映射公开说明清楚。
后续维护建议
更新日期：2026-08-03。Bluesky 上最值得长期经营的，不是某个短期热点账号，而是可迁移的身份。只要你把域名控制权、Handle 验证、账号映射和迁移窗口管理好，未来无论平台产品怎么变，你手上都有一层更稳的资产，而不是被动跟着某个后缀走。