答辩现场最怕的一幕老师指着 PPT 上的时序图问这里为什么要多一次调用你答不上来。时序图是最容易被照着模板抄一张糊过去的图也是最容易被追问的图——因为它描述的是运行时的调用顺序抄来的图和你实际代码对不上一问就露。这篇用一套真实导出的4 张时序图讲清楚对象、生命线、消息、返回这四样怎么标以及哪些地方最容易被扣分。一、时序图回答什么和流程图的区别时序图流程图视角对象之间怎么互相调用业务按什么顺序走横轴时间自上而下步骤顺序纵轴参与的对象判定与分支回答“谁调用了谁、传了什么、返回什么”“先做什么、什么情况下走哪条路”同一件事两张图讲的是不同层面。以系统登录为例流程图讲的是输入账号 → 校验 → 成功进入主页 / 失败提示重试时序图讲的是页面 → 控制层 → 服务层 → 数据层各自在第几步被调用、返回了什么。对照着看更清楚——同一套系统里登录流程的流程图长这样而时序图长这样对象视角二、时序图的四要素一张合格的时序图只需要四样东西缺一个都会被问要素画法常见错误对象参与者顶部方框从左到右排列把数据库和表都当对象图变得又宽又乱生命线对象下方的竖虚线漏画生命线只剩箭头悬空消息调用实线箭头 方法名自上而下只写调用不写方法名与参数返回虚线箭头 返回值把返回和调用画成同一种线本项目导出的时序图统一按这个规范对象名、方法名、返回线都是分开的所以打印出来能直接进设计文档。三、4 张时序图分别讲什么这套系统里一共 4 张时序图分工很清楚序文件讲什么适合放哪1系统时序图全局骨架一次请求经过哪些层答辩 PPT 第 2–3 页2单位级别-时序图一条典型业务的完整调用设计文档「系统实现」章3地区-时序图带上下级关系的业务处理设计文档体现复杂度4需求信息-时序图涉及多表写入的核心业务答辩时讲核心功能怎么实现为什么不是每个实体都画一张因为时序图的价值在讲清一次典型交互不是穷举。4 张足够覆盖通用骨架 简单业务 层级业务 复杂业务。画 12 张反而没人看。第二条业务的调用链四、三个高频扣分点调用不写方法名箭头只写调用服务等于没画。写listByPage(dto)这种真实方法名才叫时序图。没有返回线只有去没有回读图的人不知道数据从哪来。返回用虚线标清返回类型。层次不对应代码图上写页面直接调数据库而你的代码里明明有 service 层——这是答辩最容易被抓的矛盾点。画之前先对着代码确认调用链。五、答辩时的答题结构老师可能问建议怎么答为什么这里要分两步调用先讲职责校验与写入分开便于复用与事务控制再讲影响这个返回为什么要包装一层统一返回结构前端只处理一种格式异常也能统一兜住时序图和流程图有什么区别一个是对象视角、一个是业务视角本文第一节那张表可以直接用这张图画的是哪个功能明确说出对应的方法名与页面避免图上一套、代码一套六、自查清单画完对一遍每个对象都有生命线每条消息都写了方法名调用用实线、返回用虚线图上的层次顺序和实际代码一致一张图不超过 5 个对象超了就拆至少有一张图能讲清核心功能的完整链路七、说实话的部分本文的 4 张时序图来自一份真实导出连同 48 张系统图一次产出你可以对着自己的代码核调用顺序。时序图是初稿对象、方法名、调用顺序按系统结构生成了但你要核对是否与你的实现一致——尤其是自己改过 service 拆分的地方。别为了凑图数量给每个实体都画时序图4 张讲清楚比 12 张没人看强。一句话总结时序图不是流程图的另一种画法它讲的是对象之间怎么调用把对象、生命线、消息、返回四样标全并保证和代码一致这张图就从抄来的变成能答辩的。