取仓库文件有两个口：readme_file 与 files，base64 要先看 encoding 再解

做仓库文档核对时，「把这个仓的 README 拿下来」是最常见的一步。GitCode 有两个口能干这事，但形状不一样，值得分开记。

一、readme_file：给门面文件，字段最全

GET /api/v2/projects/{enc}/repository/readme_file?ref=main

实测顶层字段：aigc / audit_result / blob_id / branch / content / data_id / encoding / file_name / file_path / file_type。前三个非典型字段挺有意思——内容治理（是否 AIGC、审核结果、数据标识）是在接口层就带出来的，而不是只在页面里显示。取正文只需要 content 和 encoding：

j = get(url)                      # encoding == "base64"
text = base64.b64decode(j["content"]).decode("utf-8", "replace") \
    if j.get("encoding") == "base64" else j["content"]

那次测的 README，readme_file 返回的 content 字段是 5244 个字符，而 files 接口报的 size 是 3931 字节——前者是 base64 编码后的长度，后者才是文件本身的大小，这两个数不能混用。

不要无条件 b64decode：一旦服务端哪天直接回明文，解码会抛出看不懂的字符错误，或者更糟——恰好解成一段乱码还「解成功了」。判 encoding 再决定，是这种接口唯一稳的读法。

二、files：按路径取任意文件，判存在要读状态码

GET /api/v2/projects/{enc}/repository/files?ref=main&file_path=README.md

返回里有 encoding、size、content。我用它核对过三个仓的两个文件：README.md 正常回 encoding=base64, size=3931；而 .gitmodules、requirements.txt 这种不存在的文件，回的是 404，body 里带 message，content 直接是空。所以判「仓库里有没有这个文件」的正确姿势是读 HTTP 状态，而不是 try/except 把 404 咽下去当成「没有」——无权限、路径写错、仓不存在这三件事也会走异常路径，混成一个结论就冤枉了仓库。

三、ref 不能硬编码

第一轮审计我给所有仓都写死 ref=main，其中一个仓拿回来的树是空的，我差点把「README 里写的目录不存在」当成缺陷提出去。正确做法是从项目详情接口把 default_branch 取出来再用。我这次测的六个案例仓与三个 Agent 实践中心仓默认分支都是 main，但这条不能外推——「我没读到」和「它不存在」是两个命题，中间隔着一次 ref 参数确认。

四、两个口怎么配合

我的用法是：先看门面用 readme_file（一次调用就够，还顺便拿到 file_name 确认到底是 README.md 还是 readme.markdown）；要逐个文件核对文档里提到的路径，再用 files 精确问一次，把状态码原样记进结论表。这样最终写出来的每条断言都能指到「哪个 ref、哪个 file_path、回了什么码」，而不是一句「我 clone 看了一下」。