MantisBT从零部署到实战：开源缺陷管理系统的安装配置与团队应用指南

先聊聊我最初接触 Mantis 的场景。那会儿团队里缺陷管理靠的是表格加聊天群，测试人员报一个 bug 要打字描述半天，开发改完还要截图回复，消息一刷屏整个上下文就乱了，漏单、错单、返工全是这么来的。后来我们决定上一套缺陷跟踪系统，对比了几个方案，最终落地的是 MantisBT——大家一般直接叫它 Mantis。前后用到现在，从最开始的安装部署到日常配置维护，踩了不少坑，也积累了一些心得。这篇文章就把 Mantis 从零开始安装、配置到实际使用的完整流程做一个梳理，既适合第一次接触缺陷管理工具的新手，也适合正在评估工具选型的技术负责人参考。

Mantis 本质上是一套开源的 Web 端缺陷跟踪系统，核心价值就是“让每个问题都有迹可循”。它不需要昂贵的商业授权，部署成本低，对服务器要求也不高，一台普通 2 核 4G 的云主机就能跑得很稳健。通过浏览器访问，任何人不需要装客户端就能参与协作，开发、测试、产品都能在一条流程里完成问题流转。最实用的功能包括：缺陷提交与指派、状态流转、自定义字段、邮件通知、多项目管理和用户权限控制，基本覆盖了一个软件团队从收集问题到跟踪闭环的全部需求。

1. 为什么选 Mantis：从选型逻辑到适用场景

1.1 团队卷入缺陷管理的真实痛点

很多中小团队一开始并没有“缺陷管理”的概念，开发靠即时聊天工具接收问题，测试靠表格记录回归结果。等项目和人数同时上来之后，问题才会集中爆发：同一类 bug 被重复提交，开发无法判断优先级，测试搞不清哪些已经修复，历史问题更是无从追溯。等到上线前再集中补台账，往往要花掉大批量人工，而且信息流的失真度极高。

缺陷管理系统的核心职责就是充当“唯一事实源”。每个 bug 拥有独立编号、标题、描述、附件、优先级、指派人和状态，所有变更记录保留历史，谁改了什么、什么时候改的、为什么改，一目了然。这正是 Mantis 这类工具的定位：它不负责重构你的研发流程，只负责让问题信息流保持稳定、可追踪、可统计。

1.2 开源缺陷工具对比：Mantis、Jira、Redmine、禅道

网上关于工具选型的讨论很多，不同公司体量和研发模式适合的方案差异很大。我实际用过 Jira、Redmine 和禅道，各有特点，这里整理一张对比表方便大家判断。

对比下来，Mantis 的优势非常直白：部署轻、吃得少、学习门槛低。如果团队核心诉求就是管好 bug，不愿为了配合工具改变整个协作流程，Mantis 几乎是零摩擦的选择。Jira 确实强大，但工作流配置、权限模型和插件体系对小型团队而言是负担；禅道一体化程度高，但某些团队未必需要它的测试用例和项目集模块，反而显得臃肿。Mantis 的定位足够聚焦，做到严重偏科，不对，是严重专一：一条缺陷从提交到关闭的完整生命周期。

1.3 我建议哪些场景优先考虑 Mantis

结合使用经验，下面几类场景选 Mantis 不会后悔：

• 团队规模在 2~30 人之间，需要快速上线缺陷管理，不想花太多时间维护工具，这是一个很典型的使用阶段。
• 处于创业公司或项目外包状态，预算有限，希望把资源放在业务开发上而非基建平台上。
• 现有流程已跑通，只是缺陷这块依托聊天记录太混乱，需要一个轻量系统把信息沉淀下来。
• 需要自定义状态流和字段，比如某个项目需要额外的“验证方法”“故障等级”等专属信息。

如果团队已经深度使用 Jira 的敏捷看板和需求联动，建议就不要迁移了；如果团队需要完整的测试用例管理、自动化统计报表和需求关联，Mantis 的基础功能偏薄弱，需要靠插件补齐，不如一步到位选禅道或 Jira。工具选型这事，合适比“最强”更重要，我在团队里常说一句话：先想清楚你要解决什么问题，再挑工具。

2. 安装部署前的准备工作

2.1 环境需求拆解：PHP、数据库、Web 服务器

MantisBT 是 PHP 应用，所以核心依赖是 PHP 环境。以当前主流的 2.25 版本为例，要求 PHP 版本不低于 7.3，同时需要启用 pdo_mysql、mysqli 或 pgsql 扩展。非要说哪个数据库最省心，我推荐 MySQL/MariaDB，兼容性最好，网上资料和问题案例也最多。

Web 服务器方面，Apache 和 Nginx 都可以跑。生产环境我习惯用 Nginx + PHP-FPM，原因很简单：并发压力小，内存占用低，反向代理做起来顺手。如果团队对运维不熟，Apache 配合 mod_php 反而是更省事的选择。另外服务器需要具备访问外网的能力，因为安装过程中要下载解压包，后续插件扩展也要在线获取。

一个小提醒：Mantis 对 PHP 的内存限制有最低要求，建议memory_limit设置为 128M 以上。默认配置经常只有 32M，导入较大的数据库脚本或生成统计报表时容易爆内存，从而出现白屏或 500 错误。这一条在官方文档中容易忽略，但实际运维中非常关键。

2.2 获取安装包：下载与目录规划

下载 MantisBT 非常简单，打开官方网站的下载页面，选择最新稳定版 tar.gz 包即可。厂商把压缩包统一维护得很规范，版本信息和 md5 校验值也很有用，习惯上我会在命令行里顺手校验一下哈希，以免下载过程中文件损坏。

服务器上存放路径我建议放在/var/www/mantis或/data/wwwroot/mantis，不要直接放 web 根目录的根上，否则之后的升级迁移会很混乱。如果是多项目共用服务器，建议每个应用单独建目录，Mantis 就是一个独立站点。目录权限上，运行 PHP 的用户需要对该目录有读写权限，特别是config目录和tmp目录，安装向导会往这两个位置写临时文件。

2.3 提前创建数据库与账号

这一步很多人会漏，实际操作中安装向导失败多半是因为数据库权限没给足。建议安装前就通过命令行或管理面板创建好专用数据库和账号，而不是用 root 账户直接连。专用账号遵循最小权限原则，只需要对 Mantis 库的select/insert/update/delete/create/alter/drop/index权限即可。

创建数据库的 SQL 大致如下（以 MySQL 为例）：

CREATE DATABASE mantisbt DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER 'mantis_user'@'localhost' IDENTIFIED BY '你的强密码'; GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, INDEX ON mantisbt.* TO 'mantis_user'@'localhost'; FLUSH PRIVILEGES;

注意字符集一定要指定为 utf8mb4，否则之后提交的缺陷内容如果包含生僻字、Emoji 符号，可能会乱码或保存失败。这个细节是我在实际项目中踩过的坑，早期用了默认 latin1，测试环境没问题，一上线用户从移动端复制了一段带特殊符号的文本，整个记录直接存不进去。

3. 从零开始安装 Mantis 的完整实操

3.1 LNMP 环境快速准备

我这里以 CentOS 7 系统为例，展示一套最常用的 LNMP 环境搭建流程。如果你的服务器是 Ubuntu/Debian，命令换成apt即可，核心思路完全一致。

# 安装 EPEL 和 Remi 源（获取新版 PHP） yum install -y epel-release yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm yum install -y yum-utils yum-config-manager --enable remi-php74 # 安装 Nginx、PHP、PHP-FPM 以及扩展 yum install -y nginx php php-fpm php-mysql php-gd php-mbstring php-xml php-json php-zip # 安装 MariaDB 数据库 yum install -y mariadb-server mariadb systemctl start mariadb systemctl enable mariadb mysql_secure_installation

PHP 扩展中特别要关注php-mbstring，Mantis 的多语言界面，包括中文简体、中文繁体，都依赖这个扩展。如果没装，安装向导能走完，但登录后台后页面会出现空白或者语言包加载异常。

3.2 下载 MantisBT 并设置目录权限

cd /var/www wget https://sourceforge.net/projects/mantisbt/files/mantisbt-2.25.7.tar.gz/download -O mantisbt.tar.gz tar -zxvf mantisbt.tar.gz mv mantisbt-2.25.7 mantis cd mantis chown -R nginx:nginx . chmod -R 755 . chmod 777 config chmod 777 tmp

这里的config目录初始状态下不存在，安装向导会自动创建，但前提是 web 用户有写入权限。如果权限不够，安装时会提示无法写入配置文件，白白浪费时间排查。我给config目录的权限是 777，只是安装阶段临时放开，安装完成后建议立刻收紧为 750 或者直接通过 chmod 修改，毕竟配置文件中包含数据库密码，不应该允许任意用户读取。

Nginx 配置一个最简单的虚拟主机：

server { listen 80; server_name mantis.example.com; root /var/www/mantis; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 7d; log_not_found off; } }

配置好后重载 Nginx 和 PHP-FPM，浏览器访问http://mantis.example.com，就能看到 Mantis 的安装引导页。

3.3 浏览器安装向导逐项解读

安装界面整体分四步：环境检查、数据库配置、管理员设置、确认安装。

第一步环境检查会列出 PHP 版本、扩展加载情况和目录写入状态，每一项显示 OK 或警告。如果出现“未通过”的红色状态，直接按提示解决，常见的是php-mbstring未安装或config目录不可写。

第二步数据库信息填写：

• 数据库类型选择 MySQL Improved（mysqli）。
• 主机名填localhost或数据库服务器 IP。
• 数据库名填mantisbt。
• 用户名和密码填刚才创建的专用账号。
• 表前缀建议默认留空或用mantis_，前者方便 SQL 直查，后者便于识别。

这里要注意的是“表前缀”一旦设定，后期修改成本很高，因为所有 SQL 查询和部分插件都会引用它。首次安装就统一规划好，不要用默认的mantis_后又反悔。

第三步设置管理员账号。系统默认的管理员用户名就是administrator，密码可以在这里直接设置。邮箱务必填写真实可用的地址，后续系统通知和密码找回都要依赖这个邮箱。

第四步点击“安装”后，Mantis 会执行数据库初始化脚本，创建大约一百多张表，然后提示安装完成。走到这一步，安装本质上已经成功了，但强烈建议做一件收尾工作：删除或重命名admin/目录。

cd /var/www/mantis mv admin admin_bak_<date>

这步不做，攻击者可以直接访问admin/install.php尝试重装系统，覆盖数据库导致灾难性后果。每年都能看到不少因为没删 admin 目录被恶意重装的案例，这条算是我列进团队安全红线清单的第一条。

3.4 登录后台并完成基础配置

用管理员账号登录后，会进入 Mantis 的后台管理界面。首先要修改两处地方：时区和语言。

管理操作路径是“管理”——“全局配置”。时区选择Asia/Shanghai，默认时区如果不对，缺陷提交时间和邮件通知时间全是错的，排查问题时容易让人疯掉。默认语言可以设为chinese_simplified，不过我个人更建议先保持auto，让系统根据浏览器语言自动切换界面，这样开发团队中用英文习惯的同学也不会觉得别扭。

还要顺手配置“站点名称”，这个名称会显示在页面标题和邮件通知的主题中。项目初期叫“测试环境Mantis”没问题，但正式部署时建议用团队统一识别的业务名称，比如“某某项目缺陷管理平台”，用户从邮件里收到的通知内容也会更规范。

4. 核心配置细则：用户、项目、邮件与自定义字段

4.1 用户管理与权限角色划分

Mantis 内置六种角色：滑块？不对，依次是访客、查看者、报告者、更新者、开发者、管理者。默认新建用户的角色一般是“报告者”或“查看者”，权限从低到高分配合适的业务动作。

实际使用中我的分配原则是：

• 产品经理：报告者或更新者，负责提交缺陷和补充描述。
• 测试人员：更新者，可以修改状态、指派、添加备注。
• 开发人员：开发者，可以处理缺陷、修改状态、记录修复备注。
• 技术主管：管理者，拥有项目配置、用户管理、导出统计的权限。
• 外部客户：查看者，只读权限，用来跟踪他们提交的问题进度。

用户管理里有一个很好用的功能是“项目-用户-权限”矩阵，可以把同一个用户在不同项目里设置为不同角色。比如某人既是 A 项目的开发，又是 B 项目的测试，这在实际项目中很常见，矩阵配置比一刀切的角色灵活得多。

批量创建用户方面，Mantis 支持导入功能，也可以通过管理界面手动创建。几十人团队手动逐个添加尚可接受，人再多建议直接用 SQL 或写脚本调用 API，官方提供了 SOAP/REST 接口，这个后面细说。

4.2 创建项目与自定义字段

“项目”是 Mantis 缺陷管理的顶层单元，建议一个产品线创建一个项目，而不是一个大项目下堆所有模块。项目创建后在“管理”——“项目”——“编辑”里可以设置或者说是关联子项目。

自定义字段这个功能特别值得花时间打磨。例如一个 App 项目，我通常会定义：

• 设备型号（下拉框：iPhone 15、华为 P60 等）
• 系统版本（文本框）
• 出现频率（下拉框：必现、偶现、极少）
• 版本号（下拉框，关联每个发布版本）
• 严重程度（由默认字段承担，但可以扩展业务维度）

字段需要和“项目”进行关联后，在该项目的缺陷提交页才会出现。关联方式是“管理”——“自定义字段”——选择字段，“管理”——“项目”——该项目——“编辑”，在右侧分配字段列表中添加。有个小细节，每个字段都可以设置“只在新增时显示”“必填”“默认值”等属性，建议必填项不要太狠，不然测试人员填起来有情绪，反而影响提 bug 的积极性。

4.3 邮件通知配置与常见参数

邮件通知是 Mantis 的灵魂功能之一，用户提交缺陷后相关人被邮件提醒，避免每天拿头去刷新页面。SMTP 配置藏在“管理”——“邮件配置”中。

$g_phpMailer_method = PHPMAILER_METHOD_SMTP; $g_smtp_host = 'smtp.example.com'; $g_smtp_username = 'no-reply@example.com'; $g_smtp_password = '你的SMTP授权码'; $g_smtp_port = 465; $g_smtp_connection_mode = 'ssl'; $g_administrator_email = 'admin@example.com'; $g_webmaster_email = 'admin@example.com'; $g_from_email = 'no-reply@example.com'; $g_from_name = 'Mantis Bug Tracker'; $g_enable_email_notification = ON;

注意：很多邮箱的 SMTP 密码不是登录密码，而是单独开通的授权码，比如网易、腾讯企业邮都这样。配置好后建议先给自己发一封测试邮件，确认能收到再告诉团队投入使用。如果邮件发不出去，八成是 SMTP 端口被封了，465 或 587 换着试试，另外 SMTPS 和 STARTTLS 的抓包调试方式也不太一样，后面问题部分细讲。

4.4 通过 REST API 做二次扩展

不少团队用 Mantis 一段时间后会想跟内部系统打通，比如自动化测试工具把失败用例自动建缺陷、CI 流水线根据缺陷状态决定是否允许发布。Mantis 从 2.0 版开始提供了比较完善的 REST API，通过对/api/rest/路径的 HTTP 请求即可操作问题、项目、用户。

# 通过 API 创建一个新缺陷（示例） curl -X POST "http://mantis.example.com/api/rest/issues" \ -H "Authorization: Bearer <token>" \ -H "Content-Type: application/json" \ -d '{ "summary": "登录页面在 iOS 17 下闪现白屏", "description": "复现步骤：使用 iPhone 15 Pro Max，打开登录页，快速切换账号输入框时出现白屏，约 2 秒后恢复。", "project": {"id": 1}, "category": {"id": 1}, "priority": {"name": "high"} }'

API Token 在用户个人资料页面可以生成，每个用户可以申请多个 token，支持标记用途。我的习惯是给自动化脚本单独建一个专用账号，再生成 token，避免脚本误操作影响个人账号数据。

5. 使用场景实战：从一个 bug 的完整生命周期说起

5.1 测试人员提交缺陷的规范操作

很多团队用 Mantis 效果不好的核心原因，不是工具不行，而是使用习惯没建立起来。我总结了一套提 bug 的规范模板，贴在新人入职文档里：

• 标题：言简意赅，格式“模块-现象”，例如“支付-微信支付成功后回调未跳转”。
• 严重程度：结合影响范围选择，崩溃级、阻塞级、一般、轻微、建议。
• 复现步骤：分点写清楚前置条件、操作路径、实际结果、期望结果。
• 附件：能截图就截图，能录屏就录屏，附件是速度最快的信息载体。
• 指派对象：清楚归属就指派给对应开发，不清楚就指派给直属测试组长。
• 备注：补充设备型号、环境地址、账号权限等上下文信息。

给新人培训时我反复强调一个逻辑：好的缺陷单应该像一份完整的实验报告，另一个人不需要和提报人沟通，仅凭描述就能复现问题。这样既不浪费开发时间，也能减少来回沟通成本。

5.2 开发处理与状态流转的精简模型

Mantis 默认的状态机包含：新建、已指派、已反馈、已承认、已确认、已分配、已解决、已关闭。这套状态机对各种团队流程兼容度很高，但状态太多对小型团队反而增加负担。

我实际部署时简化成一条流水线：新建 → 认可/指派 → 修复中 → 待验证 → 已验证 → 关闭。简化通过“工作流配置”来实现，在管理菜单中设置可见状态和转换关系，比如“新建”只允许转化为“认可/指派”，不允许直接跳到“已关闭”，保证每个环节都有责任人。

状态流转的核心好处是“责任可追踪”。谁提的 bug、谁认可了、谁负责修、谁验收，每一步都有记录，复盘会上直接查历史即可。团队成员对状态的职责边界非常明确，减少了大量私下沟通成本。回头来看，这比任何花哨的统计报表都重要。

5.3 定时统计与质量度量

Mantis 默认就带有“统计报表”模块，可以按项目、按处理人、按状态生成缺陷密度、打开率、平均修复时间等图表。我给部门做周报时，经常直接从“统计”——“报表”导出 CSV，然后再拿来做汇总。

更高级的需求可以用 REST API 把数据拉到自己的报表系统，比如定时执行 Python 脚本拉取指定时间段的缺陷，由 Python 脚本写入业务库，生成团队自有看板。这里给一个简单示例：

import requests import json from datetime import datetime, timedelta url = "http://mantis.example.com/api/rest/issues" headers = {"Authorization": "Bearer <token>"} params = { "project_id": 1, "page_size": 100, "page": 1, "filter": "date_submitted", "from_date": (datetime.now() - timedelta(days=7)).strftime("%Y-%m-%dT%H:%M:%S"), "to_date": datetime.now().strftime("%Y-%m-%dT%H:%M:%S") } resp = requests.get(url, headers=headers, params=params) issues = resp.json()["issues"] print(f"过去 7 天新增缺陷：{len(issues)}")

有了历史数据之后，缺陷趋势分析就能帮助企业做质量预测，比如临近发版前一周新增缺陷曲线是否收敛，长期不关闭的遗留缺陷占比是否过高，这些都对团队迭代节奏有指导价值。

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

6.1 问题速查表

下面的速查表来自我和团队这些年实际操作中遇到的真实问题，可以直接当成排查手册用。

6.2 邮件调试的实战心得

邮件问题是我被问得最多的一项，因为邮箱服务商的环境差异太大。自己排查时可以先脱离 Mantis，直接用命令行测一下 SMTP 是否通：

telnet smtp.example.com 465

如果不能连接，大概率是网络策略或云服务商封禁了端口。能用命令行发信的证明网络没问题，再去检查 Mantis 的配置。还有一类坑是 SMTP 连接方式不匹配，SSL 和 TLS 的区别以及端口映射，可以参考邮箱服务商提供的具体参数。

6.3 数据备份与升级注意点

Mantis 的数据全部在数据库里，所以备份数据库就是备份整个系统。我习惯每天凌晨用 crontab 做一次完整的mysqldump，保留最近 7 天的备份文件，然后同步到异地存储。

mysqldump -u mantis_user -p'密码' mantisbt > /backup/mantis_$(date +%Y%m%d).sql

升级版本前务必备份一次数据库和旧代码目录。Mantis 的官方升级流程很简单：下载新版包，覆盖旧文件但保留config目录，然后访问安装向导它会自动识别当前版本并执行迁移脚本。但代码覆盖前一定先确认你是否有修改过核心文件——如果有，升级后可能被覆盖丢失，最好用版本管理软件或 diff 工具确认后操作。

6.4 捍卫系统安全：目录权限、登录策略与 HTTPS

Mantis 默认提供了基础防护，但企业使用最好再加几层：

• 强制 HTTPS 访问，在 Nginx 层配置 301 跳转，避免账号密码明文传输。
• 开启密码复杂度校验，在全局安全配置里设置最少位数和复杂度要求。
• 开启登录失败锁定机制，比如失败 5 次锁定账号 15 分钟，防暴力破解。
• 定期审计用户列表，离职员工的账号及时禁用或删除。

这些配置在“管理”——“安全”菜单下都有入口，十人规模团队也别偷懒省掉，安全意识要从小团队建立，越早越省事。

7. 插件扩展与生态

7.1 常用插件推荐与安装方式

Mantis 的插件目录在源码包的plugins/下，安装插件就是在该目录解压压缩包，然后在管理后台的“插件管理”里点击安装。推荐几个实际使用下来口碑不错的插件：

• EmailReporting：支持通过邮件创建问题，适合客户通过邮件反馈场景。
• ExcelExport：增强导出到 Excel 的功能，比内置 CSV 更适配中文办公需求。
• MantisGraph：提供图形统计图表库支持，默认的图表模板比较朴素，这个能做得更美观点。
• SavedQuery：部分版本有已内嵌的功能，如果找不到就装这个插件来自定义筛选视图。

插件安装数量不建议贪多，每个插件都是一份需要升级维护的代码。我见过生产环境装了十几个插件，一次版本升级直接兼容性爆炸，折腾了好几天。插件生态虽好，但生产环境能少装就少装。

7.2 与代码仓库、IM 工具的联动

Mantis 支持与 Git、SVN 的高级联动，配置源码管理接口后，源码提交信息中可以带上缺陷编号，系统会自动在对应缺陷下追加备注。我自己最常用的联动方式是自定义 Webhook 脚本，把状态变更推送到企业微信群或飞书群，这样每个流转动作团队都能实时感知，比频繁刷邮件高效得多。

推送脚本的思路很简单：在 Mantis 的 API 事件钩子里注册回调，或者用一个外部脚本定时轮询变更记录，检测到状态变化后再调用 IM 机器人发送消息。这些扩展能力说明 Mantis 的开放接口设计得很成功，不会把你锁死在一个封闭的产品里。

8. 最后分享一点实际运维中的体会

用了 Mantis 这几年，我有一个很深的体会：缺陷管理系统的成功与否，一半取决于工具选型，另一半取决于团队的日常使用习惯。工具只是容器，装进去的内容和流程才是真正的价值。新团队上线 Mantis 时，我会在第一个月坚持每周看一次数据，抽查若干条缺陷单的填写质量，发现问题直接在工作群里给出修改建议。等大家养成规范的操作习惯之后，系统的价值会越来越好，统计分析也有了真实的数据基础，团队的安全感也随之提升。

如果你的团队现在还在用聊天记录和表格管理 bug，真的建议花一个下午把 Mantis 部署起来。按本文的流程走一遍，加上配置邮件通知和简化状态流，第二天就能投入使用。后续等到使用成熟，再逐步扩展插件、API 和统计功能，完全来得及。