一提到自建Bug跟踪系统很多人第一反应是JIRA或者禅道但预算有限、服务器配置又不高的情况下还有一个老牌免费方案经常被低估MantisBT。这个从1998年就开始发展的开源缺陷管理工具用PHP加MySQL就能跑起来一台低配云服务器就能带得动整个团队的Bug流转。我从第一次接触Mantis到目前前前后后部署过三四套安装配置过程中踩过的坑、整理出来的实用配置正好可以完整梳理成一篇实践记录。这篇文章围绕Mantis的安装、配置与日常使用展开适合预算敏感的中小团队、外包团队以及想在内网自托管缺陷管理系统的技术负责人参考。1. MantisBT是什么它凭什么还在被大量使用1.1 一个被低估的老牌Bug跟踪工具MantisBT的全称是Mantis Bug Tracker出身于SourceForge时代代码仓库和社区一直活跃到今天。它的定位非常清晰提供一套Web化的缺陷全生命周期管理。用户提交Bug、指定项目和模块、填写严重级别与优先级、指派给开发人员、跟踪状态从“新建”一路走到“已关闭”这套闭环做得很扎实。它不追求花哨的界面也不试图替代项目管理工具而是专心把“缺陷跟踪”这一件事做好。也正因为如此很多团队把它当内部工单系统用运维组报故障、测试组提Bug、外包项目按客户维度拆分类都能适配。开源、GPL许可、没有用户数限制对预算敏感的小团队来说这是它能活二十多年还不被淘汰的根本原因。1.2 和Redmine、禅道、JIRA的横向对比维度MantisBTRedmine禅道JIRA部署复杂度低PHPMySQL即可中需要Ruby环境中PHPMySQL高需要Java容器许可证成本GPL免费GPL免费开源版免费企业版收费按用户按年订阅价格不低技术栈PHP MySQL/MariaDBRuby on RailsPHP MySQLJava Tomcat界面体验朴素但够用中规中矩偏向国内使用习惯现代交互出色扩展性插件体系适中插件生态丰富内置功能较多插件市场庞大我在这里不是要分个高下而是想说明选型逻辑。JIRA的体验确实好但一个十人团队一年的订阅费用可能就劝退了Redmine功能强但Ruby环境在部分公司网络环境下装起来够折腾禅道的项目管理感更强但如果只想要一个纯粹的Bug跟踪入口反而显得重。MantisBT的好处在于它能用最少的资源完成团队对“缺陷管理”的全部核心需求。1.3 三类最适配MantisBT的团队场景结合我实际部署过的项目来看MantisBT最适合的是这三类场景外包团队同时负责多个客户项目按项目隔离权限一个系统管理所有客户反馈内部IT/运维组需要一套简单的工单入口不想维护复杂系统又要内网自托管传统企业技术部门数据不能放第三方SaaS需要一个轻量自托管方案但没有专职DBA去维护复杂部署如果你正在这类团队里那接下来这部分MantisBT安装配置与使用的经验应该能帮你避开不少实际部署中的坑。2. 装之前必须想清楚版本选择和环境依赖2.1 基础组件和版本要求MantisBT对运行环境的要求不算高但版本选错会让你在安装向导那一步就被卡住。以目前主流的2.26/2.27系列为例官方对环境的最低要求大致如下组件建议版本说明PHP7.4 ~ 8.1不要再用5.x很多老函数已被移除MySQL5.7MariaDB 10.2同样兼容我自己更偏好MariaDBWeb服务器Apache 2.4Nginx也可以就是伪静态规则要自己调内存256MB以上128MB能跑但后台统计页面会明显变慢容易被忽略的一点是PHP扩展。MantisBT依赖pdo_mysql如果装的是精简版PHP可能压根没启用这个扩展。装系统前先执行一句php -m | grep pdo_mysql确认一下避免装到一半才发现连不上数据库。2.2 环境搭建测试用XAMPP生产老老实实LNMP/LAMP如果你是第一次接触MantisBT只是想本地快速体验那用XAMPP或者WAMP最快下载、解压、启动Apache和MySQL就能进入安装向导十分钟能看到界面。但生产环境我的建议是分情况来看。如果公司没有禁面板的规矩用宝塔这类Linux面板搭建LNMP环境效率最高Nginx配置、数据库创建、目录权限都在一个界面里操作。如果公司规范严格那就手写Apache虚拟主机或者Nginx server块核心是把站点根目录指向MantisBT目录并让index index.php这条规则生效。我自己的生产部署用的是PHP 7.4加MariaDB 5.7没追新版本。原因很简单MantisBT不是那种需要尝鲜的应用稳定压倒一切工具链越保守越省心。2.3 目录布局和数据库规划下载解压后MantisBT是一个完整目录里面有config/、lang/、plugins/、core/这些子目录。生产环境我建议放在独立目录比如/data/www/mantisbt不要丢在混了一堆其他网站的根目录里。好处是升级、备份、容灾迁移时整个系统边界非常清晰。数据库规划方面一个Mantis实例对应一个独立数据库。官方默认表前缀是mantis_如果你想在同一台MySQL服务器上跑开发版和正式版两个实例可以分别建库或者通过安装向导把表前缀改成mantis_dev_、mantis_prod_这种。前缀在安装时就能指定后期基本没人会改所以第一次就要想好。3. 一步步装起来从下载到初始化向导3.1 下载MantisBT的两种方式MantisBT的官方下载入口做过几次改版目前稳定版主要从官网mantisbt.org的Download页面跳转或者直接去GitHub的Releases页面下zip包。生产部署我强烈建议下载Release标签下带版本号的稳定包不要图省事clone master分支开发分支可能带着尚未彻底验证的改动。下载后解压到Web目录Linux环境下记得执行一次修改属主和权限的操作确保Web服务器用户能正常读写。很多人忽略这一步结果安装向导里疯狂报目录不可写其实不是MantisBT的问题是权限没给够。3.2 配置Web访问和关键目录权限Nginx环境下核心配置大概是这样的server { listen 80; server_name mantis.example.com; root /data/www/mantisbt; index index.php; location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }如果你用宝塔或者Apache虚拟主机创建站点、选择PHP版本、指定目录即可不用手写这些。这里要重点说下config/目录的权限。安装向导会在初始化时写入配置文件所以这个目录需要Web用户可写。我一般先确保目录属组设置为www权限给755安装完成后保持这个状态就够了。很多教程让你直接chmod -R 777那是偷懒的做法安全上其实是把系统裸奔给别人。3.3 安装向导每个字段到底该怎么填浏览器访问http://你的域名/admin/install.php先做环境检查确认PHP版本、扩展、目录权限都满足要求后进入数据库配置页。这一步的字段值得逐一说明Database Type保持MySQL不用动HostnameMySQL和Web在同一台机器就用localhost分开部署就填MySQL内网IP并确认3306端口在防火墙里放行Username / Password建议单独创建数据库账号比如mantis只授予使用Mantis数据库的权限别图方便用rootDatabase name命一个清晰的名字比如mantisbtAdmin Username / Password这里创建的是Mantis系统的管理员账号默认预填了administrator密码默认是root安装引导会要求修改。我建议直接改成其他用户名加强密码少一个被弱口令爆破的入口填完点击执行按钮一两分钟内看到成功提示说明数据库初始化完成了。如果报错绝大多数集中在MySQL账号权限、pdo_mysql扩展缺失这两类问题上按提示排查即可。3.4 初始化完成后的安全清理安装成功的页面上会有一段提醒删除或保护admin/目录。这一步千万别当成形式化建议。如果线上环境还留着install.php任何人都可以访问它重新执行安装等于把数据库的控制权交出去了。我的做法是把整个admin目录改名成admin_backup需要升级时再临时改回来。如果用Nginx也可以加一段配置把/admin/路径直接拒绝访问两道防护都做上。4. 装完只是开始config_inc.php里必须手动改的几项4.1 中文界面不只是语言选项MantisBT自带几十种语言包简体中文对应lang/目录下的chinese_simplified。安装完成后用管理员登录进入“管理”→“管理配置”→“界面”把默认语言改成chinese_simplified新用户默认就会看到中文界面。这里有个我实际踩过的坑如果只改系统默认语言之前已经创建好的用户仍然停留在英文界面。正确做法是同时到“用户管理”里批量重置用户语言偏好或者提前确认团队所有成员都还没注册。另外中文显示还依赖数据库字符集MySQL连接和表结构必须是utf8mb4否则Bug描述里的中文偶尔会变成乱码。如果建库时不小心选了latin1趁数据量不大尽快重建别等到积累一堆数据再来折腾。如果你想更省事也可以直接在配置文件里写死$g_default_language chinese_simplified;效果和管理后台改是一样的。4.2 SMTP邮件通知为什么默认就是发不出去邮件通知是MantisBT最核心的功能之一Bug被指派人、状态被修改、新评论出现都应该及时邮件触达。但默认配置下系统使用PHP的mail()函数发信云服务器、内网Windows机器上这个函数基本等于废的。正确做法是在config/config_inc.php里配置SMTP$g_phpMailer_method PHPMAILER_METHOD_SMTP; $g_smtp_host smtp.example.com; $g_smtp_port 587; $g_smtp_connection_mode tls; $g_smtp_username your_account; $g_smtp_password your_password; $g_from_email mantisexample.com; $g_from_name MantisBT;几个容易翻车的细节端口和加密方式必须匹配常见组合是587 tls或者465 ssl$g_from_email建议和SMTP认证账号完全一致很多邮件服务器会拒收“发件人和登录账号不一致”的邮件配置完成后到管理后台的“邮件测试”功能发一封试发邮件或者干脆建一个测试Bug看能不能收到通知。不要只看配置文件觉得没问题就关掉4.3 时区、URL路径和附件上限config_inc.php里还有几个建议开箱就改的项$g_default_timezone Asia/Shanghai; $g_path http://你的域名/; $g_max_file_size 8388608;时区不设置Bug提交时间会偏几个小时后续统计图表全乱。$g_path影响邮件通知里附带链接的域名如果你用IP部署、或者以后要换域名不改这里邮件里的链接全是错的。上传附件默认限制不大我习惯把PHP的upload_max_filesize和这里的$g_max_file_size一起调大到8MB左右方便测试同学直接贴截图和日志。5. 团队用起来的核心配置角色、权限和自定义字段5.1 五档角色权限看这一张表就够MantisBT默认权限从低到高分为查看者、报告者、更新者、开发人员、管理员五档。各角色核心区别如下角色能做什么不能做什么查看者查看被分配的Bug、阅读评论不能新建、编辑任何Bug报告者新建Bug、补充评论不能修改指派、不能关闭更新者编辑自己报告的Bug信息不能改动他人Bug的核心字段开发人员指派、解决、更新状态不能修改系统全局配置管理员全部权限无实际分配时权限是“项目用户”粒度的。也就是说同一个用户可以在项目A里当开发人员在项目B里只是查看者。这个在“项目管理”→“用户管理”里按项目逐个设置就行。对于外包团队来说这个设计非常实用客户方成员只给查看者权限自己团队给开发人员权限边界一下就清楚了。5.2 把状态流转调整成你自己团队的流程MantisBT默认的状态机是新建→反馈→确认→已指派→已解决→已关闭。但每个团队流程都不太一样比如设计团队想加一个“评审中”运维团队希望有“已排期”这时候要去“管理”→“工作流阀值”调整。这个页面没有图形化拖拽是一堆勾选框但权限控制很细。你可以指定每个状态下哪些角色有权限把Bug切换到下一个状态。我通常做两个调整把“已指派”状态的切换权开放给开发人员把“已解决”的确认权保留给报告者不允许开发人员自测完直接关单这样处理后整个闭环会更贴近真实协作场景测试提交、开发认领、解决返还、测试确认关闭每一步都有明确的负责人。5.3 自定义字段Bug表单按你的业务需求改不少团队觉得MantisBT默认表单不够用其实它支持自定义字段。位置在“管理”→“自定义字段管理”可以新增下拉框、文本框、日期类型字段比如“涉及模块”、“客户名称”、“影响用户数”等。这里有我头一回部署时踩过的坑字段建好以后必须回到“项目管理”→“编辑项目”→“自定义字段”里把它绑定到具体项目否则新字段不会出现在Bug创建页面上。我当时建了好几个字段跑去提Bug却一个都看不到绕了一圈才发现是没绑定。字段和项目是多对多的关系同一个字段可以复用给多个项目但必须显式绑定。5.4 私有项目和版本管理多项目团队的关键操作如果系统里同时跑着多个项目还要注意“私有项目”的设置。私有项目不会显示给非成员用户适合外包团队做客户隔离。创建项目时勾选“私有”再把相关人员添加进去即可。项目下的“分类”和“版本”两级结构建议尽早规划好。分类按模块拆比如登录、支付、报表版本按发版节奏建比如 v1.0、v2.0。版本管理里还能标记已发布或未发布之后按版本过滤Bug就很方便客户一提“v1.0支付有问题”打开版本筛选相关Bug全部列出来对应到人安排修复效率比翻聊天记录高太多。6. 日常使用中容易踩的坑和我的配置清单6.1 邮件通知不工作一条完整排查链路邮件问题是我在MantisBT使用中收到求助最多的一块这里给一套可以照着走的排查顺序到“管理”→“管理配置”→“邮件通知”确认各事件的通知开关处于开启状态检查config_inc.php里的SMTP配置账号密码不要有隐藏空格用管理后台的“发送测试邮件”看返回的具体错误如果系统提示发送成功但仍收不到去MantisBT日志目录看SMTP通信记录确认认证是否真的通过最后检查收件邮箱的垃圾箱公司自建邮箱比较容易拦截外部邮件的投递实测下来80%的邮件问题出在SMTP端口不通或者$g_from_email和认证账号不一致。剩下那部分邮件多半进了垃圾箱加白名单就好。6.2 升级和迁移时最容易搞砸的操作MantisBT版本升级不算频繁但一旦要升千万别把新版本文件直接覆盖旧目录否则配置、上传附件、插件会乱成一团。标准流程是这样备份当前数据库和完整站点目录在新目录里解压新版MantisBT把旧版的config/目录和上传目录一并复制过去访问/admin/install.php选择“Upgrade”让安装器完成数据库结构升级升级成功后再次确认admin/目录已被保护换服务器迁移时数据库备份用mysqldump导出再导入不要图省事直接复制MySQL的data目录。特别是源服务器和目标服务器MySQL版本不一致时直接复制data目录极容易损坏表结构。顺便说下备份一台配了cron的Linux服务器用一条命令就能定时把Bug数据备份走0 2 * * * mysqldump -u mantis -p密码 mantisbt | gzip /backup/mantis_$(date \%Y\%m\%d).sql.gz%在crontab里需要转义写成\%才能正确执行。6.3 慢、卡、白屏资源与PHP环境的常见问题小团队部署MantisBT基本都是用低配服务器访问变慢先检查这几处PHP的opcache扩展是否开启开与不开响应速度能差好几倍MySQL的max_connections是否充足连接数打满会表现为页面长时间转圈后报错config/目录和日志目录有没有堆出超大文件安装的插件是不是太多了不用的插件及时卸载还有一个经典白屏场景PHP 8.2以上版本和某些旧版MantisBT存在兼容问题页面直接白屏而且报错不明显。所以生产环境我用的是PHP 7.4安全稳定MantisBT官方测试覆盖也最充分。6.4 我给新团队的快速配置清单最后分享一份我每次部署MantisBT都会照着走的检查清单环境PHP 7.4、MySQL 5.7、Nginx或Apache数据库独立账号、utf8mb4字符集、独立库安装完成后删除或禁用admin/目录界面默认语言设置为简体中文时区设置为Asia/Shanghai邮件SMTP TLS 发件人地址与认证账号一致权限按项目逐个分配用户角色工作流调整状态流转补充团队所需枚举和自定义字段备份配置cron定时导出数据库和上传目录照这个清单走一遍MantisBT基本就能稳稳跑起来了。就算中途遇到问题也不用慌这个系统存在时间足够长踩过坑的人多按日志和报错提示一步步查基本都能找到答案。最后说句实际的体感MantisBT不算惊艳的工具但它是真的皮实。别人问我“有JIRA为什么还用Mantis”我的回答通常是如果一个Bug系统能一个晚上部署完成、不花一分钱授权费、还满足团队缺陷管理的完整闭环那它就是现阶段最合适的选择。等团队真的大到需要复杂工作流和现代化界面时你再迁移也不迟——而且到那时候你已经很清楚自己对Bug管理工具的真实需求是什么了。