干过开发的人都经历过这种场景：需求评审会上，你花一晚上画的流程图投到大屏上，产品经理扫了一眼说"这个流程不对"，测试说"异常路径呢"，老板说"太复杂了看不懂"。
然后你回去改，改完又被怼。来回三趟，流程图没定下来，开发周期先被吃掉一周。
流程图是所有技术文档里看起来最简单、实际上最容易翻车的一种。画得好的流程图，评审5分钟过；画得差的，评审两小时还在吵第一页。
干了十几年开发，画过的流程图少说几百张。踩够了坑之后，我总结了一套方法论，核心就六个字：分层、闭环、克制。
一、先搞清楚：你的流程图是给谁看的
这是最容易被忽略的一步。很多人上来就画，画完才发现受众不对。
流程图的受众分三种，每种看的东西完全不同：
给业务方看：重点在流程是否覆盖了所有业务场景，异常分支是否完整。技术细节一个字都不用写，节点名称用业务语言，比如"审核订单"而不是"调用auditService"。
给开发看：重点在系统交互和判断逻辑。需要标注接口名称、数据流向、异常处理路径。可以用技术术语，但每个节点的输入输出要写清楚。
给老板看：重点在核心链路和关键决策点。删掉所有细节分支，只保留主干流程，一张图不超过10个节点。老板要的是"这个业务怎么跑通的"，不是"每个接口怎么调的"。
真实教训：有次给CEO汇报，我把Kafka消费组的rebalance逻辑画进去了。CEO看了三秒说"你们自己定，我不关心这些"。那一刻我意识到，给错人看细节，比不给还糟糕。
二、分层画：别指望一张图搞定所有事
新手最常犯的错误：试图在一张图里表达所有细节。结果图画得密密麻麻，自己看着都头大，别人更看不下去。
正确的做法是分三层：
第一层：主流程骨架图。只画核心链路，从开始到结束，不超过15个节点。这张图的作用是让所有人30秒内理解"这个业务怎么跑的"。
第二层：角色协作泳道图。用泳道区分不同角色或系统的职责边界。比如支付流程：用户泳道、商户系统泳道、支付平台泳道，每个泳道里只放自己负责的节点。泳道图最大的价值不是"好看"，而是暴露协作盲区——两个角色之间的交接点，往往就是出bug的地方。
第三层：异常处理详图。把每个判断节点的异常分支单独展开。正常流程一张图，异常流程另一张图。混在一起画，图就废了。
经验法则：单张流程图的节点不超过30个，泳道不超过5条，嵌套子流程不超过3层。超了就拆。
三、判断节点：流程图里80%的争议都在这
判断节点（菱形）是流程图里最容易出问题的地方。我见过太多流程图，判断节点只标了"是/否"，连判断什么都没写清楚。
三个铁律：
第一，每个判断必须有明确的条件描述。不是写"金额判断"，而是写"金额是否超过1000元"。不是写"校验"，而是写"参数校验是否通过"。判断条件要具体到可以写成代码。
第二，每个分支必须有明确的出口。"是"走哪条路，"否"走哪条路，不能有悬空路径。我review过一张流程图，判断节点的一个分支画到一半断了，问开发"这里怎么处理"，他说"应该不会走到这"。后来线上就走到了，直接事故。
第三，异常分支不能偷懒。"理想路径"人人都会画，真正体现专业度的是异常处理。每个判断节点的失败分支都要有明确的处理动作：返回错误码、进入重试队列、触发告警、记录日志。不能只写"失败"然后就没有然后了。
四、连线和布局：看着不重要的细节，决定图的成败
连线交叉是第一杀手。一张图如果有三处以上连线交叉，基本就不可读了。解决办法：调整节点位置、使用折线代替直线、把交叉的分支拆到子流程里。
布局方向要统一。要么从上到下，要么从左到右，别混着来。主流程走中间，分支往两侧展开。节点间距保持一致，别有的挤一块、有的隔半天。
颜色只用来区分语义，不是为了好看。比如：蓝色=正常流程，红色=异常处理，绿色=自动任务，黄色=人工审核。颜色种类不超过5种，否则就变成彩虹了，反而干扰阅读。
节点文字控制在10-15个字以内，用"动词+名词"结构：提交订单、审核通过、发送通知。别写成长句，节点不是文档。
五、画完之后的自检清单
每次画完流程图，过一遍这5个问题：
- 有没有死循环？顺着箭头走一遍，看是否存在绕不出来的环。
- 有没有死胡同？每个节点是否都有后续路径，有没有走到一半断掉的。
- 异常路径是否完整？每个判断节点的失败分支是否都有处理动作。
- 角色职责是否清晰？泳道之间的交接点是否标注了传递的数据和触发条件。
- 非目标受众能否看懂主干？把细节分支折叠掉，只看主流程，一个不熟悉这个业务的人能否30秒内理解。
六、工具选择：够用就行，别花冤枉钱
画流程图不需要花哨的工具。如果你只是偶尔画图、一周用两三次，这些完全够用：
Draw.io：免费、开源、无广告，导出无水印。画流程图和架构图的首选，功能完整，没有付费墙。
Excalidraw：免费、手绘风格，适合早期方案讨论。手绘风格有个好处——看起来不正式，大家更敢提意见，不会觉得"图都画这么好了不好意思改"。
Mermaid Live Editor：用代码画流程图，写几行文本自动生成图。适合写技术文档时快速嵌入，GitHub的README直接支持。
如果你是重度用户、每天都要画图、需要复杂的团队协作功能，那花点钱开会员也合理。但大多数人，免费工具完全够用。
总结
流程图的本质不是画图，是思考。画图的过程，是你把模糊的业务逻辑变成清晰的步骤的过程。
一张好的流程图，应该做到：外行看懂主干，内行看到细节，测试找到异常，开发看到接口。
记住六个字就够了：分层、闭环、克制。分层是结构，闭环是逻辑，克制是审美。做到这三点，你的流程图一次过审的概率至少翻一倍。