sublime text 不支持原生 pr 审查，需借助 github cli（gh）配合手动操作实现：先 gh pr checkout 拉取分支，再 git diff 生成 patch 或打开文件对比，最后用 gh pr comment 提交评论。
Sublime Text 里根本没法直接审查 PR
Sublime Text 没有原生 PR 审查能力，SublimeGitHub 插件只支持 gist、blame、open file on GitHub 等基础操作，不提供 diff view、行内评论或审批功能。它调用的是 GitHub API 的 /gists 和 /repos/{owner}/{repo}/contents 路径，而非 /pulls 相关端点。
如果你在命令面板里搜 GitHub: Review Pull Request 却找不到——这不是你漏装插件，是它压根没实现这个功能。
- 所有“审查 PR”类需求，必须跳转到浏览器或换用 VSCode +
GitHub Pull Requests and Issues扩展 -
SublimeGitHub的GitHub: Open Pull Request命令实际只是打开 PR 页面 URL，不加载 diff - 想在 Sublime 里看变更？只能手动
git checkout到对应分支，再用git diff输出重定向到临时文件查看
用 GitHub CLI 把 PR 内容拉进 Sublime Text 审查
虽然不能直接审查，但可以用 gh 把 PR 的变更落地为本地文件，再用 Sublime Text 打开对比——这是最贴近“编辑器内审查”的可行路径。
执行这三步：
- 运行
gh pr checkout <pr-number></pr-number>，它会自动添加远程、fetch 分支、创建并检出本地跟踪分支（如pr/<pr-number></pr-number>） - 用
git diff main...pr/<pr-number> --name-only</pr-number>获取改动文件列表，复制粘贴进 Sublime Text 的侧边栏拖入（或用subl <file></file>命令打开） - 对关键文件，可生成 patch：
git diff main...pr/<pr-number> -- <file> > /tmp/pr.patch</file></pr-number>，再用 Sublime Text 打开/tmp/pr.patch查看结构化 diff
注意：gh pr checkout 依赖当前目录是已关联远程的 Git 仓库；若报错 failed to get base repo，先确认 git remote get-url origin 能正常输出，且远程名确实是 origin。
Sublime Text 配合 CLI 审查时容易踩的坑
这套组合拳看似简单，实操中几个细节常导致白忙活：
- Sublime Text 默认不监听 Git 状态变化——你
gh pr checkout后切回编辑器，它不会自动刷新文件树或高亮新分支下的修改。得手动右键文件 →Revert或重启窗口 -
gh pr diff输出的是 raw diff，直接复制进 Sublime 不带语法高亮；需安装DiffView插件，或把内容保存为.diff后缀再打开 - 如果 PR 修改了大量文件（比如重构），
git diff默认只显示前 100 个；加--stat先看范围，再用--name-only | head -n 20控制载入量，避免 Sublime 卡死 - 审查完想提 comment？别指望 Sublime 发出去。必须回到浏览器或用
gh pr comment <pr-number> --body "..."</pr-number>提交，且 body 不支持富文本或代码块渲染
为什么不用 VSCode 就硬要用 Sublime + CLI
真有这种需求，通常是因为团队强制用 Sublime、或本地环境受限（比如只允许轻量编辑器 + CLI 工具链）。这时候要接受一个现实：PR 审查的核心动作（评论、审批、状态更新）永远发生在 GitHub 服务端，编辑器只是展示层。
所以重点不是“怎么让 Sublime 变成审查工具”，而是“怎么让 Sublime 最快看到你想看的那几行代码”。删掉所有幻想中的图形化 PR 面板，专注做好三件事：快速定位变更文件、干净呈现 diff 内容、无缝跳转到 CLI 提交反馈——剩下的，交给浏览器或 gh 命令补全。
