作品上架的三道门：OAuth 授权、临时凭证与内容校验

一、发布一个作品，比想象中多三道门

在开发者社区发一个作品，看起来只是「填标题、传截图、点提交」。实际走一遍会发现，中间横着三道校验：授权、凭证、内容。

我最近完整走了一次作品上架流程，把这三道门拆开记录，希望能帮到第一次发布的人少绕路。

二、第一道门：OAuth 授权

作品的代码仓库通常托管在第三方平台（GitCode、AtomGit 之类），平台需要拿到你在那边的身份，才能校验「这个仓库是不是你的」。

流程是标准的 OAuth 授权码模式：

1. 平台生成一个授权链接，带上 `client_id`、`redirect_uri` 和 `state`；
2. 你在第三方平台确认授权，回调时带回 `code`；
3. 平台用 `code` 换 `access_token`，之后用它调仓库接口。

几个实际会踩的点：

• 授权码一次性且短命。回调带回来的 `code` 只有几分钟有效期，页面挂着不动，过期后就得重新发起授权。
• 必须完成授权再提交。很多人卡在"作品提交失败"，其实是授权那一步的 token 根本没落盘。
• `state` 不要省。它是防 CSRF 的，回调时要校验与发起时一致。

三、第二道门：临时凭证

拿到第三方 token 之后，平台侧还需要访问自己的云资源（对象存储、构建服务）。这一步用的是临时凭证，而不是长期 AK/SK：

``` IAM 自委托（SELF_VERIFY） → 调用 STS AssumeAgency → 拿到临时 AK/SK/SecurityToken（默认 900 秒） ```

为什么不用长期密钥：

• 泄露面小。临时凭证 15 分钟就失效，即使日志里泄露也过期了；
• 权限可收敛。委托时可以指定策略，只给上传和校验必需的权限；
• 可审计。每次 AssumeAgency 都有记录，能追溯是谁在什么时候取的凭证。

实际开发时要注意：900 秒很短，如果上传的是几百兆的构建产物，中途凭证过期会直接失败。做法是在上传前判断剩余有效期，不足就重新申请一次。

四、第三道门：内容校验

这一层最容易被低估，也最容易被打回。

封面图不只是尺寸问题。很多平台会用程序在封面上渲染作品名称，这就要求：

• 字体文件必须能覆盖标题里出现的所有字符；
• 渲染前要做一次 glyph 覆盖率检查。

举个例子，标题里有「①」「→」这类符号，如果字体里没有对应字形，渲染出来就是方块（俗称豆腐块）。所以正确的做法是：先算字符覆盖，缺字形就换字体或退回系统默认字体渲染，而不是渲染完再肉眼检查。

详情包通常有固定结构：

``` README.md # 项目说明，平台会解析其中的标题与简介 resources/ # 图片、截图、演示素材 ```

如果 README 里的项目名和表单里填的不一致，校验会失败。这类「同源校验」很常见，提交前对一遍字段是最省时间的做法。

表单项也有字数区间。比如简介要求 15 到 50 个字符——太短说明信息不足，太长说明没提炼。写的时候一次到位，反复试会触发频率限制。

五、发布之后

提交成功后，平台一般会返回两部分东西：

• 作品 ID：后续查询、分享、统计都用它；
• 公网预览地址：通常是一个隧道域名，把本地端口映射出去，方便评审直接打开看。

这里有个细节：预览地址依赖隧道进程存活。本地服务停了，链接就 502。所以提交后要保持进程运行到审核结束。

六、三条能省时间的经验

1. 按顺序过门。先确认 OAuth token 已经拿到，再提交作品内容。跳过第一步直接提交，报错信息通常不会告诉你"是授权没完成"。
2. 凭证有效期要算进流程。临时凭证默认 15 分钟，大文件上传要预留重取凭证的逻辑。
3. 内容校验前置。字体覆盖率、README 字段一致性、字数区间，这三件事在本地就能检查完，不要留给服务端打回。

整套流程跑下来，真正花时间的不是编码，而是等授权、等凭证、等审核。把这三道门的顺序和边界搞清楚，第二次做就是重复劳动了。