这个模板适合做什么
数据流图（DFD）展示数据在系统中的流动方式：数据从哪里来、经过哪些处理环节、存储在哪里、最终去往何处。与展示组件关系的架构图不同，数据流图聚焦于数据本身——使其成为理解系统行为、记录需求、发现数据泄露或损坏风险的核心工具。这个模板适用于系统分析、需求文档编写、安全审查以及帮助工程师快速熟悉现有系统。
适用场景
- 记录用户数据在 Web 应用中从输入到存储再到输出的完整流转过程。
- 分析业务流程，找出数据被重复录入、丢失或手动转移的环节。
- 在安全或合规审计前，梳理敏感数据的存储位置和传输路径。
- 向不懂技术架构图的利益相关方说明系统的工作方式。
- 为新入职工程师展示现有系统中数据的流转路径，帮助快速上手。
- 在建立数据管道之前，确定两个系统之间的集成点。
使用步骤
- 1识别所有外部实体——向系统发送或接收数据的人员、系统或组织。
- 2列出系统内所有对数据进行转换的处理过程。
- 3识别在处理过程之间持久化数据的所有数据存储。
- 4用带标签的箭头连接实体、处理过程和数据存储，每条箭头标注所传递的数据名称。
- 5检查每个处理过程至少有一个输入流和一个输出流。
- 6与团队共同审查，确认图表与系统实际行为相符。
简单示例
用户注册流程
相关资源
和相似工具的对比
数据流图 vs 系统架构图
系统架构图展示组件和基础设施，数据流图展示信息如何在人、流程、存储和系统之间流动。想说明“系统里有什么”用架构图；想说明“数据去哪了”用数据流图。
数据流图 vs 流程图
流程图关注步骤顺序和判断分支，数据流图关注输入、输出、转换和存储。如果问题是“下一步发生什么”，用流程图；如果问题是“这些数据流向哪里”，用数据流图。
上下文图 vs 一级 DFD
上下文图把系统看作一个整体流程，周围放外部实体；一级 DFD 展开内部流程和数据存储。先用上下文图确认边界，再用一级 DFD 给工程团队讨论细节。
常见误区
把软件组件当成数据流图节点
“React 应用”“Node 服务”更像架构图元素。在数据流图里，节点应描述数据发生了什么处理，例如“验证订单”“存储支付令牌”“发送确认邮件”。
箭头不标数据名称
没有标签的箭头只能表示方向。应标出真实负载，例如客户资料、支付令牌、订单事件、CSV 导出，这样评审者才能判断隐私和正确性。
漏掉数据存储
团队常画输入和处理，却忘了数据持久化在哪里。数据库、队列、日志、缓存、对象存储，才是保留周期、合规和回放问题发生的地方。
试图在一张图里展示所有字段
数据流图应展示有意义的数据包，而不是完整 schema。字段级细节如果重要，另接 ER 图或 schema 文档，不要把数据流图塞到不可读。
常见问题
数据流图应该包含什么？+
至少包含外部实体、处理过程、数据存储和带标签的数据流。每个处理过程都应有输入和输出，每条箭头都应说明传递的数据是什么。
什么时候应该画数据流图？+
当你需要弄清信息如何进入、变化、保存并离开一个系统时，就适合画 DFD。它特别适合需求梳理、安全审查、合规映射和新人上手。
数据流图和 ER 图一样吗？+
不一样。ER 图描述数据结构——实体、属性和关系；数据流图描述数据运动——数据从哪里来、怎么被处理、最后去了哪里。
DFD 应该画多细？+
先画上下文图，再只展开需要讨论的部分。一个实用标准是：如果干系人几分钟内看不懂，就应该拆成多个层级。
这个模板能用于安全审查吗？+
可以。标出信任边界、敏感数据存储和外部集成点。数据流图通常是发现加密、访问控制、日志和保留策略缺口最快的方法。
在线开始编辑
在 CodePic 中打开模板后，替换示例内容，很快就能整理成自己的版本。
