二进制部署Gitea最轻量可控，Docker需显式挂载/data和/etc/gitea并以git用户运行；/var/lib/gitea权限750、app.ini权限640；ROOT_URL不一致导致URL生成错误；SQLite仅适用于低频单机场景。
直接用二进制方式部署 Gitea 是最轻量、最可控的选择，尤其适合 1GB 内存的 VPS 或内网服务器；Docker 方式虽然快，但默认 SQLite 配置容易在重启后丢数据，且日志和路径管理不透明。
为什么不用 Docker run -p 3000:3000 gitea/gitea 直接跑
Docker 默认使用 sqlite 存储，容器一删，数据库文件就没了；docker run 启动时没挂载 /data 和 /etc/gitea，配置无法持久；官方镜像默认以 root 用户运行，违反最小权限原则，审计或安全扫描会直接告警。真要 Docker，必须显式挂载：
docker run -d -p 3000:3000 -v /opt/gitea:/data -v /opt/gitea/conf:/etc/gitea -u git gitea/gitea- 还得提前创建
git用户和目录权限：useradd -r -s /bin/bash -m git，再chown -R git:git /opt/gitea
用二进制部署时，/var/lib/gitea 和 /etc/gitea 权限怎么设才安全
核心原则：Gitea 进程只应有它需要的最小读写权限，不能让 web 进程写配置，也不能让配置文件被普通用户读取。常见错误是全设成 777 或让 root 持有 /var/lib/gitea/data。
-
/var/lib/gitea所有者设为git:git，权限750（chmod 750 /var/lib/gitea） -
/etc/gitea/app.ini所有者root:git，权限640（chmod 640 /etc/gitea/app.ini），确保 Gitea 能读、但不能改 -
/var/lib/gitea/log必须可写，否则gitea web启动失败并静默退出，错误不会打到终端
GITEA_WORK_DIR 和 app.ini 中的 ROOT_URL 不一致会导致什么
典型表现：网页能打开，但头像不显示、仓库克隆地址错成 http://localhost:3000、邮件通知里的链接点不开。根本原因是 Gitea 生成 URL 时优先读 ROOT_URL，而 GITEA_WORK_DIR 只影响运行时文件查找路径。
-
ROOT_URL必须带协议、域名（或 IP）、端口，例如http://git.example.com:3000/或https://git.internal/ - 如果用反向代理（Nginx），
ROOT_URL应与代理暴露的地址一致，且需在 Nginx 配置里加proxy_set_header X-Forwarded-Proto https;等头 -
GITEA_WORK_DIR=/var/lib/gitea只用于定位custom/、data/、log/，和 URL 无关
SQLite 能不能用于生产环境
可以，但仅限单机、低频写入、无人值守场景。Gitea 官方文档明确标注 SQLite “not recommended for production”，因为：
- 并发写入性能差：多个用户同时 push/pull/issue 提交，容易触发
database is locked错误 - 备份困难：SQLite 是单文件，但 Gitea 的
data/目录还包含附件、LFS 对象，必须整体拷贝，且拷贝时不能有写入 - 无用户级权限控制：MySQL/MariaDB 可为每个 Gitea 实例分配独立账号，SQLite 文件一旦泄露，全部数据裸奔
哪怕只是个人项目，也建议花 5 分钟配个 MariaDB：建库、授权、改 app.ini 三步完事，后续扩展权限或迁移都省心。
