GitLab Workflow插件功能全藏在命令面板，需Ctrl+Shift+P调用；仅支持SSH remote地址，MR流水线需手动刷新，状态60秒轮询且不实时，关键操作仍需跳转GitLab网页。
GitLab Workflow插件根本没在VSCode里显示菜单？
它不提供侧边栏入口，也不加右键菜单——所有功能都藏在命令面板里。装完插件后按 Ctrl+Shift+P（macOS 是 Cmd+Shift+P），输入 GitLab 才能看到可用命令。
常见错误现象：装完插件发现“什么都没变”，其实是没触发命令面板调用；或者工作区没关联 GitLab 项目，git remote 缺失或地址不是 GitLab 格式（比如用了 HTTPS 而非 git@gitlab.com:user/repo.git）。
- 确保当前文件夹是 Git 仓库，且
git remote get-url origin返回的是 GitLab 域名（如gitlab.com或自建实例域名） - 插件只支持 SSH 协议的 remote 地址，HTTPS 地址会静默失败——改用
git remote set-url origin git@gitlab.com:user/repo.git - 首次运行
GitLab: Login后，Token 存在 VSCode 全局设置里，不随工作区走；换账号得手动清理gitlab.token配置项
点开合并请求后看不到流水线状态？
插件默认只拉取 MR 列表和基础信息，流水线（Pipeline）、作业（Job）需要单独触发加载。这不是卡顿，是懒加载设计。
使用场景：你刚打开一个 MR 的详情页，右上角显示 “No pipelines found”，但 GitLab 网页端明明有正在运行的 CI。
- 在 MR 视图中点击右上角的
Refresh Pipelines按钮（图标是两个箭头绕圈） - 如果仍为空，检查 GitLab 项目是否启用了 CI/CD：进项目 Settings → CI/CD → General pipelines 必须为 enabled
- 流水线日志无法直接在插件里展开，点
View Job Logs会跳转到 GitLab 网页对应页面——别指望在 VSCode 里看完整输出
GitLab: Create Merge Request 提交后没反应？
这个命令不会自动 push 分支，也不会校验分支是否已推送到远端。它只生成 MR 表单，提交动作依赖你本地分支是否已存在远端对应分支。
参数差异：如果你当前分支叫 feat/login，但远端没有 origin/feat/login，插件会创建 MR，但目标分支（target branch）可能被默认设成 main，而源分支（source branch）字段为空或报错。
- 务必先手动执行
git push -u origin feat/login，让远端存在该分支 - MR 表单里的
Title和Description支持 Markdown，但不渲染预览——写完直接提交即可 - 如果项目启用了 MR 模板（
.gitlab/merge_request_templates/*.md），插件会自动填充 Description 区域，但只读取第一个匹配模板，不支持多选
为什么流水线状态老是不同步？
插件默认 60 秒轮询一次，不是 WebSocket 实时推送。你在 VSCode 里看到的「running」可能 2 分钟前就已变成「failed」，但界面还没刷新。
性能影响：高频轮询对自建 GitLab 实例压力明显，尤其当同时打开多个 MR 页签时；插件没有提供轮询间隔配置项，只能靠手动点 Refresh Pipelines。
- 不要依赖插件状态做自动化判断——比如“等 VSCode 显示 green 才继续开发”，实际应以 GitLab 页面或 API 返回为准
- CI 失败时，插件只显示
failed状态，不带错误码或 exit code；定位问题必须跳转网页看具体 job 日志 - 某些私有 GitLab 实例启用了 IP 白名单或反向代理限制，插件请求可能被拦截，表现为 pipeline 列表始终为空，但登录和 MR 列表正常——这时要查浏览器开发者工具 Network 里
/pipelines请求是否 403/502
GitLab Workflow 插件本质是个轻量桥接器，不是 GitLab 客户端替代品。它省去切网页的步骤，但关键操作、调试、权限控制，还是得回 GitLab 界面处理。
