GitCode OpenAPI 实战：用个人令牌完成仓库 Star 与 Issue 提交

一、为什么要用 API

在开源协作里，很多操作是重复的：给一批仓库点 Star、按模板提交 Issue、批量查询仓库信息。网页点一遍两遍还好，一旦变成每周、每天重复，就该交给脚本了。

GitCode 提供了 v5 OpenAPI，配合个人访问令牌（Personal Access Token）就能完成这些操作。本文用两个最小例子——Star 仓库、提交 Issue——把鉴权、调用和踩坑讲清楚。

二、准备个人令牌

在 GitCode 的设置页创建一个个人令牌，勾选所需权限（至少包含仓库读写与 Issue 相关权限）。

调用时有两种传法：

• 请求头：Authorization: Bearer <token>
• 查询参数：?access_token=<token>

建议用请求头，避免令牌出现在请求路径和访问日志里。本文示例为便于阅读使用查询参数，生产脚本请改用请求头。

先用一个只读接口确认令牌身份：

curl -s “$BASE/api/v5/user?access_token=$TOKEN”

返回里的 login 字段就是你的账号，注意区分 login 和显示名 name。

三、Star 一个仓库

GitCode 的加星接口是：

POST /api/v5/repos/{owner}/{repo}/star

示例：

curl -X POST
“$BASE/api/v5/repos/openJiuwen/agent-core/star?access_token=$TOKEN”

返回 200 即成功；随后查询 GET /api/v5/user/starred 可以看到该仓库出现在列表中。

踩坑一：仓库 path 不等于显示名

这是最容易卡住的地方。GitCode 返回的 full_name 可能包含中文显示名，例如：

full_name: 鸿蒙实践案例中心 / HarmonyOS-APP-sudoku
path: Harmony-APP-sudoku

请求路径里要用的是 path，不是 name、也不是 full_name 的后半段。用错会直接返回 404 Project not found。

稳妥做法是先取仓库元数据，再拼路径：

curl -s “$BASE/api/v5/orgs/<org>/repos?access_token=$TOKEN”
| jq -r ‘.[] | “(.namespace.path)/(.path)”’

踩坑二：不要照搬 Gitee 的端点

早期 Gitee 风格的 PUT /user/starred/{owner}/{repo} 在 GitCode 上会 404。GitCode 实际可用的是上面这个 POST /repos/{owner}/{repo}/star。

四、提交一个 Issue

Issue 接口：

POST /api/v5/repos/{owner}/{repo}/issues
Content-Type: application/json

请求体：

{“title”: “…”, “body”: “…”}

示例：

curl -X POST
“$BASE/api/v5/repos/<owner>/<repo>/issues?access_token=$TOKEN”
-H “Content-Type: application/json; charset=utf-8”
–data-binary @issue.json

其中 issue.json：

{
“title”: “【建议】为 README 补充快速上手指引”,
“body”: “## 现状\n…\n## 建议\n…”
}

几个实践建议：

1. 先看仓库有没有 Issue 模板，有就按模板填，维护者处理起来更顺。
2. 先查重：用 GET /repos/{owner}/{repo}/issues?state=all 看是否已有相同议题，避免制造噪声。
3. 标题写结论，正文写证据：现状、影响、建议，三段式足够。
4. 中文内容显式声明 UTF-8，否则容易出现乱码。

五、安全边界

• 令牌等价于账号密码，不要写进代码、不要提交到仓库、不要出现在截图里。
• 按最小权限创建令牌，只勾选需要的范围；用完后及时撤销。
• 写操作（Star、Issue、PR）都是公开行为，批量执行前先小范围试跑。
• 不要把令牌放进定时任务的 prompt 或日志中。

六、小结

GitCode v5 OpenAPI 的调用成本很低：一个令牌、两个端点，就能把重复的仓库操作自动化。真正需要留意的是两个细节——请求路径用 path 而不是显示名，以及端点风格与 Gitee 不完全一致。把这两点处理好，剩下的就是按业务需要组织脚本了。