Traq 介绍与选型指南
Traq 定位、功能全景与维护状态溯源（含仓库地址勘误 nirix/traq），并与 MantisBT、Redmine、Bugzilla 量化对比，给出分场景选型建议；关键事实均标注来源与查询日期。
TraqTraqPHP 编程敏捷错误追踪2026/10/28
Traq 介绍与选型指南
目标：面向正在为小团队选型「自托管 issue 追踪 / 项目管理」方案的技术决策者，讲清 Traq 的定位、能力边界与维护状态，并给出与 MantisBT、Redmine、Bugzilla 的量化对比与选型建议。本篇为纯联网溯源篇（关键事实均标注来源与查询日期 2026-10-28），实测面（安装、配置、运维）由本系列其余三篇承接。
一、Traq 是什么
1.1 项目档案
| 项 | 事实 | 来源（查询日期均为 2026-10-28） |
|---|---|---|
| 定位 | 多项目、多里程碑的开源项目管理与 issue 追踪系统 | 官网首页 https://traq.io/ |
| 开发语言 | PHP（要求 PHP 8.3+） | 官方 README（GitHub 仓库） |
| 数据库 | MariaDB 或 MySQL；安装向导另提供 SQLite、PostgreSQL 选项（基于 PDO） | 官方 README；向导表单实测（本系列安装篇） |
| 许可证 | GPL-3.0（程序）；Avalon/Nanite 框架为 LGPL-3.0 | 官方 README 与仓库 COPYING |
| 官方仓库 | https://github.com/nirix/traq | GitHub API 实测 |
| 官网 | https://traq.io （自带演示站与官方缺陷跟踪 bugs.traq.io） | 官网导航 |
| 起源 | 2009 年由 Jack Polgar（nirix）发起的个人项目，目标是「不臃肿的自托管 PHP issue 追踪器」 | 官网 About 页 https://traq.io/about |
| 最新稳定版 | v3.8.6（2026-10-22 发布） | GitHub Releases API 实测 |
| 预发布线 | v3.9.0-alpha.3（2026-10-26，标记 prerelease） | GitHub Releases API 实测 |
| 维护状态 | 活跃：仓库最近推送 2026-10-27，v3.8.x 稳定线持续发版（v3.8.5 于 2026-10-21、v3.8.6 于 2026-10-22） | GitHub API 实测 |
| 社区规模 | 205 Stars / 29 Forks / 13 Watchers | GitHub API 实测 |
| 仓库话题标签 | issue-management、issue-tracker、multiprojects、php、project-management | GitHub API 实测 |
⚠️ 仓库地址勘误：部分旧资料引用的
traq-dev/traq已不存在（实测 GitHub API 返回 404），官方仓库以nirix/traq为准，官网 traq.io 的下载链接同样指向该仓库的 Releases。溯源时请勿采信失效地址。
1.2 维护状态结论
Traq 不属于停更项目：截至查询日期 2026-10-28，主分支前一天仍有推送、稳定版一月内连发两版（3.8.5→3.8.6）、v3.9.0 已进入 alpha 迭代。选型风险主要不在「弃坑」，而在社区规模小（三位数 Stars）——它的可持续性依赖原作者个人驱动，建议使用方保持「发布包 + 数据库」的规范化备份能力（本系列运维篇提供完整流程），以对冲上游节奏变化。
二、功能全景与技术画像
2.1 功能清单（安装即得，实测核对）
| 能力域 | 内容 |
|---|---|
| 工单管理 | 类型（Defect/Feature Request/Enhancement/Task）、状态（New/Accepted/Started/Closed/Completed）、优先级、严重度、组件、版本、指派、任务清单（checkbox）、投票、私有工单、批量操作 |
| 多项目 | 项目隔离的空间与 slug 路由（/项目slug/...）、项目级成员与角色权限、项目设置（里程碑/组件/成员/自定义字段/权限矩阵） |
| 里程碑与路线 | 里程碑（Roadmap）、变更日志（Changelog）自动汇总 |
| 知识与动态 | 每项目 Wiki（多版本修订）、项目时间线（Timeline） |
| 协作 | 订阅通知（项目/里程碑/工单三级，邮件推送）、Markdown 渲染（内置插件）、注册与邮件验证开关 |
| 定制 | 自定义字段（按项目）、工单模板（按类型）、AdminCP 站点设置（标题/主题/时间格式等 21 项） |
| 集成 | 内置 API（版本 1.1，覆盖类型/状态/优先级/工单列表/身份）、插件机制（内置 Markdown、Custom Tabs、Security Questions 三个） |
2.2 技术栈与资源画像
- 服务端：PHP 8.3+ 常规 FPM/Apache 部署，无队列、无后台常驻进程、无 CLI 工具；框架为作者自研的 Avalon（LGPL-3.0），依赖极简（Parsedown、Symfony Mailer 6.4、ramsey/uuid，实测 composer.json）。
- 发布形态：官方 Release 由 CI 构建，tar 包约 825 KB 且自带 vendor 依赖目录——部署不需要 Composer，也不需要 Node 构建，解压即用（本系列安装篇实测）。
- 数据库：默认 MySQL/MariaDB 单库 24 表；附件存储在库内（
traq_attachments.contents），无文件目录依赖，备份一个库即全量备份（实测表结构核对）。 - 前端：构建产物由现代前端工具链产出（assets 内带哈希文件名与 manifest），页面使用 Alpine.js 风格指令（实测 HTML）；官网 About 口径为 PHP + MariaDB/MySQL + Vue。
- 体量感受（实测）：安装向导跑完 24 张表；一份全量 mysqldump 约 29 KB（空载演示数据）；整套站点由 nginx + php-fpm + MariaDB 三个系统服务承载。
一句话画像：Traq 是「单二进制思维」的 PHP 应用——包小、依赖少、表少、无外部设施，运维面收敛到「一个库 + 一份配置目录」。
三、同类方案量化对比
对比对象选取三个同样支持自托管、以 issue 追踪为核心的传统方案：MantisBT（PHP）、Redmine（Ruby）、Bugzilla（Perl）。数据来源均为 GitHub API 实测（查询日期 2026-10-28），版本以各仓库最新标签/发布为准。
3.1 核心指标对比
| 指标 | Traq | MantisBT | Redmine | Bugzilla |
|---|---|---|---|---|
| 开发语言 | PHP 8.3+ | PHP | Ruby（Rails） | Perl |
| 最新版本（标签） | v3.8.6 | release-2.28.4 | 7.0.2 | release-5.3.3（5.2 为稳定分支） |
| 官方仓库 | nirix/traq | mantisbt/mantisbt | redmine/redmine | bugzilla/bugzilla |
| 许可证 | GPL-3.0 | GPL-2.0+ | GPL-2.0 | MPL-2.0 |
| GitHub Stars | 205 | 1,515 | 6,064 | 760 |
| 仓库最近推送 | 2026-10-27（活跃） | 2023-07-10（GitHub 同步滞后，发布以 mantisbt.org 为准） | 2026-10-27（活跃；GitHub 为主仓 SVN 的同步只读副本） | 2024-10-09（明显放缓） |
| 数据库支持 | MySQL/MariaDB、SQLite、PostgreSQL（PDO） | MySQL/MariaDB、PostgreSQL、MS SQL 等 | MySQL/MariaDB、PostgreSQL、SQLite 等 | MySQL/MariaDB、PostgreSQL 等 |
| 部署依赖 | PHP 8.3 + 一个数据库 + Web 服务器；发布包自带依赖 | PHP + 数据库 + Web 服务器 | Ruby + Bundler 依赖 + 数据库 + 应用服务器 | Perl + 一组 CPAN 模块 + 数据库 + Web 服务器 |
| 命令行工具 | 无（网页向导 + SQL 运维） | 有（CLI 升级等） | 有（rake 全家桶） | 有（checksetup.pl 等） |
| 通知邮件 | Symfony Mailer DSN（SMTP/sendmail） | 内置 PHP 邮件（支持 SMTP） | 内置邮件配置 | 内置（sendmail/SMTP） |
3.2 指标解读
- 活跃度：Redmine 与 Traq 当下都在正常迭代（最近推送同日）；MantisBT 的 GitHub 仓库数据停留在 2023-07（其社区版本发布集中在官网，评估时以官网发布记录为准）；Bugzilla 仓库两年未推送，处于明显低谷。
- 上手成本：Traq 的发布包自带依赖 + 网页安装向导，是四者中「从零到可用」步骤最少的（实测：装 LEMP → 解压 → 向导四步，全程无手工编辑配置文件）；Redmine 依赖 Ruby 生态，Bugzilla 依赖 CPAN 模组清单，MantisBT 居中。
- 功能纵深：Redmine 功能面最宽（甘特、跟踪标签、工作流、REST API 完整、生态插件最多）；MantisBT 以成熟的缺陷流程与插件市场见长；Bugzilla 胜在流程严谨与大规模实践（Mozilla 系）；Traq 覆盖「工单 + 里程碑 + Wiki + 时间线 + 订阅通知」的主干能力，深度功能（工作流引擎、跨项目视图、LDAP 等）不提供。
- 运维面：Traq 无 CLI 也意味着无脚本化运维入口——备份、恢复、升级全部是「SQL + 文件 + 网页向导」三件事（本系列运维篇已逐条实测）；这一面在 Redmine/Bugzilla/MantisBT 上都有对应 CLI 可用。
3.3 量化小结
| 你的场景 | 建议 |
|---|---|
| 小团队（≤50 人）要一个「装完就能用、平时不用管」的多项目工单站，技术栈是 PHP | Traq 合适：部署最轻，主干功能齐全，GPL-3.0 无采购成本 |
| 需要工作流定制、甘特图、LDAP/SSO、丰富插件生态 | 选 Redmine：功能纵深与生态最强，代价是 Ruby 栈的部署与升级成本 |
| 以缺陷管理为核心、需要成熟插件市场与多年生产验证 | 选 MantisBT（以官网发布与社区文档为准）或 Redmine |
| 需要超大规模、严格流程审计的缺陷库（继承 Mozilla 实践） | 评估 Bugzilla，但注意其当前迭代放缓，需自行评估长期风险 |
| 只想最快架一个内部缺陷墙、接受功能主干化 | Traq 或 MantisBT；若服务器无 PHP 环境则 MantisBT/Redmine 与 Traq 同样要装栈，差异不大 |
四、选型建议
- 把 Traq 当「轻量主力」用：它的设计哲学是克制——单库 24 表、附件入库、无 CLI、无队列。适合内部工具墙、开源项目官网配套缺陷站、小型外包项目组。
- 用之前先确认两个接受度：① 界面语言仅英语（v3.8.6 语言包实测仅 enus）；② 无移动端 App 与富客户端，协作靠 Web + 邮件通知。两者都不卡再进。
- 为小社区项目预留退路：在「规范备份 + 版本留档」上花十分钟（运维篇方案），即可把上游风险降到最低——Traq 的数据形态（单库）天然好迁移。
- 不要拿 Traq 做重型流程引擎：需要审批流、工作流编排、跨项目资源池的场景直接上 Redmine/OpenProject 级别的方案，避免二次开发过重。
本系列其余三篇给出完整的落地路径：安装见 《Ubuntu 22.04 安装 Traq 3.8.6 指南》，配置体系见 《Traq 3.8.6 配置参数详解》，备份升级与 API 运维见 《Traq 3.8.6 运维命令详解》。
章节目录