架构分析图这事儿，架构十个人里有九个画成了“方框加箭头”。分析剩下的架构那一个，画出来的分析东西能让人一眼看懂系统怎么转，数据往哪儿流，架构谁依赖谁，分析挂了谁影响谁。架构

差别不在工具，分析在思路。架构

我见过最离谱的分析一张图，是架构把微服务架构画成了蜘蛛网——三十多个小方框，互相之间全是分析线，颜色还分了七八种。架构画的分析人得意，看的架构人崩溃。那图除了证明系统复杂，什么也没说清楚。

真正有用的架构分析图，是让人看完能回答三个问题：系统里有什么？它们怎么协作？最脆弱的地方在哪儿？

先别急着打开画图软件。拿张白纸，把系统里最重要的东西列出来。注意，是“最重要的”，不是全部。一个支付系统，核心是订单、账户、支付网关、风控，别的都是配角。你要是把日志服务、短信通知也画上去，图就脏了。

画图的第一原则是分层。不是画得像蛋糕那样一层层摞起来，而是按职责切。客户端一层，网关一层，业务服务一层，数据存储一层。每层之间用粗箭头表示主流程，细虚线表示异步或次要依赖。这样谁看都知道请求从哪儿进来，最后落在哪儿。

有个技巧我用了五年，特别好使——用颜色表达状态。绿色是稳定模块，黄色是有待优化，红色是已知风险点。别搞图例，直接在图上标。人脑对颜色的敏感度远高于形状，一眼扫过去就知道该盯哪儿。

别画完美图。画完第一版，拿给同事看，问他“你觉得哪儿会先出问题”。如果对方指的地方和你标红的地方不一样，那你的图没画到点子上。架构图的真正价值不是展示现状，而是暴露问题。

举个我自己的例子。去年给一个电商后台画分析图，画到订单服务依赖库存服务时，发现库存服务又反向调用了订单服务查用户地址。一个循环依赖，平时不显山露水，大促一忙起来就死锁。那张图让我省了一次凌晨三点的故障排查——这就是画图的意义。

工具选择上，别纠结。PlantUML写代码生成图适合严谨派，Excalidraw手绘风适合头脑风暴，draw.io最通用。但说实话，用熟了哪个都行，关键是别让工具限制你的表达。我见过用PPT画得比专业软件还清晰的，也见过用Visio画得跟迷宫似的。

最后提醒一句：架构分析图是“活”的。系统改了，图就得跟着改。别让它成为墙上的装饰品，那是另一种形式的文档腐烂。

画图不难，难的是想清楚再画。你脑子里如果一团浆糊，画出来的图就是浆糊的具象化。反过来，画图的过程本身也在逼你理清思路——这就是为什么老鸟总说，画不出图，就是没想明白。