Bugzilla 介绍与选型指南

Bugzilla（Mozilla 血统老牌开源缺陷跟踪系统，MPL-2.0）的认知与选型篇：来历与治理沿革、Perl+CGI 架构、核心功能、官方最新稳定版 5.2 的版本节奏，以及与 Redmine/MantisBT/Trac 的量化选型对比表。

BugzillaBugzilla2026/10/28

Bugzilla 介绍与选型指南

目标：面向「需要一套自托管缺陷跟踪/工单系统」的技术团队，系统介绍 Bugzilla 的来历、架构、功能与选型结论。本文为认知篇，全部信息来自官方渠道联网溯源（官方站点、官方仓库、官方文档、shields.io 徽章），查询日期为 2026-10-27；本文不含本地实测内容，部署、配置与运维的逐条实测过程见本专栏配套的部署实战、配置参数与运维实战文档。

一、环境信息

本文是纯联网溯源的认知篇，不含本地实测，因此「环境信息」记录的是本文的取证口径与信息源清单，便于读者复核时效性。

项目取值
查询日期2026-10-27
官方网站https://www.bugzilla.org
官方源码仓库https://github.com/bugzilla/bugzilla（README 自述：Mozilla 社区志愿者开发的自由开源 Web 缺陷跟踪软件）
官方发布信息页https://www.bugzilla.org/releases/
官方下载页https://www.bugzilla.org/download/
官方安装文档https://bugzilla.readthedocs.io/en/latest/installing/
治理方年报https://www.bugzilla.org/assets/pdf/ZBC%20Annual%20Report%202024-25.pdf
社区活跃度取证shields.io 徽章（https://img.shields.io/github/stars/<owner>/<repo>.svg）

💡 说明：本文引用的版本号、日期、许可证与下载地址均以查询当日官方页面为准；GitHub 星数为查询当日 shields.io 徽章读数，仅作社区关注度的粗粒度参考。

二、软件概述

Bugzilla 是一套历史极其悠久的自由开源 Web 缺陷跟踪系统（Bug Tracking System）。根据官方 Releases 页面的版本历史，Bugzilla 首个版本 2.0 发布于 1998 年 9 月 19 日，最初由 Netscape/Mozilla 社区开发，是「Bugzilla 型工单流程」这一行业范式的奠基者之一。官方仓库 README 对它的自述是：由 Mozilla 社区一组活跃志愿者开发的、自由开源的、基于 Web 的缺陷跟踪软件，被全球数千个项目与公司使用，可安装在 Linux 及其他 Unix 变体、Windows 或 Mac OS X 上。

许可证方面，官方下载页与仓库 README 均明确：Bugzilla 采用 Mozilla Public License 2.0（MPL-2.0）发布，既是自由软件也是开源软件。这意味着它可以被自由地自托管、修改与再分发（仅修改再分发时受 MPL-2.0 的文件级 copyleft 约束）。

治理与归属上，Bugzilla 社区在 2024 年完成了从 Mozilla 基金会体系向独立实体「Zarro Boogs Corporation（ZBC）」的过渡。ZBC 2024-25 年度报告（查询自官方站点的公开 PDF）写道：2024 年 9 月 3 日发布的 Bugzilla 5.2，以及同日配套发布的两个旧分支维护版（4.4.14 与 5.0.4.1），是首个以 ZBC 名义发布的 Bugzilla 版本。ZBC 负责维护官网与少量 Linode 服务器，代码托管与基础设施依赖 GitHub。对选型者的含义是：项目仍是社区驱动，但治理主体已明确、资金与资产归属清晰。

版本现状（查询自官方 Releases 页，2026-10-27）：

分支角色版本发布日期说明
开发主干（Trunk）5.9.1开发快照面向 6.0 的开发线，新特性在此合入
废弃主干（Deprecated Trunk）5.3.3开发快照曾的主干线，仅保留安全/崩溃/数据丢失级修复，待提供到 5.9.x 的升级路径后移除
当前稳定版5.22024-09-03仅包含缺陷修复与性能改进：无新特性、无数据库 schema 变更、无模板结构变更
旧稳定版5.0.4.12024-09-03仅安全/崩溃/数据丢失级修复
已停止支持4.4.14 及更早2024-09-03（最后维护版）官方政策：早于旧稳定版的全部版本不再支持

对版本节奏的客观描述：Bugzilla 的稳定分支维护以「年度级大版本 + 长周期小修」为主。5.2 自 2024-09-03 发布后至今（2026-10-27）官方 Releases 页未列出 5.2 分支的任何小版本（如 5.2.1），说明该分支在这一周期内保持原版滚动；官方明确承诺 5.2 线只做修复与性能改进、不改 schema，这降低了跟踪最新修复版的风险，但也意味着功能演进要等 6.0。官方同时声明：从任意旧版 Bugzilla 都可以直接升级到最新稳定版，无需逐版本过渡。

💡 技术拓展：缺陷跟踪系统的「版本节奏」大致分三种模式——持续滚动发布（如 GitLab 每月发版）、稳定线长周期维护（Bugzilla 5.2 模式：大版本间隔数年、小版本仅安全修复）、社区凉却仅安全响应（若干老牌工具的现状）。选型时节奏快不等于好：对缺陷跟踪这类「流程载体」系统，schema 稳定、升级低风险往往比新特性更重要；Bugzilla 官方对 5.2 的「无 schema 变更、无模板变更」承诺正是这一思路的体现。本文聚焦的 5.2 属于第二种模式。

三、核心架构

Bugzilla 是一个典型的「Perl + CGI + 关系数据库」三层 Web 应用。官方安装文档（bugzilla.readthedocs.io 的 Installing 章节）与官方仓库 README 给出的架构要点如下：

  1. 语言与运行形态：服务端完全由 Perl 编写，以 CGI 脚本形态运行在 Web 服务器（推荐 Apache httpd，文档亦支持 nginx + FastCGI 等形态）之下，可通过 mod_perl 或 FastCGI 提升性能。5.2 对 Perl 模块有明确清单，核心依赖包括 Template Toolkit（模板引擎）、DBI/DBD（数据库抽象层）、Email::Sender（邮件发送）等，官方提供 checksetup.pl 安装脚本自动检测与引导安装缺失的 Perl 模块。
  2. 模板引擎要求：5.2 的官方安装文档要求 Template Toolkit ≥ 3.008——这是 5.2 相对 5.0 系列的一个关键新约束（多数老发行版仓库自带的 Template 2.x 版本不满足），部署时需通过官方自带的 install-module.pl 从 CPAN 安装或手动升级。这是从旧版本升级 5.2 时最常见的兼容性要点之一。
  3. 数据层：官方支持的关系数据库后端为 MySQL 与 PostgreSQL 两大类（安装文档给出两种数据库的完整初始化流程；MySQL 生态下 MariaDB 同样可用，官方仓库还附带 MariaDB 专用的 Docker 定义文件作为佐证）。Bugzilla 通过自身的 Bugzilla::DB 抽象层访问数据库，schema 由 checksetup.pl 自动创建与升级。
  4. 模板与多语言：界面全部由 Template Toolkit 模板渲染，本地化即「模板翻译包」，官方下载页列出了保加利亚语、捷克语、德语、西班牙语、法语、日语、波兰语、俄语与繁体中文（zh_TW）等第三方本地化模板包；值得注意的是列表中没有简体中文（zh_CN）官方收录——中文团队选型时需要评估这一点或自行维护汉化模板。
  5. 接口层：除 Web UI 外，Bugzilla 内建 REST API（/rest/ 前缀）、XML-RPC 与 JSON-RPC 接口，覆盖 bug 的增删改查、产品/组件/用户/参数管理等域，供脚本与外部系统集成；官方 README 还提供了 Docker Compose 快速体验定义。
  6. 扩展机制：代码库内置 extensions/ 目录，官方文档提供扩展开发指南；Red Hat 等大型用户正是基于该机制在其内部发行版上叠加定制功能（Red Hat 公开的 Bugzilla 5.0.4 定制版文档即为佐证）。

💡 技术拓展：「Perl CGI 应用」在现代语境下常被误解为落后形态。事实上 CGI 只是一种进程模型约定，Bugzilla 的生产部署通常走两条路之一：mod_perl（把 Perl 解释器嵌入 Apache 进程，脚本常驻内存，性能最佳）或 FastCGI（独立常驻进程池）。裸 CGI 每请求 fork 解释器，只适合小流量。选型时应把「是否启用 mod_perl/FastCGI」当作与 PHP 应用「是否启用 OPcache」同级别的默认动作看待。

四、功能特性

以下特性均可在官方文档站（bugzilla.readthedocs.io 的 Using/Administering 章节）与官方功能页溯源：

  • 标准缺陷生命周期：状态机覆盖 UNCONFIRMED（未确认）→ CONFIRMED（已确认）→ IN_PROGRESS（处理中）→ RESOLVED（已解决，含 FIXED/INVALID/WONTFIX/DUPLICATE/WORKSFORME 等解决码）→ VERIFIED（已验证）→ CLOSED（已关闭），全流程可配置，解决码与状态流转可按需增删。
  • 产品/组件/分类三维组织：Bug 归属于 Product（产品）→ Component（组件）→ Version（版本），并为每个组件绑定默认负责人与质量保证（QA）联系人，天然贴合多产品团队。
  • 字段与流程可扩展：支持自定义字段（custom fields）、自定义状态与解决码、合法性校验规则（legal values）、工作流定制。
  • 权限与安全模型：基于组（Group）的细粒度权限，可按产品隔离可见性（如安全漏洞仅安全组可见，配合 Security 组实现漏洞保密流程）。
  • 邮件驱动协作：每个 bug 变更触发 CC/ Reporter / Assignee 邮件通知；支持 Whine（定时邮件提醒/催办）；支持通过电子邮件直接建 bug 与回复评论（Inbound Email）。
  • 附件与补丁评审：支持任意附件类型控制、大附件管理，配合可选的 Patch Viewer（需 PatchReader 模块）可在线浏览补丁差异——这是它作为「开发流程工单」的经典能力。
  • 报表与图表：报表（Reports）、图表（Charts，需 GD/Chart 套件模块）、保存的搜索（Saved Searches）、new-charts 历史趋势统计（collectstats.pl 采集）。
  • 时间跟踪与工作量：内置工时字段（预计/实际工时、deadline），可关闭以满足简单场景。
  • 投票与重复检测：Vote 机制支撑需求排序；提交相似摘要时自动提示疑似重复 bug（duplicate detection）。
  • 搜索与查询：结构化高级搜索（布尔条件组合）、快速搜索、查询存档与订阅（可输出为 RSS/atom/ICS）。
  • API 自动化：REST/XML-RPC/JSON-RPC 三套接口 + 用户 API Key，便于与 CI、IM 机器人、数据仓库集成。

五、快速开始（最小可用示例）

本节给出官方文档中的两条最小上手路径（均为官方渠道原文口径的转述与引用，查询日期 2026-10-27；本文不包含本地实测，完整的逐条命令实测部署过程见本专栏部署实战文档）。

路径一：Docker Compose 快速体验（官方 README 提供，最快）。官方仓库 README 原文说明：如果已安装 Docker，只想快速体验，可以 cd 进入 bugzilla 目录（即包含 README 的目录）后执行 docker compose up，控制台会在初始化完成后打印访问地址与默认管理员账号密码。README 同时提示：若初始化期间 checksetup.pl 因 UTF-8 转换需要交互确认而停止，可显式加环境变量 BZ_ALLOW_UNSAFE_UTF8_CONVERSION=1 允许该转换（官方强调仅在理解警告并备份数据的前提下使用）。该路径适合评估与演示，不适合生产。

路径二：官方源码安装（官方推荐的生产路径）。官方下载页明确表态：获取、维护与升级 Bugzilla 的最佳方式是从对应分支做源码 checkout（当前即 release-5.2-stable 分支），安装与维护操作以官方 Installation and Maintenance Guide 为准；若确需 tarball，官方在下载页提供 5.2 稳定版的直接下载：https://ftp.mozilla.org/pub/webtools/bugzilla/5.2-branch/bugzilla-5.2.tar.gz （下载页同时提供 5.0.4.1、4.4.14 旧分支与 5.9.1/5.3.3 开发快照的 tarball，以及跨小版本的手工升级补丁包）。源码路径的标准流程为：安装 Perl 依赖 → 部署到 Web 目录 → 运行 ./checksetup.pl 完成数据库 schema 初始化与参数生成 → 配置 Apache → 浏览器访问完成管理员创建。

⚠️ 注意：无论哪条路径，5.2 都要求 Template Toolkit ≥ 3.008 与 Email::Sender ≥ 2.600 等模块版本约束（见官方安装文档），在 Ubuntu/Debian 等发行版上直接用系统仓库装 Perl 模块可能版本不满足，checksetup.pl 会明确报出缺口与补装命令，按提示处理即可。

六、适用场景与限制

适用场景（结合官方定位与 Mozilla/Red Hat 等公开使用案例）：

  1. 成熟流程型缺陷跟踪：团队需要「提交 → 确认 → 修复 → 验证 → 关闭」的强流程工单流，且希望字段、状态、权限、通知全部可配置——Bugzilla 的状态机与组权限体系为此而生，bugzilla.mozilla.org（Firefox/Thunderbird 的官方缺陷库）二十余年的运行是其最大规模的背书。
  2. 大型组织的集中式缺陷库：Red Hat 长期运营 bugzilla.redhat.com 承载 RHEL/Fedora 的缺陷流程，并在其公开文档中维护定制版部署指引；多产品、多团队、海量 bug 的场景正是 Bugzilla 的设计原点。
  3. 合规与数据主权敏感环境：纯 Perl + 关系数据库、无第三方运行时依赖、MPL-2.0 许可，可完全离线自托管，适合内网研发管理。
  4. 需要开放工单入口给外部贡献者：开源项目把 Bugzilla 暴露给社区提交缺陷（如 GNOME、Wine 等项目的公开实例）是经典用法，其账号自助注册、确认流程、反垃圾参数体系完整。

限制与风险（同样基于官方事实）：

  1. 界面与交互传统：5.2 的 UI 仍是服务端模板渲染的传统形态，没有现代化 SPA 前端；对习惯新一代工单工具的团队有上手成本。
  2. 版本节奏缓慢：5.2（2024-09-03）之后无小版本更新记录，功能演进要等 6.0 线（trunk 5.9.1）；若团队把「活跃的新特性交付」作为硬指标，需要慎重。
  3. Perl 技术栈门槛：二次开发与深度排障需要 Perl 能力；Template Toolkit ≥ 3.008 的版本约束也抬高了在老系统上的部署摩擦。
  4. 简体中文本地化缺失：官方下载页的语言包列表包含繁体中文（zh_TW）但没有简体中文（zh_CN），中文团队需要接受英文界面或自行维护汉化模板。
  5. 报表图表依赖可选模块：图表能力依赖 GD/Chart 等 Perl 模块，默认最小安装不含，需额外安装（见官方安装文档的 Optional Modules 清单）。

七、同类选型对比

自托管缺陷跟踪/工单赛道上，与 Bugzilla 定位最接近的老牌开源竞品是 Redmine（项目管理 + 问题跟踪一体）、MantisBT（轻量缺陷跟踪）与 Trac（wiki + 工单 + SCM 集成）。下表给出关键维度对比，其中 GitHub 星数为 2026-10-27 经 shields.io 徽章（img.shields.io/github/stars/<owner>/<repo>.svg）读取的当日数值，其余事实以各项目官方站点与仓库为据。

维度BugzillaRedmineMantisBTTrac
定位专业缺陷跟踪/工单流程项目管理 + 问题跟踪一体轻量缺陷跟踪wiki + 缺陷 + 版本库集成
官方仓库bugzilla/bugzillaredmine/redmine（GitHub 为镜像，主仓在 redmine.org）mantisbt/mantisbtedgewall/trac
GitHub 星数（2026-10-27，shields.io）8666.1k1.8k546
服务端语言栈Perl（CGI/mod_perl）Ruby（Ruby on Rails）PHPPython
数据库支持MySQL/MariaDB、PostgreSQLMySQL/MariaDB、PostgreSQLMySQL/MariaDB、PostgreSQL 等SQLite（默认）、PostgreSQL、MySQL
许可证MPL-2.0GPL-2.0GPL-2.0BSD-3-Clause
当前稳定版与节奏5.2（2024-09-03；6.0 开发中，trunk 5.9.1）活跃开发，6.x 线进行中持续小版本维护（2.x 线）1.6.x 线，维护节奏缓慢
APIREST + XML-RPC + JSON-RPCREST APIREST API（SOAP 已弃用）XML-RPC（插件）
部署门槛Perl 模块依赖管理（checksetup.pl 自动化）Rails 应用， Ruby 环境管理PHP 应用，门槛最低Python 应用，较轻
二次开发语言门槛PerlRubyPHPPython
生态特色状态机/权限流程最完整，Mozilla/Red Hat 级验证全生命周期项目管理（甘特/看板/wiki）上手快、界面朴素与 Subversion/Git 深度联动

关键差异解读：

  • 星数与真实活跃度的错位：Redmine 的 6.1k 星明显高于其他三者，但其主版本库托管在 redmine.org，GitHub 仓库是官方镜像；MantisBT 与 Bugzilla 的 GitHub 仓库即主仓。因此星数横向比较时需打折扣看待，它反映「GitHub 生态关注度」而非全部社区规模。四个项目在查询当日均处于「有人维护」状态，但功能演进速度 Redmine 领先、Trac 明显最慢。
  • 流程严谨度：Bugzilla 的状态机、组权限、产品/组件绑定负责人模型是四者中最完整、最「研发流程导向」的；Redmine 偏项目管理全景；MantisBT 胜在简单直接；Trac 的强项是与版本库/wiki 的融合。
  • 运维栈匹配：团队现有运维技能直接决定隐性成本——Perl 运维经验稀缺是 Bugzilla 最常被引用的选型顾虑；反之若团队就是 Perl 技术栈（或接手了历史 Bugzilla 实例），5.2 的低依赖、低 schema 变更特性反而极友好。

「如果……则……」选型建议：

  • 如果团队需要的是纯粹、严谨、久经验证的缺陷跟踪流程（尤其多产品、多团队、有安全漏洞保密流程诉求），且能接受 Perl 栈与传统 UI——选 Bugzilla 5.2，它在这个细分定位上仍是最成熟的自托管方案。
  • 如果需要缺陷跟踪之外还要甘特图、看板、wiki、多项目费用与人力管理——选 Redmine，Bugzilla 不做项目管理。
  • 如果只想要一个几小时内能上线的轻量缺陷登记簿，团队规模小、流程简单——选 MantisBT。
  • 如果核心诉求是代码仓库与工单强联动（提交信息引用工单、浏览源码树）且项目规模小——选 Trac。
  • 如果目标是 6.0 的新架构（官方 trunk 5.9.1 正在开发中）——可评估跟踪 6.0 发布节奏，但生产环境当前仍应以 5.2 稳定线为准。

八、参考链接