Rust联邦社交服务端开发：贡献代码与扩展社交行为

项目标题里出现“开发者指南”这四个字，通常意味着两件事：一是这个项目已经过了“能跑就行”的阶段，开始在意别人能不能读懂、能不能改；二是它的扩展点还没铺满，需要外部贡献者一起把边界推出去。Enola Holmes 就是这样一个基于联邦协议的社交服务端实现，主体用 Rust 写成，单个可执行文件加一个 SQLite 文件就能跑起一个节点。这篇内容我想聊的是围绕它的贡献代码与扩展社交平台支持这两件事：怎么把开发环境跑通、怎么读懂请求在代码里流转的路径、怎么在不破坏兼容性的前提下新增一种社交行为，以及联邦通信里最容易翻车的签名与投递环节怎么排查。适合已经会一点 Rust、对分布式社交协议好奇、手上有个想实现的小功能却不知道从哪下手的人看。下面涉及的目录划分和部分实现细节，是按这类项目的通用做法补全的，具体字段以你手上的仓库为准，思路和坑位是通的。

1. 先搞清楚这个服务端到底在做什么

1.1 一个节点就是一封能被别人验证的信

刚接触联邦社交的人容易把它想得太复杂。剥掉所有术语，一个节点的职责只有三条：把自己的内容发布成别人能拉取的公开地址、接收别人推过来的活动、把接收到的活动按规则投递回来。这三条背后对应的是同一套东西——用 URL 标识每一个实体（用户是 URL、帖子是 URL、点赞也是 URL），用 JSON-LD 描述实体之间的关系，用 HTTP 签名证明“这条消息确实是我发的”。

Enola Holmes 的定位是轻量实现。主流的联邦服务端动辄要 Postgres、Redis、Sidekiq、Node 运行时一整套，装起来像搭一整套机房。轻量实现的选择是反过来：能用单进程解决的绝不上队列，能用嵌入式数据库解决的绝不上独立数据库服务，能用服务端模板渲染的绝不拆前后端。这个取舍直接决定了贡献代码时的思维习惯——你写的每一段逻辑，都要能在“一台 1 核 1G 的小机器”这个前提下成立。

我见过不少人一上手就想加缓存层、加消息队列、加读写分离，理由是“以后量大了怎么办”。在这类项目里这种想法通常是负收益：单节点的瓶颈很少在数据库，更多在网络往返和签名计算上，先把这两块做扎实比加中间件有用得多。所以读代码之前，先接受这个项目“故意不复杂”的价值观，能省掉很多无谓的改造冲动。

1.2 技术栈为什么长这样

Rust 在这类场景里的优势不是“快”，而是“占得少、崩得少”。一个常驻进程处理成千上万个签名验证请求，GC 语言会有内存抖动，Rust 没有；交叉编译出一个静态链接的二进制丢到小机器上就能跑，不用管运行时版本。代价也很实在：异步生态的心智负担高，编译时间长，写业务逻辑时所有权检查会反复打断你的思路。

所以你会看到一个典型的分层：HTTP 层用轻量框架做路由和中间件，业务层是纯函数式的处理器，存储层用同步数据库驱动包在阻塞任务里。这个分层不是审美选择，是在“异步运行时里不能随便阻塞”这条硬约束下逼出来的。理解了这一点，你就知道为什么写一个数据库查询不能直接在 async 函数里裸调——要么放进阻塞任务池，要么换成异步驱动。

另一个容易被忽略的选型是模板渲染。很多人第一反应是“都什么年代了还服务端渲染”。但对于一个要能离线部署、要在没有 CDN 的环境里也能看的社交节点，服务端渲染意味着首屏不依赖额外请求，也意味着前端代码不会成为贡献门槛。一个人想改个按钮文案，不需要先装一整套前端工具链，这个体验对开源项目拉新贡献者非常重要。

1.3 联邦协议的三个核心概念，用人话讲一遍

Actor（角色）：就是“账号”的协议表达。它是一个 URL，指向一份 JSON 文档，里面写着这个账号的名字、头像、公钥、收件箱地址。你可以把它想成一张名片，名片上印着“我的信箱在哪个地址，我盖章用的公钥是什么”。

Inbox / Outbox（收件箱 / 发件箱）：每个 Actor 都有这两个集合。你关注别人，本质是把自己的发件箱地址告诉对方，对方有新内容就往你的收件箱推一份。别人想看你的内容，就来你的发件箱拉。推送和拉取两条路径都要实现，缺一条就会出现“我能看到他，他看不到我”的诡异现象。

Activity（活动）：所有行为都是活动。发帖是 Create，转发是 Announce，关注是 Follow，点赞是 Like。活动本身也是一个带 URL 的 JSON 对象，这意味着“点赞”这件事可以被引用、被撤销（Undo）、被审计。

把这三点记住，读代码时会顺畅很多：你在任何一个处理器里看到的操作，几乎都能翻译成“某个 Actor 对某个对象做了一个 Activity”。

2. 把开发环境跑起来，别急着改代码

2.1 工具链与依赖准备

最稳的做法是先用项目自带的工具链声明文件锁定版本，别用你系统里那个“上次装完就没动过”的 Rust。版本不匹配导致的编译错误最浪费时间，而且报错信息通常指向标准库的内部实现，跟你的代码毫无关系。

# 用官方工具链管理工具安装，跟着项目声明文件走 rustup show # 看看当前默认工具链 rustup update stable cargo --version

数据库这块，大多数轻量实现默认用嵌入式数据库，本地开发不需要起任何服务，一个文件路径就够了。但有两个细节要注意：一是并发写入时嵌入式数据库会有锁竞争，本地单进程测试看不出来，压测时才会暴露；二是数据库文件所在目录必须可写，容器化部署时忘了挂卷，重启数据全丢。

环境变量一般需要这几类：对外域名、数据库路径、用于签名的密钥材料、监听地址。域名这一项在本地开发时最容易踩坑，后面单独讲。

export DOMAIN=localhost:8080 export DATABASE_PATH=./data/dev.db export LISTEN_ADDR=0.0.0.0:8080 export SECRET_KEY=$(head -c 32 /dev/urandom | base64)

提示：密钥材料生成一次就固定下来存好。开发期反复更换会导致已经投递出去的消息签名验证失败，而这类失败在日志里往往只表现为一个 401，非常难联想到是密钥变了。

2.2 编译、迁移、启动的三段式

第一次编译慢是正常的，依赖树里塞了 HTTP 框架、序列化、加密、模板引擎，十几分钟不算离谱。之后的增量编译会快很多，但如果你频繁改动被大量模块引用的核心数据结构，重新编译的代价会明显上升。这也是为什么贡献代码时，建议把“改数据结构”和“改业务逻辑”拆成两个提交。

启动前要跑数据库迁移。有些项目用编译期检查的迁移方案，好处是 SQL 写错在编译时就报错；有些用运行时迁移，好处是改起来方便。不管哪种，迁移都必须是幂等的，而且要有回滚思路——你要假设自己会在一个有数据的库上反复跑迁移，而不是每次都能删库重来。

cargo build --release cargo run -- migrate # 具体子命令以仓库为准 cargo run -- serve

服务起来之后，第一件要验证的事不是打开首页，而是访问自己的 Actor 文档。这个地址返回的 JSON 里，公钥、收件箱、发件箱三个字段齐全，说明基础数据模型没问题。如果这一步就 404，先去看路由表，别去翻业务代码。

2.3 本地两个实例互相联邦，这是最有效的验证方式

只跑一个实例，你永远测不出联邦逻辑。最靠谱的本地验证是同时起两个实例，端口不同，互相把对方当成“远端服务器”。

# 实例 A DOMAIN=localhost:8080 LISTEN_ADDR=127.0.0.1:8080 DATABASE_PATH=./data/a.db cargo run -- serve # 实例 B DOMAIN=localhost:8081 LISTEN_ADDR=127.0.0.1:8081 DATABASE_PATH=./data/b.db cargo run -- serve

这里有个几乎人人都会踩的坑：DOMAIN里带不带端口，会直接影响签名验证结果。HTTP 签名对Host头很敏感，如果DOMAIN写的是localhost，但实际访问地址是localhost:8080，那么对端计算出的待签字符串里 host 是localhost:8080，而你这边用的是localhost，两边对不上，验签必然失败。所以本地测试时，DOMAIN一定要带上端口，跟实际访问地址严格一致。

验证联邦是否真的通了，用 WebFinger 查询是最直接的探针：拿账号名去问对端“这个人的 Actor 地址在哪”，能拿到正确的 JSON 就说明发现机制是通的。这一步通了再去测关注、发帖、投递，问题定位会清晰得多。

2.4 编译和启动阶段的常见拦路虎

按我自己的经验排序，最常见的三类问题：依赖的本地库缺失（加密库、数据库驱动往往需要系统级依赖）、配置文件路径相对定位导致的“在项目根目录能跑、在别的目录不能跑”、以及端口占用但不报错只是超时。第三类最坑，因为日志里看不到任何异常，你会怀疑代码，其实只是前一个进程没退干净。

lsof -i :8080 # 看看端口被谁占了 ss -lntp | grep 8080

还有一个不常被提到的问题：某些加密相关的依赖在 Debug 模式下极慢，签名验证会慢到你以为是死锁。如果你在本地做压测，务必用--release构建，Debug 下的性能数据没有任何参考价值。

3. 读懂代码结构，才知道该往哪下手

3.1 目录与模块的对应关系

轻量实现通常按职责分模块，而不是按“控制器 / 服务 / 仓储”那套企业分层。下面这张表是我按这类项目的一般组织方式整理的，你可以拿来对照自己仓库里的实际结构：

理解这张表的价值在于：当你想加一个功能，先判断它落在哪一列。加个按钮属于渲染层，加个字段属于存储层，加个行为则同时涉及活动处理和联邦通信，这是工作量差别巨大的三类改动。

3.2 一次入站请求的完整生命周期

这是我最建议新人先摸清的路径，因为绝大部分 bug 都出在这条链路的某一环上。一条来自远端的活动，大致会经过这些环节：

1. HTTP 层接收 POST 请求，路由匹配到某个 Actor 的收件箱路径。
2. 中间件读取请求头，取出签名相关的几个字段，同时把请求体读进内存（因为要算摘要，必须完整读一次）。
3. 根据签名里的 keyId 去查对方 Actor 的公钥。这一步可能触发远端抓取，抓取结果要缓存。
4. 构造待签字符串，验签。失败直接返回 401，不进入业务逻辑。
5. 反序列化成活动对象。这里要做容错，远端可能带来你没见过的字段。
6. 按活动类型分发。每一种类型有独立的处理器。
7. 处理器内部做幂等判断（这个活动 ID 是不是处理过），然后落库、更新相关计数、生成通知或时间线条目。
8. 返回 202 或 200。注意返回码的语义，很多对端会根据返回码决定是否重试。

这里面第 7 步的幂等性是新手最容易漏的。联邦网络里重投是常态，不是异常。同一个 Create 活动可能被投递三次，你的处理逻辑如果没做去重，用户时间线里就会出现三条一模一样的帖子。做法通常是给活动 ID 建唯一索引，插入冲突就当成“已处理”直接返回成功。

3.3 从 issue 到 PR 的正确姿势

想贡献代码，第一步不是写代码，是找对入口。仓库里的好入门标签通常对应三类任务：文档修正、测试补充、错误处理完善。这三类任务看起来不性感，但它们能让你在不理解全貌的情况下先熟悉流程——怎么跑测试、怎么写提交信息、维护者关注什么。

分支命名和提交信息别自己发明格式。看一眼最近的提交记录，模仿它就对了。多数项目要求提交信息里带模块前缀，正文写清楚“改了什么”和“为什么改”，而不是“修了个 bug”这种等于没说的描述。

注意：提 PR 之前先把上游主分支同步一次，本地跑一遍完整测试。因为你的分支可能是三天前拉的，而主分支这三天里改了存储层的接口，合并时冲突还好说，逻辑冲突才要命。

测试这件事值得单独说。这类项目的测试通常是两层：纯函数层的单元测试（序列化、签名计算、路由匹配）和集成测试（用临时数据库跑完整请求）。你新增的行为，至少要给出一个能复现的集成测试，否则维护者没法判断你的改动在真实联邦场景下是否成立。

3.4 代码约定里那些没写在文档里的规矩

几个我观察到在这类项目里普遍成立的隐性约定。第一，错误类型要能区分“对端的错”和“我们的错”，前者返回 4xx 且不重试，后者返回 5xx 并允许重试，混在一起会导致无穷重试。第二，任何对外发起的 HTTP 请求都必须有超时，没有超时的远端调用在联邦网络里等于自杀。第三，日志里不要打完整的请求体，里面可能有用户的私密内容，打活动 ID 和类型就够了。第四，不要在处理器里直接发起网络请求，把它放进后台任务，否则一个慢对端就能拖垮你的收件箱。

这些规矩维护者未必会明说，但你的 PR 一旦违反，通常会收到“这里能不能改成异步投递”之类的评论。提前做对，能省一轮返工。

4. 签名与投递：联邦通信里最容易翻车的两块

4.1 HTTP 签名到底在签什么

用一个生活化的说法：你要给对方寄一封正式函件，信封上盖了公章，还写了寄出日期。对方收到后要做三件事——核对公章是不是你的（验签）、核对信封上的日期是不是最近（防重放）、核对信封里的内容和信封上写的摘要是否一致（防篡改）。

技术上对应的是：把请求方法、路径、Host、Date、以及请求体的摘要，按固定顺序拼成一个字符串，用私钥签名；对端用你的公钥验证。拼接顺序和字段名必须完全一致，多一个空格都会失败。

(request-target): post /users/alice/inbox host: remote.example:8080 date: Tue, 01 Apr 2025 10:00:00 GMT digest: SHA-256=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

摘要的计算方式是对请求体做一次 SHA-256 再 base64。命令行验证很方便：

printf '%s' "$BODY" | openssl dgst -sha256 -binary | openssl base64 -A

实践中最常见的失败原因是待签字符串的构造细节：有的实现把方法名写成大写，有的写小写；有的把路径里的查询参数也算进去，有的不算；有的把Host头的值做了端口归一化。跨实现互操作时，这些细节差异就是 401 的主要来源。排查方法很土但有效——把两边的待签字符串都打出来，逐字符比对。

4.2 时钟偏差与 Date 头

签名里带Date头是为了防重放。对端一般允许正负五分钟的偏差，超过就拒绝。这在容器环境里特别容易出事：宿主机的时钟漂移了，容器里继承的是漂移的时间，所有出站请求都会被对端拒绝，而你的日志里只有一堆 401。

排查思路很直接：对比本地时间和一个可靠时间源，偏差超过几十秒就要处理。这不是代码问题，是部署问题，但表现出来完全像代码 bug。

date -u curl -sI https://example.com | grep -i '^date'

还有一个隐蔽的坑：某些代理或网关会重写Date头。如果你的服务前面有一层反向代理，它可能会用自己的时间覆盖你签过名的Date，导致签名失效。这种情况要在代理层配置透传，而不是在应用层想办法。

4.3 投递队列与重试策略的设计

投递不能同步做，这一点没有商量余地。你对一个帖子点了发布，可能要投给两百个关注者，其中三个对端挂了，同步投递会让你的请求卡住几十秒。正确做法是发布时只落库，把投递任务写进队列，由后台工作者慢慢消化。

重试策略我倾向于指数退避加抖动：第一次失败等一分钟，第二次五分钟，第三次十五分钟，依次拉长，最多重试若干次后进死信表。加抖动是为了避免大量任务在同一时刻集体重试，把自己的出口带宽打满。

超过上限进死信表，提供手动重投的入口。死信表的价值不在于重投，而在于让你能看清“到底有多少对端长期不可达”，这个数据对判断实例健康状况很有用。

队列的存储也别搞复杂了。既然是单机部署，用数据库里的一张任务表就够，加个状态字段和下次执行时间，后台工作者定时扫。引入独立的消息队列组件会让部署复杂度翻倍，收益在这个规模下几乎为零。

4.4 调试联邦问题的三板斧

第一板斧是读日志，但要读对字段。有效的日志应该包含：活动 ID、活动类型、来源 Actor、处理结果、失败原因。没有这几项，日志基本没法用。

第二板斧是手动构造请求。用 curl 伪造一个带签名的入站请求，能快速区分“是我的处理逻辑错”还是“对端根本没发过来”。构造时注意摘要必须和实际请求体一致，很多人改了 body 却忘了重算 digest。

curl -X POST http://localhost:8080/users/alice/inbox \ -H "Content-Type: application/activity+json" \ -H "Date: $(date -u '+%a, %d %b %Y %H:%M:%S GMT')" \ -H "Digest: SHA-256=$(printf '%s' "$BODY" | openssl dgst -sha256 -binary | openssl base64 -A)" \ -H "Signature: keyId=\"...\",headers=\"(request-target) host date digest\",signature=\"...\"" \ --data "$BODY"

第三板斧是拿一个已知能互通的对端做对照测试。如果 A 能收到 B 的消息，但你收不到，那么问题大概率在你的验签或路由上，而不在协议理解上。对照测试能把搜索空间砍掉一大半。

5. 扩展社交平台支持：新增一种社交行为

5.1 先分清你要做的是哪一层扩展

“扩展社交平台支持”这句话很宽，落到代码上至少有三种完全不同的量级，选错了会做大量无用功。

第一种是新增活动类型。比如社区里想支持“带表情的回应”这种比点赞更丰富的互动。这是最常见的扩展，涉及入站解析、出站构造、存储、渲染四处改动。

第二种是新增对象类型。比如支持除文本帖之外的某种结构化内容。这类改动会牵动序列化、渲染、卡片预览，工作量明显更大。

第三种是新增协议能力。比如支持某种内容发现机制或服务元信息描述。这类改动往往不涉及数据模型，但要考虑对端不认识时的降级。

先判断清楚再做，比闷头写代码重要得多。很多人把第三种当成第一种做，结果写了一大堆数据结构，最后发现根本不需要存。

5.2 以“自定义表情回应”为例拆解

选这个例子是因为它的兼容性问题最典型：你对端可能根本不认识这个活动类型，你得保证在那种情况下不会把对方的实例搞崩，也不会让自己的数据变脏。

先看数据模型。回应本质上是“某个 Actor 对某个对象表达了一种带内容的态度”，跟点赞同构，只是多了内容字段。

CREATE TABLE reaction ( id TEXT PRIMARY KEY, -- 活动的全局唯一标识 actor_id TEXT NOT NULL, object_id TEXT NOT NULL, content TEXT NOT NULL, -- 表情或短语 created_at TEXT NOT NULL, UNIQUE(actor_id, object_id, content) ); CREATE INDEX idx_reaction_object ON reaction(object_id);

唯一约束里带上content是关键设计决策：同一个人可以对同一个帖子表达多种回应，但不能对同一种回应重复表达。这个语义要在建表时就定下来，后期改索引很麻烦。

再看解析结构。这里要处理两个现实问题：字段可能是数组也可能是单值（联邦协议里很多字段允许两种形态），以及必须保留未知字段以便后续转发时不丢信息。

#[derive(Debug, Serialize, Deserialize)] pub struct ReactionActivity { pub id: String, #[serde(rename = "type")] pub kind: String, pub actor: String, pub object: String, pub content: String, #[serde(rename = "@context")] pub context: serde_json::Value, #[serde(flatten)] pub extra: serde_json::Map<String, serde_json::Value>, }

extra那个字段看起来可有可无，实际上是兼容性的关键。对方可能在这个活动上附带了你没有定义的扩展字段，如果你反序列化时把它们丢掉，之后转发给第三方时信息就缺失了。转发场景下这个损失是不可逆的，所以宁可多存一点。

5.3 入站处理：不认识的类型怎么优雅退化

分发逻辑通常是一个大的类型匹配。新增类型时，我倾向于加一个“未知类型兜底”分支，把不认识的活动原样存进一张审计表，附上接收时间和来源。这样做的理由很实际：联邦协议在演进，今天你不认识的活动，明天可能就是主流，留着原始数据将来能补解析。

match activity.kind.as_str() { "Create" => handle_create(activity).await, "Announce" => handle_announce(activity).await, "Like" => handle_like(activity).await, "EmojiReact" => handle_reaction(activity).await, other => { store_unknown_activity(other, &raw_body).await } }

还有一个必须想清楚的问题：如果对端发来的回应类型不在你的白名单里（比如内容是一段很长的文本），你要不要接受？我的建议是限长并且过滤控制字符。字符串长度不做限制的话，一条活动就能把页面布局撑坏，这不是理论风险，是联邦网络里真实发生过的骚扰手段。

5.4 出站侧：投递与降级策略

出站要做的事：用户产生回应 → 构造活动对象 → 存入本地表 → 生成投递任务 → 后台投递到原帖作者和参与者的收件箱。

这里有个取舍值得展开：如果对端不支持这种回应类型，你要不要降级成普通的点赞投递一份？两种做法各有道理。降级的好处是对方至少知道“有人互动了”；坏处是会污染对方的通知，而且是重复通知（回应和点赞都发一份）。我倾向于不降级，但把回应同时以点赞的形式存进本地统一互动表，这样时间线和计数逻辑不用改两套。

至于投递目标，别一股脑投给所有人。回应这种轻量互动，投给原帖作者和被回应的对象就够了，投给整个参与者列表会让热门帖子的投递量爆炸。这个判断在代码里就是一个地址收集函数的边界条件，但它直接决定了你的实例在大流量下的存活能力。

6. 互操作性与回归验证怎么做得靠谱

6.1 建一张互操作矩阵比写一百行测试有用

联邦协议的麻烦在于“你觉得自己实现了，对端不这么认为”。我习惯在动手前先列一张矩阵，把能力、期望行为、验证方式三列写清楚，做完一项就填一项。

这张表最大的价值不是给测试用，是给讨论用。跟维护者讨论 PR 时，把矩阵一贴，对方立刻知道你考虑过边界情况，评审会顺畅很多。

6.2 用固定夹具构造联邦场景

集成测试的难点是“怎么造一个真实的远端”。比较务实的做法是把远端响应录成固定文件，测试时读文件而不是真的发网络请求。

#[tokio::test] async fn reaction_from_remote_unknown_type_is_stored() { let fixture = include_str!("fixtures/reaction_unknown.json"); let app = test_app().await; let resp = post_inbox(&app, fixture).await; assert_eq!(resp.status(), 202); assert_eq!(count_unknown(&app).await, 1); }

夹具要覆盖几种极端情况：字段是数组的、字段缺失的、带大量未知字段的、时间格式不规范但能解析的。这几类加起来大概能覆盖八成真实世界的脏数据。

6.3 上线前的灰度思路

这类项目没有“全量上线”的概念，但你的实例一旦跟外部世界通了，改动的影响就是不可撤回的。我的做法是先在测试实例上挂两三个小号，手动跑一轮完整交互，观察日志里有没有异常的验签失败峰值。如果有，说明你的签名构造改了但没改全，这是最容易引发连锁故障的改动类型。

注意：不要在生产实例上直接试新的活动类型。这类改动一旦写入了错误的数据格式，清理起来非常麻烦，因为你还得考虑已经投递出去的活动在对端的状态。

7. 常见问题与排查技巧实录

7.1 问题速查表

7.2 几条我踩过的坑

签名失败但不报原因。早期我在验签失败时只返回一个笼统的 401，结果联调时两边互相甩锅。后来改成把失败的具体环节（取不到公钥 / 摘要不匹配 / 时间超窗）写进日志，排查效率立刻不同。这类可观测性改进虽然不产生功能价值，但对一个需要跟外部世界打交道的项目来说，价值可能比新功能还高。

在处理器里同步抓远端文档。这会导致一个响应慢的对端把你的请求处理链路全堵住，因为你的处理器在等网络。改成抓取结果带缓存、缓存过期才回源，并且回源放在后台任务里，收件箱的响应时间立刻稳定下来。

迁移文件改了又改。我在本地反复修改同一个迁移文件，本地库删了重建没问题，但别人的库已经跑过旧版本，再跑新版本就会冲突。规矩很简单：合并过的迁移文件一律只增不改，改字段就加新迁移。

过度设计导致 PR 被打回。我第一次提 PR 时顺手把投递逻辑重构成了一套抽象层，想着“以后方便扩展”。维护者的回复很直接：这个项目要的是能被一个人看懂，抽象层反而增加了理解成本。后来我改成只做必要的改动，PR 顺利合并。这件事让我明白，在轻量项目里，克制比技巧重要。

忘了处理撤销。互动的撤销路径比创建路径更容易被漏掉。测试的时候只测了“能点赞”，没测“点赞后能取消”，结果上线后计数只增不减，用户看着数字对不上。现在的习惯是，任何创建型的行为，测试用例必须成对：创建 + 撤销。

8. 给准备动手的人几句实话

如果你打算在这个项目上做点事，我的建议是先花一个下午把两个实例的联邦跑通，手动发几条活动，看看数据库里多了什么、日志里打了什么。这个“手感”比读十遍文档都管用。联邦社交的复杂度不在单点技术上，而在“任何一个小改动都会被外部世界放大”这一点上——你改了一个字段的序列化方式，可能对端就全挂了，而挂的表现只是对方时间线里少了几条内容，不会有人来给你报错。

动手写功能的时候，先问自己三个问题：对端不认识这个新东西会怎样、网络抖动会不会导致重复、出问题之后靠日志能不能定位。这三个问题能提前筛掉大部分返工。至于代码风格、抽象层次，跟着仓库现有的写法走就行，别在一个强调“单机可读”的项目里炫技，那是最容易被拒绝的一类贡献。