简介：这是一份基于QT框架实现甘特图功能的可运行源码，面向希望掌握QT图形视图框架与自定义可视化组件的C++开发者。源码共12个文件，以5个.h头文件、4个.cpp实现文件为主体，辅以.pro工程配置和txt说明，压缩包仅14KB，头文件负责任务结构等声明，实现文件承载绘制与交互逻辑，工程文件可直接用qmake构建，体量虽小但模块完整，适合逐行精读。项目围绕甘特图的绘制与交互展开：利用QGraphicsView/QGraphicsScene渲染任务条，通过QDateTime处理任务起止时间，并由任务结构类管理名称、时长、优先级等数据；代码还包含添加/修改任务的对话框控制、事件处理与视图布局，清晰展示了数据模型、绘图逻辑和界面刷新之间的协作。目前已有3096人学习该资源，可用于快速理解QT自定义控件及项目管理可视化的落地写法，是入门Qt Graphics View框架的不错参考。
1. 方案选型：为什么我最终放弃了QTableWidget和QCustomPlot
做Qt界面开发的人，早晚会撞上甘特图这个需求。项目排期、任务调度、资源分配，凡是带时间维度的管理类软件，几乎都逃不过那一根根横条。但你翻遍Qt官方控件库，会发现一个尴尬的事实：Qt压根没有原生甘特图控件，QTableWidget只能画表格画不了条，QCustomPlot主要是折线散点图，硬拿来画甘特图等于用菜刀削铅笔，能削但非常别扭。
我最早尝试过两条弯路。第一条是用QTableWidget做底，在单元格里嵌入QLabel或者QProgressBar模拟任务条，拖动滚动条时对不齐，单元格高度一变任务条就错位，最后放弃。第二条是尝试用QCustomPlot的CPBars叠加坐标轴，但甘特图需要的是水平横条加时间刻度，还要支持任务拖拽、缩放、依赖关系箭头，QCustomPlot对这些交互需求支持得很弱，强行改造代码反而更复杂。
最终稳定下来的方案是QGraphicsView + QGraphicsScene体系。这套方案的本质是把甘特图拆成“表格区”和“图形区”两个部分：左侧任务列表用QTableWidget或QTreeView承载，右侧时间轴和任务条用QGraphicsView绘制，两个区域同步滚动。QGraphicsView天生支持缩放、拖拽、碰撞检测，任务条的选中、移动、拉伸、连线都有现成的机制，不需要像自绘控件那样自己处理鼠标命中和重绘。这套架构用了快两年，客户提了七八次需求变更，大到任务条拖拽回写数据库，小到周六周日列背景变色，都能在不推翻底层的前提下完成扩展。
2. 核心数据结构与时间刻度换算
2.1 任务节点的数据建模
甘特图的数据顶层是任务，任务之间还有前后置依赖关系。我的数据类设计分三层：Project管理整个项目，Task描述单个任务，Dependency描述任务之间的连线。Task里除了任务名、开始时间、结束时间这些明面上的字段，还有个容易踩坑的设计点——状态字段不能只有一个枚举，至少要拆成“计划状态”和“实际状态”两个。做项目排期图时，计划开始时间是排程依据，实际开始时间是跟踪依据，两者混在一个字段里，后续做拖拽调整时根本不知道拖的是计划还是实际。
依赖关系这块，用两个Task ID加一个关系类型枚举就够了。关系类型只保留最常用的四种：完成到开始（FS）、开始到开始（SS）、完成到完成（FF）、开始到完成（SF）。实际开发中95%的场景都是FS关系，也就是前一个任务干完后面才能开工。连线绘制时不需要真的在这种数据模型里做拓扑计算，只要根据两端任务的坐标画箭头即可，真正的关键路径计算属于排程引擎的范畴，甘特图控件只负责展示。
2.2 时间与像素坐标的换算逻辑
时间轴和像素的换算关系是甘特图最核心的逻辑。我的做法是定义一个TimeScale类，内部维护一个像素宽度（比如每像素代表多少秒）。换算公式很直白：x轴坐标 = (时间戳 - 项目起始时间戳) / 秒每像素。反向换算同理：时间戳 = 项目起始时间戳 + x坐标 * 秒每像素。
这里有个细节必须提前处理——时间的对齐问题。甘特图的时间轴通常按天或按周显示刻度，如果项目起始时间是某个周三的下午2点，第一列起点对齐到周三的日期线上，那么“1月1日”这个刻度显示的其实是1月1日0点，但第一条任务从下午2点才开始，画出来就空出半格。我的做法是建立“时间轴零点”，即把项目起始时间向下取整到当天0点，所有换算都基于这个零点，任务自身的起始坐标再偏移实际时间与零点之间的秒数。这样时间轴刻度才能正好落在每天的0点线上，语义才正确。
缩放功能就是调整秒每像素这个系数。我用鼠标滚轮控制，滚轮上滑放大，系数变小；下滑缩小，系数变大。缩放锚点放在鼠标当前位置，这个交互细节很关键——用户预期是“鼠标指向哪里，哪里就放大”，所以缩放时要保持鼠标下方的任务条不动。实现方式是缩放前记录鼠标位置对应的时间戳，缩放后重新计算这个时间戳应该所在的屏幕位置，然后调整Scene的滚动偏移量。
2.3 表格与图形区联动滚动
表格区用QTableWidget，图形区用QGraphicsView，两个控件同步滚动是甘特图组件里最磨人的问题。直接给两个控件绑定同一个滚动条信号不行，因为表格是纵向滚动，图形区是横向滚动时间轴加纵向滚动任务条，滚动方向不一样。
我的方案是把两个控件放在一个QWidget里，外面套一个QVBoxLayout管理表头，中间放一个独立的QScrollBar，分别连接表格的垂直滚动条和图形区的垂直滚动条。具体逻辑是：当用户滚动表格时，把滚动值同步到图形区；滚动图形区时，再同步回表格。中间用一个互斥锁标志位防止信号互相触发导致死循环。这条代码虽然只有几行，但实际开发时必须把“正在同步”的标志位放在类成员里而不是局部变量，否则快速拖动滚动条时会出现抖动回弹。
3. 图形区绘制实现：任务条、依赖线和时间轴
3.1 任务条Item的绘制细节
任务条我用QGraphicsRectItem的子类实现，继承后重写paint事件。看似简单的矩形，要画出专业感需要处理几个细节。首先是任务条的三维凸起效果，左边和上边用浅色边，右边和下边用深色边，这样看起来像凸起。任务条颜色按类型区分，普通任务用蓝色系，里程碑用菱形表示，摘要任务用深色加粗条覆盖子任务范围。进度状态在任务条内部画一层半透明前景色，完成度越高，前景色越靠近右边。
任务条高度我固定设置为28像素，上下留出间隔防止相邻任务条视觉粘连。行高设置太矮会导致文字显示不全，太高又浪费空间，28像素搭配12像素字体实际使用下来视觉密度最合适。
文本绘制要适应不同缩放级别。完整模式下显示任务名称加时间段，缩小到一定程度后只显示任务名称，再缩小就只显示一个纯色条。这个分级显示机制能避免时间轴缩小到月视图时，任务条里挤满了密密麻麻的文字变成一幅“色块图”。判断阈值用当前秒每像素值除以任务总时长得到一个“可用像素数”，小于30像素就切到下一级显示。
3.2 依赖连线的智能路由
依赖连线用QGraphicsPathItem实现。最简单的画法是两个任务条边缘之间直接拉一条直线加箭头。但实际项目里任务A在顶部、任务B在底部，中间还隔着其他任务条，直线会穿过遮挡区域，视觉上非常乱。我用了一个极简但有效的“两段式连法”：从源任务右侧中心出发，先水平向右走出一定距离，再垂直向下走到目标任务条左侧的垂直中心，最后水平向左接入目标任务条左边缘。也就是走一个L形的路线。
这个固定L形其实有局限。如果目标任务在源任务的左上方，L形路线会穿过整个界面。后来我升级成了“避让式算法”：计算两个任务的垂直中心点，如果目标在源的下方，就向下走出拐点；如果在上方，就向上走出拐点。拐点位置始终保持在时间轴当前可见范围之外，也就是固定从任务条右侧边缘先向右延展80像素再转折。实际效果在绝大多数场景下能绕过其他任务条，毕竟用户不会同时让几十条任务挤在一个可见区域里。
依赖线还承担了一个隐性功能——任务拖拽时的动态约束提示。当用户拖动一个任务导致依赖关系冲突（比如把前置任务的结束时间拖到后置任务的开始时间之后），依赖线会立即变为红色，同时弹出一个tooltip提示“当前拖动将导致XX任务的开始时间早于其前置任务的结束时间”。这个功能用QGraphicsItem的hover事件和数据校验函数配合完成，预先加载所有依赖关系到QHash映射表中，每次拖拽都会增量检查受影响的相邻任务，而不是全量扫描界面上的所有任务，实测1000条任务规模下拖动几乎无延迟。
3.3 时间轴与网格背景的绘制方案
时间轴区域我不放在Scene里，而是放在一个自定义的ViewportWidget顶部固定层上。原因是甘特图的表头时间轴需要跟随水平滚动条滚动，但不能跟随垂直滚动条滚动，如果直接画在Scene中，垂直滚动时表头会跟着任务条一起上下移动，观感很差。所以我拆成两个QGraphicsView共享同一个Scene：上方的时间轴视图只显示表头，关闭垂直滚动条并固定高度；下方的任务视图显示任务条，两个视图水平同步滚动。
时间轴分级策略分三层：最上层显示年份和季度，中间显示月，最下层显示日和周的刻度。刻度间隔根据当前秒每像素值动态计算：当每像素小于3600秒（1小时）时，最下层显示小时刻度；介于一小时到一天之间时，显示天刻度；大于一天则切换到周刻度。每级刻度都要做“刻度值取整对齐”，比如天刻度要从当天的0点开始，周刻度从每周周一开始，否则刻度线会歪歪扭扭不在整点上。
网格背景用QGraphicsScene的背景画刷实现，每层刻度对应一组淡色网格线。这里有个性能坑要提醒：Scene的背景绘制会随缩放频繁触发重绘，如果每次都在paint里计算整个时间范围的网格线，缩放时会卡顿。正确做法是只绘制当前可见矩形区域内的网格线，不可见的刻度线全部跳过。实现时需要把sceneRect的可见矩形传给绘制函数，然后根据时间轴的像素跨度反向计算可见区域覆盖的刻度范围，只在这个范围内画线。
4. 交互操作实现：拖拽、缩放与关键路径高亮
4.1 任务条拖拽调整的功能实现
任务条交互动作分三类：拖拽移动整条任务（改变开始和结束时间）、拖拽左边缘（只改开始时间）、拖拽右边缘（只改结束时间）。实现关键是鼠标命中区域的判定，我用的是QGraphicsItem的shape()和多边形检测——任务条中间的80%区域返回一个可拖动移动的矩形，左右各10%区域返回一个宽度为10像素的竖条形状作为缩放手柄。鼠标光标样式在进入这些区域时分别切换为SizeAllCursor和 SizeHorCursor。
拖拽过程中要做两级校验。第一级是基础校验，不能拖到项目开始时间之前、不能拖到项目结束时间之后、开始时间不能晚于结束时间。第二级是依赖关系校验，遍历当前任务的所有前置和后置依赖。一个提升体验的技巧是：拖拽时显示黄色tooltip实时展示当前新时间段，如果校验失败改成红色；释放鼠标时若校验仍然失败，恢复原时间并让任务条弹性回弹，而不是直接拒绝拖动让用户一脸懵。这个回弹动画效果用QPropertyAnimation基于任务条的rect属性实现，200毫秒内从错误位置缓动回正确位置，用户对这个反馈的接受度非常高。
4.2 时间轴缩放与快速定位的配合
时间轴的缩放交互上一节已经提到了坐标换算逻辑，这里补充UI层面的细节。除了鼠标滚轮缩放，我还实现了键盘快捷键操作：按住Ctrl键加鼠标滚轮也是缩放，这个和普通滚轮滚动区分开，避免用户在平移时间轴时误触缩放。另一个高频操作是“自适应全览”，一键将时间范围扩展到覆盖所有任务，同时把左侧任务列表滚动到顶部。实现方式是遍历所有任务的开始时间和结束时间，取出最小值和最大值，计算总时间跨度，然后把时间轴零点调整到最小值所在天的0点，秒每像素设置为总时间跨度除以图形区可见宽度的值。
定位功能还有一个隐藏需求：当用户点击任务列表中的一行时，图形区要自动滚动到该任务条的所在位置并居中显示。这个功能看上去简单，但有个细节是如果任务条在当前滚动范围内就不需要滚动，否则每次点击列表都闪烁跳动。判断方式是先获取任务条在Scene中的坐标，再用mapFromScene转换成视图坐标，判断这个点的y坐标是否落在视图可见矩形内，如果落在外面上方就往上滚，落在下方就往下滚，落在外面的都不用处理，只滚动Y方向，X方向保持不动。
4.3 关键路径识别的实现思路
关键路径高亮是项目管理类软件的“装逼功能”，需求方总爱加一句“把关键路径标出来”。严格来说关键路径算法（CPM，Critical Path Method）属于排程引擎范畴，不属于甘特图控件的展示职责，但纯粹做展示也需要一个算法。我的轻量实现思路是：遍历所有任务节点，找到没有前置依赖的任务作为起点，用递归深度优先遍历的方式计算从起点到每个任务节点的最长累计工期（前置任务结束时间加上当前任务的持续时间）以及每个节点的最早开始、最晚开始时间，两者相减得到总时差。总时差为零的任务构成关键路径。
这个算法的时间复杂度是O(N+E)，N是任务数，E是依赖边数，1000个任务的规模下毫秒级就能出结果。计算出关键路径后，将这些任务条的颜色替换成深红色，右侧添加一个感叹号图标，鼠标悬停时显示浮层解释“该任务位于关键路径上，延期将影响整体项目交付时间”。要注意的是：算法结果要缓存在内存里，只有当任务时间、依赖关系发生变化时才重新计算，不能每次绘图都跑一遍。后续如果要支持多项目多里程碑的复杂排程，建议直接集成专业的排程引擎而不是自己从头写。
5. 常见问题排查与性能优化实录
5.1 高频问题：表格滚动和图形区滚动不同步
这个问题现象是用户拖动表格滚动条时，图形区的任务条不跟着移动；或者反之，图形区滚动了，表格行没跟上。绝大多数原因是两个控件各自的滚动条范围不一致导致的。表格行高之和通常等于图形区任务条总高度，但如果任务条Item有额外的边距（比如为了处理依赖线，我把每个任务条的scene坐标加上了20像素的垂直间距），两者的滚动范围就对不上了。排查方法很简单：分别输出表格的垂直滚动条最大值和图形区的垂直滚动条最大值，如果数值不一致就需要统一。我的统一方式是计算图形区所有任务条Item的boundingRect并集高度，再加上上下各留50像素的边距得到一个总高度，然后把这个高度用作表格的scrollAreaWidgetResize逻辑中的固定行高总和，而不是分别取两边的最大高度再求平均值。
另一个容易忽略的坑是：在Linux下某些风格的QScrollBar存在“滚动步长不一致”问题，手势滑动和鼠标拖拽的步长不同，导致信号值虽然同步了但两边相差几个像素。解决方式是同步时用setValue(value)而不用setSliderPosition(value)，并显式调用updateGeometry刷新。至少在Qt 5.15的默认Fusion风格下，这个方法是稳妥的。
5.2 性能优化：任务条上千条的卡顿问题
任务量到5000条以上，QGraphicsView就会开始吃力，拖拽时画面掉帧明显。优化思路有几个层次。第一层是减少Item数量——把不可见的任务条Item不加入到Scene中，而是根据当前视口显示范围动态创建和销毁Item。这需要重写View的scrollContentsBy和resizeEvent事件来触发可视范围变化通知，然后在Scene的子类里维护一个“任务列表”的Hash表，判断每个任务的时间范围是否与当前可视时间段相交。这个方法最立竿见影，实测5000任务从明显的卡顿变为流畅拖拽。
第二层是减少绘制开销——任务条Item的paint函数里，涉及时间格式化字符串的操作（比如toLocalTime、toString）是最耗CPU的，不要每次paint都调用。正确做法是把显示文本缓存在Item的成员变量中，只有时间发生变化时才重新生成。第三层是在放大缩小过程中，受控地跳过动画重绘。具体来说：缩放过程中（按下Ctrl键加滚轮），将View的viewport层级设为NoViewportUpdate，缩放结束时再设为MinimalViewportUpdate并调用一次update()刷新整个画面。实测这个方案即时代码量不大，但对平滑度的提升非常明显。
5.3 一个容易忽视的bug：跨天任务的时间计算
有个客户报过一个问题：任务开始时间是前一天23:00，结束时间是第二天凌晨2:00，任务条画出来只有1个小时的长度。排查后发现是时间戳转换成QDate再转换回时间戳时，时区信息丢失了。原因是任务开始时间用QDateTime存储，在赋值时我用了toStartOfDay()来对齐零点，但这个函数会丢失时区偏移，导致跨天任务的时间戳被错误地当成当天0点再往后推了1小时。
修复方法是所有时间计算统一使用UTC时间戳存储，仅在绘制时间轴刻度、显示tooltip时才转换为本地时区的时间文本。甘特图内部的所有计算（开始时间、结束时间、时长）全部用时间戳秒数，只有显示时格式化字符串，这样从根本上避免跨时区、跨天引起的各类边界问题。
我在实际项目里还额外给任务条增加了一个“跨天标记”，当任务跨天时，在任务条中间画一条竖向的虚线作为视觉提示。这样用户不用鼠标悬停查看详情，一眼就能看出这条任务跨越了午夜。这个细节提得非常小，但是客户演示时专门点名称赞过，算是投入产出比很高的一笔改动。 ## 1. 方案选型：为什么最终是QGraphicsView而不是QTableWidget或QCustomPlot
先说结论：Qt官方原生根本没有甘特图控件，想在Qt里做甘特图，基本只有三条路——自绘控件、QTableWidget硬模拟、用第三方绘图库扩展。我第一次做甘特图时选了QTableWidget方案，把每个单元格塞进一个QProgressBar来模拟任务条，结果滚动联动、缩放、拖拽全是硬伤，维护到第二版就彻底推翻重写了。后来又试过QCustomPlot，它做曲线图确实强，做甘特图需要拿CPBars强行横向堆叠，坐标轴、拖拽逻辑全部要自己绕，代码写到最后比自绘还复杂。
最终长期稳定下来的方案是QGraphicsView + QGraphicsScene体系。这个方案的本质是把甘特图拆成“表格区+图形区”两部分：左侧任务列表用QTreeWidget，右侧时间轴和任务条用QGraphicsView的Scene来承载。QGraphicsView天生就处理好了鼠标命中检测、拖拽、碰撞、视图缩放这些底层交互，做任务条的拖动、进度条拉伸、依赖关系连线时，基本只需要关心业务数据，不需要像自绘控件那样自己算重绘区域和更新矩形。左侧表格和右侧图形区通过共享滚动条和QSignalMapper做同步，这个架构跑了两三年，后续加什么里程碑标记、资源泳道都没有推翻重来。
选型时还有一个必须考虑的隐藏因素：甘特图大概率要叠加“缩放时间轴”这个交互。自绘控件遇到缩放时，所有坐标换算都要手工维护，而QGraphicsView的scale机制天然支持视图层缩放，配合把时间轴刻度做成可缩放的ItemGroup，实现成本和维护难度都低一个量级。如果你是刚接手这个需求，我的建议很直接：在QGraphicsView上做扩展，别去碰自绘控件和表格模拟两条弯路。
2. 核心数据结构与时间刻度换算
2.1 任务节点的数据模型
甘特图的数据核心是任务节点，但它绝不只是“开始时间、结束时间、名称”这三个字段就能撑起来的。我设计的数据类叫TaskNode，字段包括任务ID、任务名、计划开始时间、计划结束时间、实际开始时间、实际结束时间、进度百分比、前置任务ID列表、所属分组、任务颜色、任务类型。其中“类型”字段很重要，它区分普通任务、里程碑任务和摘要任务。里程碑任务在图上是一个菱形而不是横条；摘要任务是一根粗条，它的时间段由子任务聚合得到，不直接编辑但可以折叠展开。
前置任务ID列表是用来画依赖连线的，理论上是多对多关系，一个任务可以同时依赖多个前置任务。实际业务里最常见的是完成-开始（FS）关系，也就是前置任务结束后后置任务才能开始。这个约束我用一个DependencyRule列表维护，每个规则记录前置任务ID、后置任务ID、关系类型和延迟天数。延迟天数用于表示“前置完成后3天再开工”这类需求，解析规则时直接加到后置任务的实际开始时间上即可。
任务数据上来就用QDateTime存储绝对时间点，不要用字符串“2025-03-14”这样的格式。原因是甘特图要做时间轴的缩放平移换算，用时间戳秒数做加减运算最方便，字符串格式一次QDateTime::fromString的开销在大量任务重绘时会被放大得非常明显。
2.2 时间与像素坐标的换算逻辑
甘特图所有绘图都建立在一个基准公式上：像素坐标 = (时间戳 - 项目起始时间戳) * scaleFactor。scaleFactor表示每毫秒对应的像素数，或者反过来定义每像素代表多少时间，两种定义都行，关键是全项目统一。
我的实现是维护一个TimeScale类，内部保存projectStart（项目起始时间戳）、pixelsPerDay（每天多少像素）。把pixelsPerDay作为核心参数，因为日期刻度换算最直观。例如当前视图每天对应50像素，那么某个任务第3天08:30的x坐标就是：(3243600 + 83600 + 3060) * (50.0 / 86400)。反向换算同理，鼠标点击位置对应的日期时间 = projectStart + x / pixelsPerDay * 86400 秒。
这里有坑必须提前说：直接用毫秒时间戳换算会碰到“时区偏移”或“夏令时”问题。处理方式是把时间全部对齐到UTC0时区存储换算，只在显示时间文本时才转换到本地时区，不然中国时区的8小时偏移会让所有任务在一天的坐标上偏移三分之一，很隐蔽很难查。
缩放功能直接修改pixelsPerDay的值即可，滚轮上滑放大时pixelsPerDay变大，下滑时变小，改完马上重新计算所有Item的pos和boundingRect，再update()整个视图。但缩放时还要锁定“鼠标光标下对应的时间点”，否则缩放后时间轴会乱跳。具体做法是：缩放前记录鼠标场景坐标对应的那个时间戳，缩放后让这个时间戳仍然落在鼠标场景坐标所在的位置，也就是调整视图滚动条的位置做补偿。这段逻辑虽然只有几行，但用起来体感差异极大，不做的话每次缩放都像在滑冰。
2.3 表格与图形区联动滚动机制
甘特图最常见的布局是左侧表格固定宽度显示任务名，右侧图形区显示时间轴和任务条，两者共用纵向滚动。这个联动的隐藏难点在于：QTreeWidget和QGraphicsView各有自己的滚动条，直接同步数值往往会因为行高不一致导致错位。
解决方法是给两侧的行高定死一个常量，比如TASK_ROW_HEIGHT = 40像素。表格用setRowHeight逐行设置，图形区在计算每个任务Item的y坐标时也使用这个常量：y = rowIndex * TASK_ROW_HEIGHT。这样两边的滚动条范围就完全一致了，同步时直接一个setValue就能对上。
实际代码中我封装了一个LinkedScrollArea组件，它持有一个QScrollBar作为主滚动条，左侧表格和右侧图形区都连接到这个滚动条上。连接的核心是setValue同步，在表格的verticalScrollBar valueChanged信号里调用图形区视图的verticalScrollBar setValue，图形区滚动时同理反向同步。注意同步时要用QSignalBlocker或者一个布尔标志位防止信号递归循环触发，不然两个滚动条的valueChanged互相触发会卡顿。
3. 图形区绘制实现：任务条、时间轴和依赖线
3.1 表格区的行高、列宽和缩进设计
左侧表格我用QTreeWidget承载，因为它天然支持分组和嵌套，摘要任务和子任务的层级展示最直观。列设计为四项：任务名称、开始时间、结束时间、负责人。任务名称列要设置较大权重，其他列宽度固定，这样窗口拉宽时优先扩展名称区域。如果业务中还有进度百分比展示需求，可以在名称列后面放一个自定义委托画一个微型的进度条，不要直接在单元格里塞QProgressBar控件，控件数量一多刷新成本会很高。
行高固定和上节提到的TASK_ROW_HEIGHT保持同一个常量。QTreeWidget的setRowHeight默认会考虑字体和图标，所以要在设置完所有列之后再统一调用setRowHeight(0, 40)——只对顶部列设置即可，因为子项行高和父项是同一个模型。缩进原则是最多两级，一级摘要，二级具体任务，层级太深在甘特图渲染上非常不友好，用户看图时也没有耐心展开三层以上。
3.2 时间轴的刻度分级与绘制方法
时间轴的好坏直接决定甘特图的专业度。我按缩放级别把时间轴分成四档：当日视图、周视图、月视图、年视图。每个视图下，主刻度线和次刻度线承担的职责不同。当日视图中主刻度显示小时，次刻度显示半小时；周视图中主刻度显示星期，次刻度显示每天；月视图主刻度显示月份，次刻度显示每周；年视图主刻度显示年份，次刻度显示每月。
在绘制时，我把整个时间轴做成一个单独的QGraphicsItemGroup，放在Scene的顶层，y坐标固定为0。绘制逻辑是遍历当前可视时间范围（由视图映射的可见场景矩形反推），按刻度间隔计算每个刻度线的x坐标，然后drawLine画竖线，drawText画刻度文本。时间刻度文本要格式化成“MM-dd”或“HH:mm”这种简洁格式，不要显示的过于冗余，不然画面会像打翻的调色盘。
缩放级别切换的判断用一种自适应策略：根据当前pixelsPerDay值落在哪个区间就自动选用对应的时间轴级别。这样用户不需要手动切换视图，直接滚动缩放就能无缝过渡到不同密度的时间轴。这个交互细节做完之后，客户反馈“这个东西特别有专业软件的感觉”。
3.3 任务条Item的绘制与样式定制
任务条是核心视觉元素，我用QGraphicsRectItem的子类TaskBarItem来表示。它的paint函数里要画出：任务矩形背景、进度填充、任务名称文本、时间范围文本（可选）、以及左右两端的圆角。背景颜色根据任务类型和当前状态区分——进行中的任务用蓝色渐变，已完成的任务绿色，延期的任务红色。进度填充就是矩形内部再画一个宽度按进度百分比缩放的颜色区域，这样做视觉上比覆盖一个半透明图层更清晰。
文字在任务条内部的绘制要处理宽度不够的情况：计算任务条的像素宽度，如果能够容纳任务名称的字体宽度，就绘制名称文本；宽度不足时省略号截断，或者干脆不画文本只画一个色块。我在实际项目中就遇到几十个紧挨着的短任务条，如果每个都硬画名称，整个画面全是重叠的黑色像素，根本没法看。
每个TaskBarItem还要在构造时绑定TaskNode数据，把它存在item.data()里或直接写在成员变量中，方便点击时快速反查业务数据。这比用一个QMap用item指针做映射要靠谱得多——删除Item时不需要额外清理map，QGraphicsScene会自己管理item的生命周期。
3.4 依赖连线的绘制与箭头方向
依赖连线我单独用一个DependencyLineItem继承QGraphicsPathItem。连线是从前置任务条的右侧中心点到后置任务条的左侧中心点，期间按需要途经节点的路径。如果只是简单画一条直线，遇到任务条重叠或跨距很大时，线会穿过其他不必要的矩形区域，视觉非常混乱。所以我用了B样条曲线，控制点设置在两个端点中间偏上一点，让连线呈自然的拱形绕过中间区域。
箭头方向总是指向后置任务。绘制时用QPainterPath的moveTo、lineTo先在端点处理出一个箭头形状，然后在paint事件里fillPath填充。这里的逻辑和QGraphicsLineItem不同，一定要把箭头也做进Item的shape()函数里，否则点击箭头区域时Item不会命中，选择交互就会缺失。
依赖连线的更新策略：当任务条移动时，连线两端的端点跟着移动。最稳妥的方法是连线Item不存固定的端点坐标，而是在paint时实时从关联的TaskNode数据里读取任务条的最新矩形位置，计算出新的路径。千万不要在任务条move事件里去手动update连线Item的坐标，那样会产生海量的信号连接和更新调用，性能损耗很大。
4. 交互操作实现：拖拽、缩放与任务编辑
4.1 任务条的拖拽移动与时间更新
甘特图区别于普通图表的最大特性就是任务条可以直接拖拽。实现思路是：为TaskBarItem重写mousePressEvent、mouseMoveEvent、mouseReleaseEvent。按下时记录按下点的场景坐标和任务原始起止时间；移动时根据当前场景坐标反算对应的时间戳，算出时间偏移量；释放时把偏移后的时间写回TaskNode，并触发数据保存回调。
拖拽的自定义光标提示也很关键。当鼠标悬停在任务条中间区域时显示SizeAllCursor表示可移动；悬停在任务条左边缘或右边缘时显示SizeHorCursor表示可拉伸调整开始时间或结束时间。判断“边缘区域”可以在mouseMoveEvent里根据局部坐标判断，小于8像素视为边缘，否则是中间区域。
拖拽过程中要实时更新任务条的绘制位置，我采用的方式是直接在move事件里调用update()，然后用item->setPos重新定位。但要特别提醒一个坑：TaskBarItem在Scene里的坐标是相对于它的parentItem的，如果直接挂在Scene顶层，坐标就是场景坐标，这个没问题；如果挂在一个容器Item下，那坐标就全乱了。最简单的方式就是所有任务条都直接addItem到Scene上，逻辑简单，也方便后续做碰撞检测。
4.2 时间轴的缩放与原点的保持
缩放逻辑在第三节提到过核心实现，这里补充几个细节：滚轮事件的触发范围要限定在图形区View上，不要在表格区域也绑定缩放，不然用户滚动表格时时间轴也跟着变，体验很怪。缩放等级要限制在一个合理区间，比如pixelsPerDay最小为10（一年缩放视图）最大为2000（小时级视图），超出范围直接return，不然缩放过大会导致浮点运算误差堆积，坐标线错位。
还有一个可视化细节：缩放过程中，视图的SceneRect要动态扩展。QGraphicsView默认的sceneRect是固定的，如果放大的时间范围超出了原本的sceneRect，内容会被裁剪掉，反而不如自绘控件灵活。解决办法是重写View的scrollContentsBy和resizeEvent，每次视图尺寸或滚动位置变化时计算当前可视时间范围，把sceneRect的左右边界放宽到可视范围外各扩展一天的距离。这样滚动和缩放时永远留有缓冲。
4.3 双击编辑、进度调整和右键菜单
任务编辑我用“双击进入编辑态”的交互：双击任务条区域弹出一个轻量对话框，让用户修改任务名称、起止时间、进度百分比等核心字段。这里不值得做一个特别复杂的Dialog，直接在鼠标位置附近放一个QLineEdit或者QSpinBox，编辑完成按回车写入即可。甘特图工具的定位是辅助排期，不是完整的项目管理软件，编辑体验做轻做快比大方美观更重要。
进度调整的快捷方式是Ctrl+右键拖动：按住Ctrl不放点击任务条，上下拖动调整进度百分比。过程提示沿用tooltip或者状态栏，显示“进度已调整为65%”。这个交互看起来不起眼，但在实际给项目排期同事用的时候，反馈最好用的就是这个小功能，因为不需要打开任何编辑窗口就能把某个任务的完成情况快速改掉。
右键菜单我放四个选项：编辑任务、添加前置任务、删除任务、添加子任务。这里要注意菜单弹出的位置要映射到全局坐标，QGraphicsScene的contextMenuEvent是场景坐标，需要先用 view->viewport()->mapToGlobal()转换才能用QMenu::exec弹出，否则菜单会出现在完全错误的位置。这个坑我在第一版实现时实实在在踩过。
5. 常见问题与排查技巧实录
5.1 高频问题：任务条和表格行错位
表格行与图形区任务条的y坐标总是对不上，这是联动架构里最常见的问题。要么任务条比行偏上，要么偏下，而且随着滚动条上下滑动越来越明显。排查几乎都是行高不一致导致的。QTreeWidget的默认行高是字体高度加内边距，如果你桌面缩放比例是125%或者150%，字体渲染默认DPI变化，QTreeWidget计算出的行高可能不是整数，或者和你手动设置的TASK_ROW_HEIGHT对不上。
解决方式是不依赖setRowHeight，而是给表格也设置一个自定义itemDelegate，在sizeHint里强制返回QSize(列宽, TASK_ROW_HEIGHT)，同时设置verticalHeader的defaultSectionSize等于同一个常量。这样保证每个可能的渲染路径都使用同一个行高常量，杜绝内部计算偏差。另外注意Windows和Linux的DPI设置不同，这个代码要放在程序启动早期统一设置Qt::AA_EnableHighDpiScaling策略，不能假设不同环境下的缩放系数一致。
5.2 性能问题：上千条任务的卡顿优化
任务数量达到几百条时，如果还每秒都在update，加载就会明显卡顿。QGraphicsView的Item数量和重绘频率直接决定性能。优化方案有几个层次。
第一层是减少无谓更新：业务数据没变化的内容不要重建Item，拖动滚动条时触发的是视图渲染而不是Item数据重算。建议把时间轴文本的绘制缓存起来，只有缩放级别变化时才重新生成，滚动时只做平移，避免重复格式化时间字符串这种高成本操作。
第二层是使用Item的自绘优化：在TaskBarItem的paint函数里，避免创建QPen、QBrush等临时对象，把它们作为成员变量缓存。避免在paint里做字符串格式化，而是把要显示的文本提前算好存进一个QString成员。如果任务名称在早期就能确定，就把文本宽度也提前计算缓存。
第三层是加载策略上的优化：启动时不要一次性把所有TaskBarItem全部创建并addScene，而是先根据当前可视时间范围只创建可视区域附近的Item，滚动过程中再动态创建新进入视野的Item、销毁离开视野的Item。这本质上是虚拟化，3000条任务的情况下不需要同时存在3000个Item，可视区域内一般只需要几十个。这个优化幅度最大，QGraphicsView虽然本身有裁剪优化，但要接纳3000个Item本身就不划算，达到一万条任务时这个策略就成了刚需。
5.3 数据处理：跨天、多级分组和依赖校验
跨天任务的处理主要涉及时间的零点和边界。每天的时间范围是[0点, 24点)，画任务条时段的计算要按“结束时间 - 开始时间”得到秒数，换算成像素宽度。如果结束时间和开始时间相同，要按最小宽度绘制（比如至少画8像素），否则用户会因为条太窄而看不到任务存在，甚至鼠标点不中。
多级分组时摘要任务的时间范围是子任务的最小开始时间和最大结束时间。摘要任务条绘制在父级行上，如果摘要任务的起止时间和子任务重叠时，给摘要条设置半透明样式，让子任务的条透出来，视觉上能直接看到树形结构的时间分布。数据变化时摘要的样式必须同步更新，这个刷新是最容易遗漏的，每次子任务拖拽完成后要去刷新它的父级摘要条和信息面板。
依赖校验方面，拖拽一个任务导致它的后置任务时间被“提前”时，我建议不自动联动移动后置任务，而是在拖拽完成后弹一个确认框提示“该任务提前将影响以下任务的开始时间，是否同时平移？” 默认建议是“仅修改当前任务”，因为排程软件里自动连串改动的行为很容易让用户觉得失控。如果将来要支持联动排程，建议用拓扑排序遍历依赖图，确定影响范围，而不是简单的递归修改。
6. 扩展方向：从甘特图到资源视图和里程碑标记
6.1 资源泳道和人员负载展示
甘特图做到后面，客户十有八九会提“我要看资源冲突”。资源泳道就是按人分组，每个人一行，他的任务都显示在同一行上。这个改动对现有架构来说不算伤筋动骨——只要把任务Item的y坐标从“按索引排列”改成“按负责人分组后的组内索引”来排列，再把左侧表格也改成按负责人分组树形展示。真正的难点在人员负载计算：每一天内，某个人员的所有任务并行的时间段不能重叠，重叠就需要提示冲突，并提供把重叠任务自动平移到空闲时间的支持。
我做过的方案里，资源冲突检测是从每个任务的实际开始时间到结束时间，按天遍历任务占用情况，存进一个QHash<QDate, QList<TaskNode*>>。遍历完所有任务后，对同一天的列表做两两区间重叠检测。检测出来后在这些任务条上方画一个红色的波浪线或感叹号标志，告诉用户这里有冲突。自动平移不是必须实现的，大多数业务场景用户只需要你指出冲突，他自己会去人工调整。
6.2 里程碑标记和依赖线自动更新
里程碑任务在数据模型里的特征是duration=0，也就是开始时间和结束时间相同。绘制时用菱形取代矩形条，大小建议16x16像素。菱形在时间轴上的定位是他的时间点对应x坐标居中。里程碑上的文本可以显示在菱形上方，不占用任务条的宽度空间，样式更加干净。
依赖线在任务条移动后自动更新，这个功能是甘特图交互体验的加分项。实现方式是在TaskBarItem的itemChange方法中监听ItemPositionChange事件，位置变化后更新和它关联的所有DependencyLineItem的路径。DependencyLineItem的路径本身是实时计算的，前面提到过更新时从TaskNode读取最新位置，所以这里只需要在TaskBarItem移动结束后调用所有相关连线Item的update()。不要监听鼠标move的每一帧都做这件事，改成在mouseReleaseEvent时统一刷新一次就足够了。
6.3 导出与打印适配
甘特图的价值不只局限于屏幕展示，项目汇报时经常要导出成图片、PDF，或者打印出来贴到白板上。导出图片比较简单：QGraphicsScene的render函数配合QImage直接渲染整个Scene，设置合适的分辨率即可。但直接渲染会面临超级宽的时间轴和大量的Items，一次渲染大图像会爆内存或超时，需要按页渲染然后拼接。
打印适配要处理好缩放比例：A4纸横向打印时，甘特图的宽度可能是纸张宽度的好几倍，直接print会缩成一片模糊。我的做法是把时间轴拆成多个连续页面，每页显示一个固定时间跨度的区间，按页循环打印，顶部每一页都重新画时间轴表头。这个方案实现不算复杂，但能解决90%的项目汇报需求，追加这个功能后客户很少再提“导出PDF显示太小”的反馈了。
甘特图这套架构做了这么多轮需求，最深的体会是：不要一开始就把甘特图控件定义成一个小控件，要把它定义成一个可扩展排期图形平台。数据模型、时间缩放、Item体系、联动机制这四个核心部分搭好之后，后续所有花活——资源泳道、依赖校验、里程碑标记、导出打印——都只是在这个骨架上填充不同形态的Item和交互逻辑。如果一上来就想着“先用表格把任务列出来再说”，后面每扩展一个功能都要推翻一次重写，那才是真正被甘特图拖入了泥潭。
本文还有配套的精品资源，点击获取
