企业官网建设流程全解析

1. 为什么选择自建 Code Review 平台

代码审查这件事，但凡在团队里写过几年代码的人都有体会。用聊天工具发 diff 截图、靠口头说“你帮我看看这个分支”，短期凑合还行，人一多、分支一杂，立刻就乱套。提交记录和评审意见对不上号，谁审过、谁没审、哪条意见改了、哪条还挂着，全靠脑子记，最后必然出问题。

市面上托管式的代码托管服务确实省事，但有些团队出于数据留存、内网隔离、成本控制或者纯粹想自己掌控全流程的考虑，更倾向于把评审系统放在自己的机器上。Phabricator 就是在这个需求下经常被提到的一个选择。它最早由 Facebook 开源，是一整套研发协作工具的集合，其中Differential这个组件专门负责代码审查，配合Arcanist命令行工具，能实现从提交 diff、分配评审人、逐行评论到最终合入的完整闭环。

这个项目标题里说的“三行命令搞定搭建”，指的是用 Docker 跑起 Phabricator 的官方镜像，把数据库、Web 服务、后台任务这些原本要折腾半天的依赖一次性拉起来。对不想在环境配置上耗时间的人来说，这条路确实够短。但“跑起来”和“能用好”是两码事，邮件提醒不配，评审请求发出去没人知道；基础配置不调，仓库接不进来、权限一团糟。所以这篇内容我会把三行命令背后的东西拆开讲清楚，再把邮件提醒和日常配置这两块补上，让整套系统真正能落地干活。

适合读这篇的人大概分三类：一是中小团队里负责搭内部工具的那位；二是想在自己机器上跑一套完整评审流程练手的开发者；三是对 Phabricator 这套老牌工具好奇、想看看它到底怎么运转的技术负责人。不管你是哪一类，只要跟着把命令敲一遍、把配置对着改一遍，基本都能得到一套可用的评审环境。

提示：Phabricator 官方已经停止新功能开发，进入维护状态。这不影响它在内网环境里继续稳定使用，但如果你追求长期演进，心里要有数。本文聚焦的是“如何把它稳稳跑起来并用顺手”，不涉及后续版本升级路线。

2. 三行命令背后的容器编排逻辑

2.1 官方镜像的组成与依赖关系

很多人看到“三行命令”以为是三个孤立的 docker run，其实不是。Phabricator 要正常工作，至少需要三个角色：Web 前端（处理页面请求和 API）、MySQL 数据库（存所有元数据）、后台守护进程（跑邮件队列、仓库导入、定时任务）。官方维护的镜像把这些打包好了，但数据库通常建议单独起一个容器，方便数据持久化和备份。

所以那三行命令的典型形态是：先起一个 MySQL 容器并初始化库，再起 Phabricator 主容器并把它链接到数据库，最后进容器执行一次初始化脚本。命令本身不长，但每一行的参数都有讲究，下面逐个拆。

docker run -d --name phab-mysql \ -e MYSQL_ROOT_PASSWORD=your_root_pwd \ -e MYSQL_DATABASE=phabricator \ -v /data/phab/mysql:/var/lib/mysql \ mysql:5.7 --character-set-server=utf8mb4

这一行做三件事：后台运行、设置 root 密码和默认库名、把数据目录挂到宿主机。挂载卷这一步千万别省，否则容器一删，所有评审记录跟着没。字符集指定 utf8mb4 是为了支持完整的 Unicode，中文注释、特殊符号都不会乱码。

docker run -d --name phabricator \ --link phab-mysql:mysql \ -p 8080:80 -p 2222:22 \ -v /data/phab/repo:/repos \ -v /data/phab/files:/files \ phabricator/php:7.2-apache

第二行把主容器和数据库连起来，映射 Web 端口和 SSH 端口。2222 这个端口是给 Arcanist 推送代码用的，后面配仓库时会用到。/repos存 Git 仓库裸库，/files存上传的附件，同样要挂出来。

docker exec -it phabricator \ /app/bin/storage upgrade --force

第三行进容器执行数据库结构升级，把表建好。到这一步，浏览器打开http://你的机器IP:8080就能看到登录页了。

2.2 为什么用 link 而不是自定义网络

上面用了--link，这是老写法。新一点的 Docker 更推荐自定义 bridge 网络，容器之间用服务名互访，不依赖 link 的隐式环境变量注入。如果你用的是较新版本，可以改成：

docker network create phab-net docker run -d --name phab-mysql --network phab-net ... docker run -d --name phabricator --network phab-net ...

这样容器重启后 IP 变化也不影响连接，配置里数据库主机名直接写phab-mysql就行。我实测下来，自定义网络在容器频繁重启的场景下更稳，link 偶尔会因为启动顺序问题导致主容器连不上库，得手动重启一次。

2.3 端口与目录规划的经验

端口映射有两个坑。一是 8080 可能被别的服务占了，起之前先ss -tlnp | grep 8080看一眼。二是 SSH 端口如果宿主机本身开着 22，映射到 2222 是常规做法，但 Arcanist 配置里要显式写这个端口，否则它默认连 22 会失败。

目录规划上，我习惯把所有持久化数据放在一个统一根目录下，比如/data/phab/，下面分mysql、repo、files三个子目录。这样备份的时候一条tar打包整个目录就行，迁移也方便。别把数据散落在多个位置，时间一长自己都记不住哪个目录是干嘛的。

3. 初始化配置与管理员账号设置

3.1 首次登录与账号体系

容器跑起来后，第一个访问的人会被引导创建管理员账号。Phabricator 的账号体系默认是本地账号，用户名密码存在自己库里。创建完管理员后，建议立刻进Auth应用把注册策略收紧，默认是允许任何人注册，内网环境虽然风险低，但也没必要敞开。

进People → Auth → Registration，把注册方式改成“仅管理员邀请”或者直接关闭自助注册。团队成员账号由管理员在 People 里手动创建，或者接 LDAP、OAuth 这类外部认证。小团队手动建号最省事，人多了再考虑对接统一认证。

3.2 基础参数调整

登录后右上角进Config → Setup Issues，这里会列出所有没配好的项。刚装完通常有一堆黄色警告，不用慌，按优先级处理。最关键的几项：

• storage.local-disk.path：确认文件存储路径指向挂载出来的/files，否则附件重启就丢。
• phabricator.base-uri：设成你实际访问的地址，比如http://192.168.1.100:8080。这个值影响邮件里的链接和 API 回调，必须设对，否则邮件里的按钮点过去是错的。
• security.alternate-file-domain：如果只在内网用，可以先忽略；对外暴露的话建议配一个独立域名存附件，避免 XSS 风险。

改完这些，Setup Issues 里的红色项基本就清了。剩下的黄色项大多是可选优化，不影响核心功能。

3.3 时区与语言

Phabricator 默认英文界面，时区是 UTC。团队在国内用的话，进Config → Settings → Account把时区改成Asia/Shanghai，否则提交时间、评审时间全是错位的，看日志会很别扭。界面语言官方没有完整中文包，但核心菜单就那几个词，用两天就熟了，不建议折腾第三方汉化，容易在升级时出问题。

4. 邮件提醒配置全流程

4.1 邮件在评审流程里的作用

代码评审最怕的就是“提交了没人理”。Phabricator 的邮件提醒解决的就是这个问题：有人提交 diff、有人评论、有人要求修改、最终合入，每个节点都能触发邮件，相关人邮箱里直接收到带链接的通知，点进去就能操作。没有邮件提醒的评审系统，基本等于半瘫，因为没人会一直盯着网页刷新。

4.2 SMTP 参数配置

进Config → Mail，把发送方式从默认的sendmail改成 SMTP。需要填的参数：

填完保存，进Config → Mail → Send Test Email发一封测试邮件到自己邮箱。收到就说明通了，收不到就往下排查。

4.3 邮件发不出去的排查思路

邮件这块是最容易卡住的地方，我踩过的坑按频率排：

1. 端口和加密方式不匹配。465 配 tls、587 配 ssl 都会连不上。先确认邮件服务商文档里写的组合。
2. 授权码当密码用。很多邮箱服务不允许直接用登录密码发信，要在后台生成一个专用授权码，配置里填授权码。
3. 发件人地址和认证账号不一致。有些服务要求 From 必须等于认证账号，否则拒发。把metamta.default-address设成和smtp.user一样最保险。
4. 容器内 DNS 解析不了邮件服务器。进容器docker exec -it phabricator ping smtp.example.com试一下，不通就是容器网络 DNS 的问题，给容器加--dns 8.8.8.8重启。

注意：测试邮件如果进了垃圾箱，不是配置问题，是收件方策略。让团队成员把发件地址加白名单即可。

4.4 通知规则微调

默认情况下，只要和某个 diff 有关联就会收到邮件，人多的时候会吵。进Config → Notification可以调：

• 关掉“自己操作也给自己发通知”，避免自己评论完还收到一封。
• 把“仅被 @ 或直接分配时通知”打开，减少无关邮件。
• 设置邮件聚合，短时间内多条通知合并成一封，避免刷屏。

这些规则没有标准答案，建议先按默认跑一周，看团队反馈再调，一上来就改太细反而容易漏掉重要通知。

5. 接入代码仓库与 Arcanist 实操

5.1 仓库接入的两种方式

Phabricator 支持两种仓库接入：托管型（仓库建在 Phabricator 里，用它的 SSH 推拉）和观察型（仓库在别处，Phabricator 只读镜像过来做展示和评审）。内网自建通常用托管型，流程最顺。

进Repositories → Create Repository，选 Git，填个名字，创建后进Manage → URIs加一条 SSH URI，格式类似ssh://git@你的机器IP:2222/diffusion/仓库短名/仓库短名.git。加完在容器里执行一次仓库初始化，裸库就建好了。

5.2 Arcanist 的安装与配置

Arcanist 是本地命令行工具，负责把改动打包成 diff 推到 Phabricator。安装方式各平台不同，核心是让arc命令可用。装完后在项目根目录执行：

arc install-certificate

它会提示你打开一个链接，登录后复制 token 粘回来。这一步是把本地arc和你的 Phabricator 账号绑定。token 是账号级的，换机器要重新绑。

然后在项目里配.arcconfig：

{ "phabricator.uri": "http://192.168.1.100:8080" }

这个文件要提交到仓库里，团队成员拉下来就自动知道往哪推。

5.3 提交一次评审的完整流程

假设你在 feature 分支改完代码，流程是：

1. git add和git commit把改动提交到本地分支。
2. arc diff发起评审。它会打开编辑器让你填标题和描述，保存后自动创建 diff 并推到 Phabricator。
3. 在网页上分配评审人，或者arc diff --reviewers 某人直接指定。
4. 评审人收到邮件，点进去逐行评论。
5. 你根据意见改代码，git commit后执行arc diff --update D123（D123 是 diff 编号），新版本追加到同一个评审里。
6. 评审通过后，arc land把代码合入主分支并关闭评审。

arc land这一步会真的推代码到主分支，用之前确认评审确实通过了，别手滑。

5.4 仓库权限与可见性

默认新建的仓库所有人可见。如果团队分多个项目组，进Repositories → Manage → Policies把可见性和推送权限收到对应项目组。Phabricator 的权限模型是基于“项目（Project）”的，先在Projects里建好组，把人加进去，再在仓库策略里引用这个组。权限配错是内网环境最常见的安全隐患，建完仓库顺手检查一遍。

6. 常见问题与排查速查

6.1 启动与访问类问题

6.2 邮件与通知类问题

邮件发不出，九成在 SMTP 参数。按“端口加密组合 → 授权码 → 发件人一致性 → 容器 DNS”这个顺序查，基本都能定位。通知太吵就调 Notification 规则，别直接关邮件，关了等于放弃提醒。

6.3 Arcanist 使用类问题

arc diff报认证失败，多半是 token 过期或 base-uri 变了，重新arc install-certificate即可。arc land报冲突，说明主分支有新提交，先git pull --rebase再 land。这些报错信息其实都挺直白，别急着搜，先读一遍它说了什么。

6.4 数据备份的实操建议

Phabricator 的数据分三块：MySQL 库、/repos裸库、/files附件。备份就是这三样一起打包。我习惯写个脚本，每天凌晨mysqldump出库，再tar另外两个目录，存到另一台机器。恢复的时候三样要一起恢复，只恢复数据库会导致附件和仓库对不上。

7. 我实际用下来的一些体会

这套东西搭起来确实快，三行命令加半小时配置就能跑。但真正让它融入团队工作流，花的时间在配置之外——是让大家习惯用arc diff而不是直接推主分支，是让评审人认真看而不是点个通过。工具只是把流程固化了，流程本身得团队自己认。

几个我踩过之后觉得值得说的点：邮件提醒一定要配，而且要配到“刚好不吵”的程度，太吵大家会设过滤规则，等于没配；仓库权限建完就查，别等出事再补；备份脚本早点写，数据丢了再想起来就晚了。Phabricator 这套工具虽然不再更新，但它的评审模型设计得很扎实，用顺了之后换别的平台反而会觉得别扭。如果你只是想找个能长期稳定跑、不依赖外部服务的评审系统，它依然是个靠谱的选择。