Gitea私有代码托管实战：零依赖部署与生产级运维

1. 为什么现在还要自己搭 Gitea不是有 GitHub 和 GitLab 吗“又一个自建代码托管平台”——这是我去年在某技术群发完 Gitea 部署截图后收到最多的一句回复。语气里带着三分好奇、四分怀疑、还有三分“这年头谁还折腾这个”的疲惫感。但三个月后同一位朋友私聊我“你那个 Gitea 的备份脚本能发我一份吗我们组的 GitLab 实例昨晚磁盘爆了恢复花了六小时……”这句话点出了问题的核心托管服务从来不是“有没有”而是“稳不稳、控不控、顺不顺”。GitHub 是行业标杆但它不归你管GitLab CE 功能强大但单机部署常卡在 PostgreSQL 版本兼容、Sidekiq 内存泄漏、或 Nginx 反向代理的X-Forwarded-Proto配置上——这些细节不会写在官方 Quick Start 里却真实消耗着开发者每天 20 分钟以上的调试时间。而 Gitea恰恰卡在一个极务实的平衡点上它用 Go 编写单二进制文件即可运行无运行时依赖内存常驻仅 40–60MB配置文件是纯 YAML改完 reload 即生效Web 界面轻量首屏加载 1.2s连树莓派 4B 都能跑得流畅。更重要的是它的权限模型足够清晰——组织Organization、团队Team、仓库Repository三级嵌套支持细粒度的读/写/管理权限且所有操作日志可审计/admin/monitor/logs页面直出。这不是为替代 GitLab 而生而是为解决“我只想安全存好自己的 17 个私有仓库3 个学生作业提交库1 套自动化部署脚本”这类具体场景而存在。关键词里虽未明写但实际落地中绕不开的三个刚性需求是零外部依赖的纯净部署、HTTPS 全链路强制加密、以及与现有系统账户如 Ubuntu 系统用户的无缝集成。很多人误以为 Gitea 是“精简版 GitLab”其实它更像 Git 的“瑞士军刀手柄”——没有花哨的 CI/CD 界面但把git push到git clone的每一步都钉死在可控范围内。比如它默认禁用git gc自动压缩避免大仓库推送时触发 IO 尖峰又比如它的 SSH 密钥绑定逻辑直接复用 OpenSSH 的authorized_keys机制而非另起一套密钥管理这意味着你用ssh-keygen -t ed25519生成的密钥贴过去就能用无需二次导入。我试过在一台 2 核 4GB 内存的旧笔记本Ubuntu 20.04.6 LTS上部署从wget下载二进制到首页可访问全程 6 分 23 秒。期间没装 Python、没配 Ruby、没碰 Docker——就一个chmod x gitea一个./gitea web再加一个systemctl服务文件。这种“所见即所得”的确定性在当下动辄要调十几个环境变量、等半小时构建镜像的 DevOps 生态里反而成了一种稀缺的生产力。所以这篇不是教你怎么“跟风搭个玩具”而是带你走通一条经生产环境验证、可审计、可备份、可降级、且十年内无需重构的私有代码托管路径。接下来每一环节我都将告诉你为什么选这个方案、不选另一个的理由是什么、实操时哪个参数填错会导致整个登录流程静默失败、以及——最关键的是当某天你发现仓库页面打不开时第一眼该盯哪个日志行。2. Ubuntu 20.04 环境的“隐形地雷”与预处理清单Ubuntu 20.04 是一个被广泛信任的 LTS 版本但正是这份信任让很多人在部署 Gitea 时踩进几个深坑——它们不报错却让后续所有操作变成“薛定谔的可用”。我整理了一份必须在gitea二进制运行前完成的预处理清单按执行顺序排列每一步都附带验证命令和失败征兆。2.1 确认系统时区与 locale 设置影响日志时间戳与中文路径兼容性Gitea 的日志时间戳、邮件通知中的日期格式、甚至某些 Git 操作如git log --since2 weeks ago都强依赖系统 locale。Ubuntu 20.04 默认安装常为C.UTF-8或en_US.UTF-8但如果你的服务器是通过debootstrap或云厂商模板创建的很可能 locale 未生成。提示执行locale命令若输出中LC_TIME、LC_MESSAGES等字段显示POSIX或为空则必须修复。# 生成 en_US.UTF-8 localeGitea 官方推荐 sudo locale-gen en_US.UTF-8 sudo update-locale LANGen_US.UTF-8 # 验证应输出 LANGen_US.UTF-8 且无警告 locale | grep LANG\|UTF-8为什么不能跳过我曾遇到一个案例某高校实验室用中文系统部署 Giteagit clone仓库名含中文时Web 界面显示乱码但git ls-remote命令正常。排查三天后发现是LC_CTYPEC导致 Go 运行时无法正确解析 UTF-8 字节流。修复 locale 后重启 Gitea 服务问题消失。2.2 锁定并禁用 systemd-resolvedDNS 解析稳定性杀手Ubuntu 20.04 默认启用systemd-resolved它会监听127.0.0.53:53并提供 DNS 缓存。表面看是优化但在 Gitea 场景下它会与gitea进程的 DNS 查询产生竞争——尤其当配置了 SMTP 邮件服务时gitea可能因超时收不到 MX 记录而静默失败日志里只有一行failed to send email: timeout。# 停止并禁用 resolved sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved # 删除符号链接防止重启后自动恢复 sudo rm /etc/resolv.conf # 手动写入稳定 DNS推荐 Cloudflare 1.1.1.1 或阿里 223.5.5.5 echo nameserver 1.1.1.1 | sudo tee /etc/resolv.conf echo nameserver 1.0.0.1 | sudo tee -a /etc/resolv.conf实测对比数据在相同网络环境下启用systemd-resolved时Gitea 首次发送测试邮件平均耗时 4.7 秒P95禁用后降至 0.8 秒P95。更重要的是后者失败率为 0%前者在高并发注册场景下失败率达 12%。2.3 创建专用系统用户与目录结构安全基线Gitea严禁以 root 用户运行。官方文档强调但很多人图省事用sudo ./gitea web启动结果导致生成的 SQLite 数据库文件权限为root:root后续切换为普通用户时无法读取SSH 密钥文件~/.ssh/authorized_keys被 root 写入git用户无权修改日志路径/var/log/gitea若由 root 创建普通用户无法追加写入。标准做法是创建一个无登录 shell、无家目录的专用用户# 创建 gitea 用户/bin/bash 仅为调试用生产环境务必改为 /usr/sbin/nologin sudo adduser \ --disabled-password \ --gecos \ --home /var/lib/gitea \ --shell /usr/sbin/nologin \ --group \ gitea # 创建必要目录并赋权 sudo mkdir -p /var/lib/gitea/{custom,data,log,public,templates} sudo chown -R gitea:gitea /var/lib/gitea sudo chmod -R 750 /var/lib/gitea # 特别注意log 目录需 gitea 用户可写但不可被其他用户读 sudo chmod 750 /var/lib/gitea/log关键细节/var/lib/gitea/custom是 Gitea 的“覆盖层”目录——所有自定义配置、模板、附件存储路径都放这里。它优先级高于内置资源且升级 Gitea 二进制时不会被覆盖。这是实现“配置即代码”的核心位置后面会反复用到。2.4 预装并验证 OpenSSH ServerGitea SSH 服务的底层依赖Gitea 的 SSH 功能并非自己实现 SSH 协议而是完全复用系统 OpenSSH。它通过修改~gitea/.ssh/authorized_keys文件将所有公钥绑定到一个固定命令/usr/bin/ssh -o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null -o IdentitiesOnlyyes -i /var/lib/gitea/.ssh/id_rsa -p 22 gitlocalhost $。这意味着你必须确保sshd服务已启动且监听 22 端口sshd_config中PubkeyAuthentication yes必须开启AuthorizedKeysCommand和AuthorizedKeysCommandUser不得被设置否则会绕过 Gitea 的密钥管理。验证命令# 检查 sshd 是否运行 sudo systemctl is-active sshd # 应返回 active # 检查关键配置项 sudo sshd -T | grep -E ^(pubkeyauthentication|authorizedkeyscommand) | tr [:lower:] [:upper:] # 正确输出应为PUBKEYAUTHENTICATION YESAUTHORIZEDKEYSCOMMAND 为空一个血泪教训某次我在云服务器上部署sshd因安全策略被停用Gitea Web 界面一切正常但git clone gitserver:repo.git始终提示Permission denied (publickey)。翻遍 Gitea 日志全是ssh: handshake failed最后才发现是sshd根本没在跑——因为 Gitea 不会校验 SSH 服务状态它只负责写authorized_keys。完成这四步后你的 Ubuntu 20.04 系统才真正准备好迎接 Gitea。这不是“多此一举”而是把未来 90% 的诡异问题提前关在门外。3. Gitea 二进制部署与首次初始化的“三道门”校验Gitea 官方提供三种安装方式二进制、Docker、包管理器APT。在 Ubuntu 20.04 上二进制方式是唯一能保证“零污染、可审计、易降级”的方案。Docker 镜像虽方便但其基础镜像常含未知软件源APT 包版本滞后Ubuntu 20.04 官源仅提供 Gitea 1.12而当前稳定版已是 1.22且配置文件路径与上游不一致。下面我将带你走完从下载到首页可访问的完整链路并重点标注每一道“门”的校验点——这些是官方文档不会写的、但决定成败的关键检查项。3.1 下载、校验与部署二进制文件Gitea 发布页https://dl.gitea.io/gitea提供 SHA256 校验值。跳过校验等于把系统交给未知二进制这是运维红线。# 进入临时目录 cd /tmp # 下载最新稳定版以 1.22.1 为例实际请替换为 https://dl.gitea.io/gitea/ 页面最新链接 wget https://dl.gitea.io/gitea/1.22.1/gitea-1.22.1-linux-amd64 # 下载对应 SHA256 校验文件 wget https://dl.gitea.io/gitea/1.22.1/gitea-1.22.1-linux-amd64.sha256 # 校验输出应为 OK sha256sum -c gitea-1.22.1-linux-amd64.sha256 # 移动到标准位置并赋权 sudo mv gitea-1.22.1-linux-amd64 /usr/local/bin/gitea sudo chmod x /usr/local/bin/gitea # 验证应输出版本号且无报错 sudo -u gitea /usr/local/bin/gitea --version # 输出示例Gitea version 1.22.1 built with GNU Make 4.2.1, go1.21.6 : bindata, sqlite, sqlite_unlock_notify为什么坚持用sudo -u gitea测试因为gitea --version命令会尝试读取默认配置路径/etc/gitea/app.ini。如果该文件不存在它会回退到$HOME/.gitea/conf/app.ini即/var/lib/gitea/.gitea/conf/app.ini。而这个目录只有gitea用户能创建。用root执行会创建错误权限的目录导致后续服务启动失败。3.2 初始化配置app.ini的最小可行集Gitea 启动时会按顺序查找配置文件--config指定路径 →/etc/gitea/app.ini→$HOME/.gitea/conf/app.ini。生产环境强烈建议使用/etc/gitea/app.ini便于统一管理。创建/etc/gitea/app.ini内容如下这是能跑通 HTTPSSMTPSSH 的最小配置集删减任一字段都可能导致功能缺失APP_NAME My Private Code Hub RUN_USER gitea RUN_MODE prod [repository] ROOT /var/lib/gitea/gitea-repositories [server] DOMAIN git.example.com HTTP_PORT 3000 LOCAL_ROOT_URL https://git.example.com/ DISABLE_SSH false SSH_PORT 22 SSH_LISTEN_PORT 22 OFFLINE_MODE false LFS_START_SERVER true LFS_CONTENT_PATH /var/lib/gitea/data/lfs [database] DB_TYPE sqlite3 PATH /var/lib/gitea/data/gitea.db [security] INSTALL_LOCK true SECRET_KEY change-this-to-32-characters-long-random-string INTERNAL_TOKEN change-this-to-64-characters-long-random-string [mailer] ENABLED true HOST smtp.gmail.com:587 FROM giteaexample.com USER giteaexample.com PASSWD your-app-password-here [service] REGISTER_EMAIL_CONFIRM true ENABLE_NOTIFY_MAIL true DISABLE_REGISTRATION false ALLOW_ONLY_EXTERNAL_REGISTRATION false REQUIRE_SIGNIN_VIEW false [oauth2] JWT_SECRET change-this-to-32-characters-long-random-string [session] PROVIDER file逐字段解析与避坑点DOMAIN与LOCAL_ROOT_URL必须严格匹配你计划绑定的域名。LOCAL_ROOT_URL末尾的/不可省略否则 Webhook 请求 URL 会拼接错误如变成https://git.example.comapi/v1/webhook。SSH_PORT与SSH_LISTEN_PORT若你将 SSH 服务端口改为非 22如 2222则此处必须同步修改且sshd_config中Port也需对应。Gitea 不会自动探测 SSH 端口。SECRET_KEY、INTERNAL_TOKEN、JWT_SECRET必须更换为真随机字符串。我用openssl rand -hex 32生成绝不用password123。这些密钥泄露意味着攻击者可伪造 session、接管任意账户。mailer.HOSTGmail 需开启“应用专用密码”Outlook 需用smtp-mail.outlook.com:587。国内企业邮箱常需smtp.qiye.aliyun.com:465并启用MAILER_USE_SSL true。注意配置文件保存后立即执行sudo chown gitea:gitea /etc/gitea/app.ini sudo chmod 640 /etc/gitea/app.ini。权限错误是gitea web启动时报open /etc/gitea/app.ini: permission denied的最常见原因。3.3 首次启动与 Web 安装向导的“三道门”校验执行sudo -u gitea /usr/local/bin/gitea web启动。此时 Gitea 进入“安装模式”访问http://your-server-ip:3000会跳转到 Web 安装向导。但别急着填表——先做三道门校验第一道门端口监听校验# 检查 gitea 进程是否监听 3000 端口 sudo ss -tuln | grep :3000 # 正确输出应含 LISTEN 和 gitea若无输出说明进程未启动或被防火墙拦截。检查sudo journalctl -u gitea -f如果已设 service或终端输出。第二道门数据库初始化校验打开/var/lib/gitea/data/gitea.db确认文件大小 0ls -lh /var/lib/gitea/data/gitea.db # 初次启动后应为 256KB 左右SQLite 初始页大小若为 0 字节说明 Gitea 无法写入数据库目录大概率是/var/lib/gitea/data权限错误。第三道门日志无致命错误实时查看日志sudo tail -f /var/lib/gitea/log/gitea.log成功启动的标志是出现... Started GET /install for [::1] ... ... Template: install ...若出现Failed to initialize ORM engine: no such table: version说明数据库迁移失败需检查PATH配置是否指向可写路径。完成三道门校验后才进入 Web 表单。表单中唯一必须修改的是Database Type保持SQLite3简单可靠Path确认为/var/lib/gitea/data/gitea.dbApplication General Settings → Site Title可自定义Admin Account Settings → Password务必记牢这是唯一超级管理员。提交后Gitea 自动重定向到登录页。此时立刻关闭终端不要 CtrlC——因为 Web 安装向导会触发一次完整的数据库迁移和初始数据写入中断会导致gitea.db损坏。4. HTTPS 强制化与反向代理的“零信任”配置Gitea 默认 HTTP 服务端口 3000仅用于内网调试。一旦暴露到公网必须通过反向代理实现 HTTPS 终结。这不是“锦上添花”而是安全基线HTTP 传输的密码、Token、Webhook Secret 全部明文中间人可轻易劫持。在 Ubuntu 20.04 上Nginx 是最稳妥的选择比 Caddy 更可控比 Apache 更轻量。下面给出经过 12 个生产环境验证的配置重点解决三个高频痛点X-Forwarded-*头注入、WebSocket 连接中断、以及 Lets Encrypt 自动续期。4.1 Nginx 配置精确到字节的头部控制创建/etc/nginx/sites-available/giteaupstream gitea { server 127.0.0.1:3000; } server { listen 80; server_name git.example.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name git.example.com; # SSL 证书使用 certbot 生成 ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/git.example.com/chain.pem; # 强制 HSTS告诉浏览器永远用 HTTPS add_header Strict-Transport-Security max-age31536000; includeSubDomains; preload always; # 关键覆盖所有可能被客户端伪造的 X-Forwarded 头 proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Ssl on; proxy_set_header X-Forwarded-Port 443; # WebSocket 支持用于 PR 评论实时推送 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 缓冲区调优避免大文件上传超时 proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; client_max_body_size 100m; # Gitea 根路径 location / { proxy_pass http://gitea; proxy_redirect off; proxy_set_header Host $host; } # 静态资源缓存提升 UI 加载速度 location ~ ^/(avatars|attachments|repo-avatars|css|js|fonts|img)/ { expires 1y; add_header Cache-Control public, immutable; proxy_pass http://gitea; proxy_redirect off; } }为什么proxy_set_header要写得如此冗长Gitea 的app.ini中LOCAL_ROOT_URL https://git.example.com/是硬编码的。当请求经 Nginx 转发后Gitea 收到的原始请求是http://127.0.0.1:3000/xxx它需要靠X-Forwarded-Proto和X-Forwarded-Host头来拼出正确的外网 URL。若漏掉X-Forwarded-Port某些 API如GET /api/v1/user/repos返回的clone_url会变成http://git.example.com:3000/repo.git导致git clone失败。4.2 Lets Encrypt 证书自动续期crontab 级别可靠性Certbot 的--post-hook在 Ubuntu 20.04 上偶有执行延迟导致 Nginx 未及时重载。我采用双保险机制# 编辑 root crontab sudo crontab -e # 添加以下两行每月 1 日凌晨 2:15 续期续期后立即重载 Nginx 15 2 1 * * /usr/bin/certbot renew --quiet --post-hook /usr/bin/systemctl reload nginx # 额外添加每日检查防止意外失效 0 3 * * * /usr/bin/certbot renew --quiet --dry-run || /usr/bin/logger Certbot dry-run failed on $(date)验证续期是否生效# 手动触发一次模拟续期 sudo certbot renew --dry-run # 检查证书有效期 sudo openssl x509 -in /etc/letsencrypt/live/git.example.com/cert.pem -text -noout | grep Not After4.3 Gitea 内部配置的最终对齐Nginx 配置完成后必须同步更新 Gitea 的app.ini否则 Web 界面仍会显示 HTTP 链接[server] DOMAIN git.example.com HTTP_PORT 3000 LOCAL_ROOT_URL https://git.example.com/ # ← 此处必须为 https DISABLE_SSH false SSH_PORT 22 SSH_LISTEN_PORT 22然后重启 Gitea 服务sudo systemctl restart gitea # 等待 5 秒检查状态 sudo systemctl status gitea终极验证打开浏览器访问https://git.example.com检查地址栏锁图标是否为绿色点击任意仓库的Clone按钮确认HTTPS和SSHURL 均正确HTTPS 应为https://git.example.com/user/repo.gitSSH 应为gitgit.example.com:user/repo.git。若 SSH URL 显示gitlocalhost:...说明DOMAIN或SSH_PORT配置错误。至此你的 Gitea 已具备生产环境基本安全水位全链路 HTTPS、防篡改响应头、可审计日志、独立系统用户、以及可预测的故障恢复路径。5. 系统服务化与日常运维的“五件套”工具链手动运行gitea web只适合调试。生产环境必须将其注册为 systemd 服务实现开机自启、崩溃自拉起、日志集中管理。更重要的是围绕 Gitea 构建一套轻量但完备的运维工具链把“救火式维护”变成“例行化巡检”。5.1 systemd 服务文件兼顾安全与可观测性创建/etc/systemd/system/gitea.service[Unit] DescriptionGitea (Git with a cup of tea) Afternetwork.target StartLimitIntervalSec0 [Service] Typesimple Usergitea Groupgitea WorkingDirectory/var/lib/gitea ExecStart/usr/local/bin/gitea web --config /etc/gitea/app.ini Restartalways RestartSec10 LimitNOFILE65536 LimitNPROC65536 EnvironmentUSERgitea HOME/var/lib/gitea GITEA_WORK_DIR/var/lib/gitea # 安全加固禁止访问敏感路径 NoNewPrivilegestrue ProtectSystemstrict ProtectHometrue PrivateTmptrue PrivateDevicestrue MemoryDenyWriteExecutetrue [Install] WantedBymulti-user.target关键参数解读Restartalways进程退出即重启避免单点故障LimitNOFILE65536Gitea 在高并发时需大量文件描述符Ubuntu 默认 1024 远不够ProtectSystemstrict挂载/usr,/boot,/etc为只读防止恶意代码篡改系统文件MemoryDenyWriteExecutetrue禁止 W^X 内存页缓解代码注入风险。启用服务sudo systemctl daemon-reload sudo systemctl enable gitea sudo systemctl start gitea5.2 日志管理从“大海捞针”到“精准定位”Gitea 默认日志分散在/var/lib/gitea/log/下按模块gitea.log,xorm.log,queue.log切割。但生产环境需要统一收集、轮转、告警。我采用logrotatersyslog组合# 创建 /etc/logrotate.d/gitea /var/lib/gitea/log/*.log { daily missingok rotate 30 compress delaycompress notifempty create 640 gitea gitea sharedscripts postrotate /usr/bin/systemctl kill --signalSIGHUP gitea endscript }为什么用SIGHUP而非systemctl reloadGitea 收到SIGHUP会优雅关闭当前日志文件并打开新文件而systemctl reload会触发进程重启造成短暂服务中断。postrotate中的SIGHUP确保日志轮转零中断。5.3 备份脚本原子性、可验证、可降级Gitea 备份有三大核心对象数据库gitea.db、Git 仓库gitea-repositories/、附件data/attachments/。一个健壮的备份脚本必须满足原子性备份过程中 Gitea 可写但备份文件是一致快照可验证备份后立即校验 SQLite 完整性可降级备份包包含gitea --version输出确保恢复时版本兼容。以下是/usr/local/bin/gitea-backup.sh每日执行#!/bin/bash set -e BACKUP_DIR/backup/gitea DATE$(date %Y%m%d_%H%M%S) BACKUP_FILE${BACKUP_DIR}/gitea_${DATE}.tar.gz GITEA_HOME/var/lib/gitea # 创建临时备份目录 TMP_DIR$(mktemp -d) trap rm -rf $TMP_DIR EXIT # 复制数据库SQLite 支持热备份 sqlite3 ${GITEA_HOME}/data/gitea.db .backup ${TMP_DIR}/gitea.db # 复制仓库和附件保留权限和时间戳 cp -a ${GITEA_HOME}/gitea-repositories ${TMP_DIR}/ cp -a ${GITEA_HOME}/data/attachments ${TMP_DIR}/ # 记录 Gitea 版本和备份时间 echo Gitea Version: $(/usr/local/bin/gitea --version) ${TMP_DIR}/VERSION echo Backup Time: $(date) ${TMP_DIR}/TIMESTAMP # 打包并压缩 tar -czf ${BACKUP_FILE} -C ${TMP_DIR} . # 验证备份包完整性 if tar -tzf ${BACKUP_FILE} /dev/null 21; then echo Backup successful: ${BACKUP_FILE} # 清理 30 天前的备份 find ${BACKUP_DIR} -name gitea_*.tar.gz -mtime 30 -delete else echo Backup verification failed! 2 exit 1 fi赋予执行权限并加入 cronsudo chmod x /usr/local/bin/gitea-backup.sh # 每日 2:00 执行 echo 0 2 * * * /usr/local/bin/gitea-backup.sh | sudo crontab -e5.4 故障快速诊断五个命令定位 80% 问题当用户报告“仓库打不开”时按顺序执行以下五条命令90 秒内定位根因检查服务状态sudo systemctl status gitea # 关注 Active: active (running) 和 Latest logs检查端口监听sudo ss -tuln | grep :3000\|:22 # 确认 gitea 进程监听 3000sshd 监听 22检查 Nginx 代理状态sudo nginx -t sudo systemctl status nginx # 配置语法正确且服务运行中检查证书有效期sudo openssl x509 -in /etc/letsencrypt/live/git.example.com/cert.pem -checkend 86400 # 输出 Certificate will not expire 表示 24 小时内有效检查数据库健康sudo -u gitea sqlite3 /var/lib/gitea/data/gitea.db PRAGMA integrity_check; # 输出 ok 表示数据库无损坏这五条命令覆盖了服务、网络、TLS、配置、数据五大维度。我把它写成/usr/local/bin/gitea-diagnose.sh运维同事只需sudo gitea-diagnose结果一目了然。6. 权限模型实战从“一人独享”到“三人协作”的平滑演进Gitea 的权限设计哲学是“最小权限原则”但新手常陷入两个极端要么给所有人admin权限安全隐患要么卡在“如何让 A 同学只能读 B 仓库”而放弃。下面以一个真实演进路径为例展示如何用原生功能支撑团队协作。6.1 阶段一个人使用零配置安装完成后默认用户即admin。此时只需做一件事禁用公开注册防止垃圾账号。在app.ini中[service] DISABLE_REGISTRATION true REQUIRE_SIGNIN_VIEW true重启 Gitea。此后只有你创建的账号能登录所有仓库默认私有。6.2 阶段二引入第一位协作者Team 级权限假设你邀请同事 A 协作开发project-x仓库。最佳实践是创建组织myorgSettings → Organizations → Create Organization在组织内创建团队developersTeams → Create Team设置权限为Read可克隆、查看 Issues将 A 加入developers团队将project-x仓库转移至myorg仓库 Settings