GitLab自托管实战：从Docker部署到CI/CD高频操作与避坑

1. GitLab是谁，为什么值得折腾

先聊一个看着有点傻、但几乎每天都会有人问的问题：GitLab 到底是干嘛的？它本质上就是一套可以自己部署的代码托管平台，跟 GitHub、Gitee 做的事差不多——管理代码仓库、处理合并请求、跑 CI/CD 流水线、发 Release 包。但最大的区别就一条：GitHub 的代码放别人服务器上，GitLab 你可以整个搬回公司内网或自己的服务器，仓库、权限、流水线全部自己掌控。

我为什么从 GitHub 切换到 GitLab？最开始其实是被逼的。公司要求代码不能出内网，又想要 GitHub 那种 Pull Request 协作体验，选了 GitLab 一用就是好几年，慢慢才体会到它真正值钱的地方。对个人开发者来说，GitLab 的免费版也够用：不限仓库数量、支持私有仓库、自带 CI/CD，光最后一条就能省掉单独搭 Jenkins 的不少事。对团队来说，自托管之后权限控制、审计日志、LDAP 对接都做得非常顺手，代码安全性也更有底。

这篇我打算把 GitLab 从部署到日常使用的高频操作串一遍，重点讲那些教程里经常一笔带过、但实操时一定会踩的坑。适合三类人看：刚接触 GitLab、装了不知道从哪入手的同学；打算在企业内网自建代码平台的运维或技术负责人；以及已经在用 GitLab、但被配置 SSH、Token、CI/CD 这些细节卡过的人。

2. 部署落地：Docker 是当前最稳的入口

自托管 GitLab 有两种主流方案：官方推荐的 Omnibus 包（直接装在 Ubuntu/CentOS 上）和 Docker 部署。如果你不是有特殊的性能调优需求，我建议直接用 Docker。原因很简单：Omnibus 装的时候依赖挺多，升级、回滚、迁移都比较麻烦；Docker 把 GitLab 的依赖全部封装好了，数据目录挂载出来，升级就是拉一个新镜像重启容器，出了问题还原也容易。

2.1 用 docker-compose 拉起一套 GitLab

先交代环境。我在一台 Ubuntu 20.04 的机器上实操，配置是 4 核 8G 内存、100G 磁盘。GitLab 对内存要求比一般的 Web 应用高，官方说 4G 是起步，我实测下来 4G 跑起来有点吃力，编译流水线一跑就容易卡，建议至少 8G。

直接看 docker-compose.yml 的写法：

version: '3.8' services: gitlab: image: gitlab/gitlab-ce:16.11.2-ce.0 container_name: gitlab restart: always hostname: gitlab.example.com environment: GITLAB_OMNIBUS_CONFIG: | external_url 'http://gitlab.example.com' gitlab_rails['gitlab_shell_ssh_port'] = 2222 unicorn['worker_processes'] = 4 postgresql['shared_buffers'] = "256MB" ports: - "80:80" - "2222:22" volumes: - /srv/gitlab/config:/etc/gitlab - /srv/gitlab/logs:/var/log/gitlab - /srv/gitlab/data:/var/opt/gitlab shm_size: '256m'

几个关键点说明一下。external_url 是你访问 GitLab 的地址，如果你没有域名，可以直接写 http://服务器IP，例如 http://192.168.1.10，这样浏览器里可以直接通过 IP 访问。gitlab_shell_ssh_port 这个参数很多人会漏，它的意思是 GitLab 对外提供 Git 操作的 SSH 端口。因为容器内部 sshd 监听在 22 端口，而宿主机 22 端口通常已经被系统自己的 sshd 占用了，所以我把宿主机的 2222 映射到容器内的 22。而且访问仓库时的克隆地址，GitLab 会根据这个配置生成 ssh://git@gitlab.example.com:2222/group/project.git 而不是常规的 git@gitlab.example.com:group/project.git 格式。这个细节不设对，后面 clone 代码很容易碰到连不上的问题，而且用 Git 检查时会提示端口不匹配。

volumes 挂载了三个目录：config 保存 GitLab 的配置，logs 存日志，data 存仓库数据、数据库。这三个目录必须挂出来，否则容器一删，你的代码仓库和历史记录就全没了。我第一次部署时没挂数据目录，想升级版本直接丢了近一个月的提交记录，那种教训一次就够了。

2.2 首次启动与默认密码

镜像比较大，首次启动按照机器性能和网络状况，大约需要 3~8 分钟。怎么判断初始化完成了？盯着容器日志：

docker compose logs -f gitlab | grep "Running configuration change"

或者直接等浏览器打开页面，看到 GitLab 的欢迎页说明起来了。首次访问时，GitLab 会让设置 root 用户的密码，至少 8 位。这是管理员账号，权限极大，密码务必记牢。

然后遇到之前热搜里频繁出现的"gitlab login failed. check api token or gitlab version. log in via git if the version is older"这个报错，其实是 VSCode 的 GitLab 插件在探测 API 版本时失败导致的，一般分三种情况：一是你 Token 真的配错了，二是 GitLab 版本旧、插件不兼容，三是插件权限不够。解决办法我在后面 Token 那一节详细说，这里先知道有这么个坑。

3. SSH 密钥配置：第一次拉代码前必做的事

很多新手卡在"配置 GitLab 免密拉取"这步，其实 SSH 密钥的原理很简单：你生成一对公私钥，把公钥交给 GitLab，私钥留在自己电脑上。以后 Git 跟 GitLab 通信时，GitLab 用公钥验证你的身份，你的私钥负责签名，类似于你随身带了一把只属于自己的印章，盖章之后对方能验明真身但是学不会你的印。

3.1 生成密钥并添加到 GitLab

这一步主要在本机操作，通用做法：

cd ~/.ssh ssh-keygen -t ed25519 -C "youremail@example.com"

生成的 id_ed25519 是私钥，id_ed25519.pub 是公钥。然后查看公钥内容并复制：

cat ~/.ssh/id_ed25519.pub

把输出的整串内容复制到 GitLab 的 Settings -> SSH Keys 页面，标题随便起个好认的名字，Expiration date 建议留空或设长一点，否则到期后你又得重新配一遍。

为什么我推荐 ed25519 而不是传统的 RSA 2048/4096？性能更快、密钥更短、安全性理论更强，而且 GitLab 十几版本之后对 ed25519 支持已经很成熟。RSA 兼容性是好，但除非你要兼容很老的系统，否则 ed25519 足够了。

3.2 本机 SSH config 与端口适配

如果你前面用 Docker 部署并且把宿主机 2222 映射到了容器 22，那还需要在 ~/.ssh/config 里加一段配置，不然 git clone 时会默认走 22 端口连到宿主机自带的 sshd，连到的根本不是 GitLab：

Host gitlab.example.com HostName gitlab.example.com Port 2222 User git IdentityFile ~/.ssh/id_ed25519

如果你访问 GitLab 用的是 IP，比如 http://192.168.1.10，那 Host 和 HostName 都填 192.168.1.10。测一下能否连通：

ssh -T git@gitlab.example.com -p 2222

看到Welcome to GitLab, @username!就说明密钥配置成功了。很多人在这一步会卡很久，我见过最典型的错误是直接把公钥加到 GitLab 后，没配置 ~/.ssh/config，结果 clone 时一直提示 Permission denied (publickey)，其实就是 ssh 客户端用了系统 sshd 的 22 端口，而不是 GitLab 监听的 2222 端口。你只要在 config 里把端口指对，问题立刻消失。

4. 登录、Token 与常见认证报错

4.1 422 登录错误和隐身模式

"gitlab 422 登陆的错误,隐身模式可以登陆"这个热搜组合非常有意思。422 通常意味着请求被 CSRF 校验拦住了，根本原因是浏览器的 Cookie 或缓存里有旧的 GitLab 会话信息，跟新部署的 GitLab 的加密密钥对不上。你开隐身窗口访问，浏览器完全没有旧会话状态，所以能正常登录；一旦用回普通窗口，旧 Cookie 还在，GitLab 校验不通过就报 422。

解决办法很简单：清除该站点 Cookie，或者直接换隐身窗口。另外如果你的 GitLab 开启了强制 HTTPS，而浏览器缓存里还存着 HTTP 的会话，也会出现类似问题。这种情况我建议干脆换个新浏览器登录一次，再回旧浏览器清理缓存，省得纠结。

4.2 GitLab Token：分类与获取位置

Token 在 GitLab 里主要有这么几类：

• Personal Access Token：个人访问令牌，代替密码操作 API 或进行 Git 操作。
• Project Access Token：项目级令牌，权限范围只限当前项目下，适合 CI/CD 使用。
• Group Access Token：组级令牌，管理一个组下的所有项目。
• Deploy Token：只读或读写特定项目的仓库和镜像仓库，适合自动部署场景。

PTA 在哪里创建？登录 GitLab 后，点击左下角头像，进入 Preferences（偏好设置），左侧菜单里有 Access Tokens。如果新版界面不好找，也可以直接访问地址：http://你的GitLab地址/-/profile/personal_access_tokens。

创建时注意勾选 scopes。pull 代码只需要 read_repository；通过 API 创建项目、管理仓库需要 api 权限；要用 GitLab 的 Git LFS 还要 read_repository 配合 write_repository。Token 只显示一次，关掉页面就再也看不到了，务必复制到自己的密码管理工具里。

很多人在 VSCode 里配置 GitLab 插件时填了 Token 却一直报login failed. check api token or gitlab version，我排查过几个真实案例，原因基本是勾选 scope 时只选了 read_user，没选 api。VSCode 插件通常要调用 GitLab API 获取项目列表、创建 MR 等信息，没有 api 权限自然失败。遇到这个报错先别怀疑版本，先检查 token 权限。当然如果你的 GitLab 版本比较老（13.x 以下），也确实是插件太新导致不兼容，那就需要升级 GitLab 或插件版本。

4.3 未授权访问漏洞与快速加固

GitLab 多次出现过高危漏洞，比如未授权访问接口、SSRF、存储型 XSS。听到"未授权访问漏洞常见路径有哪些"这种问题，说明大家确实关心安全。这里给几个重点路径供自查：

• /api/v4/users：如果可以不登录就枚举出所有用户信息，说明注册功能配置有风险。
• /users/sign_up：匿名用户可以注册账号，一旦注册成功可能访问到内部项目。
• /admin 相关接口直接暴露在公网且未加保护。

针对这些风险，最有效的手段是：第一，升级到最新稳定版，很多高危漏洞是版本太旧导致；第二，关闭公开注册，在 Admin Area -> Settings -> Sign-up restrictions 里取消 Sign-up enabled 勾选；第三，用反向代理在 Web 层加 IP 白名单，限制 /admin、/api 的访问来源；第四，如果不需要公网访问，干脆不暴露到公网上，或者放在内网使用。上次公司内网因为某个老版本 CVE 被人探测扫描，我第一时间升级并关了注册入口，半天就消停了，说明基础加固比上复杂安全设备更管用。

5. 创建项目、拉取代码与本地推送

5.1 创建项目并上传本地代码

在 GitLab 首页点击 New project，有三种方式：Create blank project（空项目）、Create from template（模板项目）、Import project（从其他平台导入）。我平时用 blank 最多，填好项目名，可见性选 Private，初始化时勾选 Add README。

如果本地已经有一个项目要推上去，不需要在界面上勾 README，直接按下面的命令操作：

cd 你的项目目录 git init git add . git commit -m "Initial commit" git branch -M main git remote add origin http://gitlab.example.com/group/project.git git push -u origin main

注意 remote add origin 后面这个地址，推荐用 SSH 形式（ssh://git@gitlab.example.com:2222/group/project.git），因为 SSH 不用每次输入密码，也不容易触发 token 失效问题。如果你不想处理 SSH，那就用 HTTP 地址，但 push 时大概率要求输入用户名和访问令牌，密码框里填你的登录密码会一直验证失败，填 Personal Access Token 才可以通过。这个坑已经有太多人踩过，我朋友第一次在 HTTP 下推送，输错了五次密码，最后才发现要用 Token，气得差点删库。

5.2 拉取代码到本地

从零开始拉一个新项目到本地，常见的路径：

git clone git@gitlab.example.com:group/project.git

如果你按前面 Docker 部署的方式做了端口映射，那 clone 地址是：

git clone ssh://git@gitlab.example.com:2222/group/project.git

项目已经有代码、有远程分支，你只想拉最新代码，就进到项目目录执行：

git fetch --all git pull origin main

如果本地分支与远程分支的提交历史不一致，pull 报冲突，可以改用 pull --rebase 把本地提交暂存、拉取远程新提交后在本地重放。团队协作时这个命令更常用，因为它能保持提交历史线性，不会频繁出现 merge commit。

5.3 VSCode 和 IDEA 配置 GitLab

VSCode 里使用 GitLab，官方推荐安装 GitLab Workflow 扩展，它会读取你打开的本地仓库、自动识别远程仓库地址，然后调用 GitLab API 显示流水线状态、MR 列表等。前提是：本地先安装好 Git，然后在 VSCode 设置里搜索 gitlab.gitlab.baseUrl 填你的 GitLab 地址，比如 http://gitlab.example.com，再配置 gitlab.gitlab.token 填访问令牌。如果配置完了还是连不上，多半是 baseUrl 写成了 gitlab.example.com 少了 http 协议，或者 token 权限不对，按我前面说的排查路径走一遍就解决了。

IDEA 其实不用装额外插件，它自带的 Git 集成就能连 GitLab。在 Settings -> Version Control -> Git 里配好 Git 可执行文件路径，然后 Settings -> Version Control -> GitHub 那里虽然叫 GitHub，但你可以通过 Add account -> GitLab 的方式添加。填入 GitLab URL 和 Access Token，IDEA 会自动识别项目并展示 MR、提交历史、分支信息。实际体验下来，IDEA 的 GitLab 集成比 VSCode 插件流畅一点，特别是做代码审查时要看行内评论，IDEA 的展示形式更直观。

6. 用 CI/CD 把代码变成产物

6.1 认识 .gitlab-ci.yml

GitLab CI/CD 的核心就是 .gitlab-ci.yml，放在仓库根目录下。它会定义整个流水线的阶段：比如 test -> build -> deploy。每次 push 代码后，GitLab Runner 会拉取代码，按照配置文件一步步执行任务。

我最早的流水线很简单，拿 Python 项目为例：

stages: - test - build before_script: - python --version test: stage: test script: - pip install -r requirements.txt - pytest tests/ build: stage: build script: - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA . only: - main

这段配置里有几个隐藏点值得注意。

第一，pip install -r requirements.txt如果在 CI Runner 上执行，会去公共 PyPI 下载依赖。很多内网环境的 Runner 没有外网权限，这时需要在 PyPI 源里配置公司内部镜像，或者把依赖打包上传到私有仓库。热搜词"gitlab cicd python 依赖 仓库地址"说的就是这个场景。解决办法是配置 pip 的 index-url 指向内网源，例如：

pip install -r requirements.txt -i http://您的内网pypi源/simple --trusted-host 您的内网pypi源

如果你用的是企业内部的私有依赖，还需要把仓库地址配置为 GitLab 的包仓库，把依赖发布到 GitLab Package Registry 里，并在 pip.conf 里配置 extra-index-url。这个流程比较细，我这里先提一下思路，后面会展开讲 GitLab Package 的使用。

第二，GitLab Runner 执行 Job 时，默认的工作目录是 CI_PROJECT_DIR，也就是克隆下来的仓库目录。很多人想在 Job 里执行cd /some/other/path再跑脚本，发现找不到文件，那是因为工作目录就不是你 push 的项目目录。建议尽量在项目根目录下组织脚本，不要跨目录操作。

第三，only 和 rules 的区别。only 是历史遗留写法，只认分支名或标签名，无法精确控制变量条件；rules 是推荐的新语法，可以同时匹配分支、变量、MR 状态等。写新流水线时直接用 rules。

6.2 注册 GitLab Runner

要让 CI/CD 跑起来，光有配置文件不够，还得有一个 Runner 来执行任务。Runner 可以装在独立服务器、Kubernetes Pod、甚至你本地电脑的 Docker 容器里。

注册命令一般是：

gitlab-runner register \ --non-interactive \ --url http://gitlab.example.com/ \ --registration-token YOUR_REGISTRATION_TOKEN \ --description "my-first-runner" \ --executor "docker" \ --docker-image python:3.11 \ --docker-volumes /var/run/docker.sock:/var/run/docker.sock

Registration Token 在哪里找？项目页面 Settings -> CI/CD -> Runners，里面会有 Specific runners 的注册链接和 token。用的是新版却一直提示 token 失效？检查一下 GitLab 版本，15.x 之后推荐用 project-level 的 Runner 注册 token，过期或权限不足时旧 token 就失效，那就去 Runners 设置里重新生成。

如果使用 Docker executor，每个 Job 都会拉一个隔离的 Docker 容器来执行命令。看起来方便，但也意味着每次构建都要还原依赖、装测试库，时间比较长。想优化的话，可以在tags里给 Runner 打标签，然后 Job 里指定 tags 跑在某一台做了缓存的高配机器上。

6.3 在 CI 中处理 Python 依赖缓存

内网环境最大的痛点就是依赖下载慢、甚至下不了。我总结了一套可行的组合方案：

• 基础镜像选择带 Python 和 pip 的版本，比如 python:3.11-slim。
• Runner 的 Docker 配置中配置国内或内网 PyPI 镜像地址作为全局 pip 源，避免每个 Job 都写一遍-i参数。
• 使用 GitLab Cache 缓存 pip 下载目录：

cache: paths: - .pip-cache/ test: stage: test script: - pip install --cache-dir .pip-cache -r requirements.txt

这样第二次跑流水线时，依赖可以直接走缓存，时间能缩短很多。我实际经验是同样一个 Django 项目，第一次流水线 8 分钟，加了缓存之后第二次能压到 3 分半，收益很明显。

如果你的项目里还有内部包，比如一个团体内多个服务共用一套工具库，那建议把工具库发到 GitLab Package Registry。在项目里配置：

[global] extra-index-url = http://gitlab.example.com/api/v4/projects/项目ID/packages/pypi/simple trusted-host = gitlab.example.com

然后 pip install 就能直接从 GitLab 拉取私有包了。这个方式非常适合企业内部项目，既不走公共网络，又能统一依赖版本。

7. 常见问题与排查技巧实录

把这些年真真切切遇到并解决的问题整理成一个速查表，方便在遭遇报错时快速定位。

7.1 Ubuntu 部署 GitLab 的简化版指引

如果你不想用 Docker，想直接在 Ubuntu 上部署，官方推荐方式也很清晰。先装依赖，再添加仓库、安装 gitlab-ce：

sudo apt update sudo apt install -y curl openssh-server ca-certificates postfix curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash sudo EXTERNAL_URL="http://gitlab.example.com" apt install gitlab-ce

装完执行sudo gitlab-ctl status查看各服务状态，sudo gitlab-ctl reconfigure在改完配置文件后需要执行一次让配置生效。这种方式比 Docker 更贴近系统原生，但备份和迁移麻烦一些。我个人的选择是 Docker，省心。

7.2 git 账号和 GitLab 账号不一致

热搜词里有一条"git账号和gitlab账号不一致，无法统计推送代码量"，这个其实是个很容易绕晕的坑。GitLab 统计贡献者时，是通过提交记录里的 author name 和 email 来对应到账号的。如果你的全局 Git 配置是一套，而 GitLab 账号里绑定的邮箱是另一套，那么你的提交就不会算到这个账号头上。

处理方式很简单，检查并修改提交者信息：

git config --global user.name "你的昵称" git config --global user.email "你的GitLab账号邮箱"

然后重置历史中的作者信息，不过这会重写历史，操作要谨慎。正确做法是从一开始就统一邮箱。如果历史已经乱了，可以用 git filter-repo 批量修改，但要确保参与协作的同事都 pull 最新的历史，不然会冲突。很多团队里"为什么我提交了很多代码、但代码统计榜上没有我"的问题，十有八九都是这个原因。

7.3 默认端口引发的访问混淆

GitLab 默认端口其实不是 79。gitlab.example.com 走 HTTP 时默认是 80，图省事可以直接用 IP + 80 访问；HTTPS 是 443。有人会把 GitLab 放到 79 端口，实际上是因为内网端口规划冲突。无论用哪个端口，external_url 都要带上端口。比如http://192.168.1.10:79，那访问地址就是http://192.168.1.10:79，CI CD 里的 URL 配置也必须是这个带上端口的地址。整体思路就是让 GitLab 知道自己被访问的合法地址，它生成 link、API 文档、Webhook 地址时才会正确。

7.4 与 Jenkins 同主机 Docker 部署的注意事项

GitLab 和 Jenkins 能跑在同一台宿主机的 Docker 里吗？能，但两个容器都用 8080 端口就会冲突。GitLab 默认不走 8080，Jenkins 默认走 8080，所以常见做法是把 Jenkins 的宿主映射端口改为 8081，或者把 GitLab 的端口改掉。同时注意 Docker 网络问题：两个容器最好放在同一个 docker network 内，让 GitLab 通过 http://gitlab:8080 或 http://gitlab 访问 Jenkins 的 Webhook，而 Jenkins 访问 GitLab 则用外网地址。我也踩过一个坑：Jenkins 容器里跑 Maven 构建、需要连接 GitLab 拉取代码，但容器内解析 gitlab.example.com 解析到了宿主机 IP，导致网络不通。解决办法是 compose 文件里加 extra_hosts，直接把 gitlab.example.com 指向宿主机 IP。

7.5 高危漏洞的快速收敛

前面提到了修复思路，这里再给一套可执行的操作清单：

1. 确认当前版本：右下角 Help 页面能看到完整版本号，也可以访问http://gitlab.example.com/api/v4/version，需要带 token。
2. 对照官方安全公告和 CVE 库确认影响范围。
3. 升级 GitLab 到包含修复的版本，Docker 部署的可以先拉新镜像，再用新镜像启动容器观察日志是否正常。
4. 开启自保护：管理后台收紧注册权限、关闭公开项目、配置 IP 白名单。
5. 定期备份：Docker 方式下可以用docker exec -t gitlab gitlab-backup create把配置文件和数据目录一起打包到异地。

说实话，GitLab 漏洞修复没有捷径，最快的办法就是版本跟上游保持同步。欠版本债越久，后面补课越痛苦，这是所有自托管软件逃不掉的规律。

8. 一些更进阶的玩法

8.1 通过 API 自动化管理项目

GitLab 的 API 设计得相当完整，日常运维完全可以脚本化。比如批量创建项目：

curl --request POST \ --header "PRIVATE-TOKEN: 你的PersonalAccessToken" \ --data "name=my-new-project&visibility=private" \ http://gitlab.example.com/api/v4/projects

获取 OAuth Token 还有一套标准流程，主要给第三方应用用。反复提示 Token 失效时，检查下是不是 OAuth Application 的回调地址没配对。如果你的服务要长期调用 API，更推荐用 Service Account 或项目级 Access Token，而不是拿个人的 token，这样离职、调岗时权限回收也干净。

8.2 搭建 ARM 构件的构建流水线

"如何从 gitlab 下载 arm gnu"这类问题，本质上是在构建 ARM 相关的交叉编译工具链。GitLab Runner 可以注册成带标签的 ARM 机器，然后在 .gitlab-ci.yml 里：

build-arm: stage: build tags: - arm-runner script: - make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu-

这样流水线就会自动调度到那台 ARM 机器上编译。如果没有专门的 ARM Runner，也可以采用 Docker + 模拟器方案，不过速度会慢很多，实际体验不佳。最稳妥的还是让 IT 部门拨一台 ARM 开发板或者 ARM 服务器专门当 Runner，编译效率和稳定性都提升一个档次。

8.3 SourceTree 连接 GitLab

Windows 上用 SourceTree 连接局域网 GitLab 的场景也挺常见。SourceTree 本身支持 SSH key，只需要在 Tools -> Options -> SSH 里把 SSH Client Configuration 的密钥路径指向本机生成的 id_ed25519，第一次拉取时让它加载即可。如果连接的是 2222 端口，同样需要额外指定选项，在克隆对话框里填入完整 SSH URL：ssh://git@192.168.1.10:2222/group/project.git，SourceTree 会自己识别。

9. 我对 GitLab 的整体体会

用 GitLab 这几年，最大的感受是它跟 GitHub 的"免费开放"气质不同，GitLab 更偏"企业的私有化基建"。不管是部署、权限、CI/CD，还是 API、Wiki、Issue 追踪、Package Registry，它几乎把 DevSecOps 链条上的每一环都占了。对个人开发者来说，就算只有一台 8G 内存的服务器，也完全能把它变成一个全功能的研发中台。

我也理解为什么很多人在第一次使用时会觉得它"笨重"——组件多、配置项多、新手不友好。但一旦你理解了它背后的设计逻辑，比如 SSH 就是为了免密推送、CI/CD 配置文件就是为了把构建流程固化在仓库里、Token 就是为了安全地让工具接入 API，整个 GitLab 就变得非常顺手。

如果你现在正准备从 GitHub 切回 GitLab 自托管，或者公司正计划在内网自建代码平台，我的建议是：先别一上来就堆最强的 Runner、最好的机器，先用 Docker 在自己的笔记本或一台低配服务器上把基本流程跑通，注册一两个项目，走一遍"创建项目-拉代码-改代码-推送-触发流水线"的完整链路，然后再慢慢叠加权限、加固、监控这些高级能力。这样即使踩坑也能快速定位问题，不至于在一开始就陷入组件太多、无从下手的状况。

最后分享一个小习惯：我每天下班前都会随手看一眼 GitLab 的流水线状态和 Merge Request 列表，发现有挂掉的流水线就直接在手机上查看日志、重新触发。这个习惯让我能第一时间发现代码问题，避免第二天到公司才被同事提醒"昨天流水线挂了"。这个小操作对团队协作的帮助，比想象中大得多。