一、本次改动的背景
上一篇里，我主要补了函数调用传播和作用域处理，让 SQL 注入检测不再只停留在函数定义本身，而是可以根据真实调用点的实参状态，继续进入函数体做分析。
这一轮没有新增新的漏洞类型，也没有大幅调整整体架构，而是继续沿着 SQL 注入这条主线，把检测结果里的“传播过程”记录得更完整一些。
之前后端已经可以输出source_line、sql_build_line、sink_line这类字段，能够说明用户输入、SQL 构造和execute(...)大概分别出现在哪几行。
但这些信息还是比较粗。它们能说明“风险发生在哪”，却不能完整说明“数据是怎么一步步传过去的”。对于后续 AI 解释来说，如果只拿到SQLInjection标签和几个行号，生成的解释就容易比较泛。
所以这次的重点，是先由后端把传播链事实记录清楚，再交给后续 AI 模块组织成用户能看懂的说明和修复建议。
二、新增 flow_trace 传播链
这次主要新增了一个结构化字段：
flow_trace它用来记录从 source 到 sink 的关键传播步骤。目前主要记录：
source assign function_call parameter_bind sql_build sink对于涉及返回值传播的场景，也会继续记录return相关步骤。
也就是尽量把下面这条链路记录下来：
用户输入 -> 变量赋值 -> 函数调用 -> 参数绑定 -> SQL 构造 -> execute 执行这里我没有选择在 B 阶段直接生成一大段中文解释，而是先保留结构化事实。因为 B 阶段更适合做静态分析和证据提取，比如哪一行识别到了用户输入、哪个变量被污染、实参绑定到了哪个形参、SQL 在哪里构造、最终在哪里进入execute(...)。
这些信息本身不一定适合直接展示给用户，但很适合交给后续 AI 解释模块使用。
三、传播链记录了什么
这次在后端新增了EvidenceStep，用来表示传播链上的一步。它大致记录：
kind line symbol from_symbol to_symbol function_name source_kind source_label source_selector sink_label sql_shape其中kind表示当前步骤的类型，例如source、assign、function_call、parameter_bind、sql_build、sink。
例如下面这段代码：
defrun_query(uid):sql=f"SELECT * FROM users WHERE id ={uid}"cursor.execute(sql)user_id=request.args.get("id")run_query(user_id)内部可以记录出类似这样的传播链：
source@5 -> assign@5 -> function_call@6 -> parameter_bind@6 -> sql_build@2 -> sink@3对应含义是：第 5 行识别到用户输入，并赋值给user_id；第 6 行user_id被传入run_query，并绑定到形参uid；第 2 行uid被拼接进动态 SQL；第 3 行 SQL 进入cursor.execute。
这样后端输出的结果就不只是“这里有 SQL 注入风险”，而是能把风险形成过程记录下来。后续 AI 可以根据这些步骤生成更自然的解释，例如说明用户输入如何进入函数、如何参与 SQL 构造、最后如何到达执行点。
四、和前端、AI 模块的关系
这里我做了一个边界区分。
flow_trace目前主要保留在 B 阶段的中间结果里，也就是：
RiskCandidate.flow_trace它主要服务后续 AI 解释模块和结果整理层。
最终返回给 VS Code 插件的RiskItem暂时不直接暴露完整传播链。因为前端当前更需要展示的是风险类型、风险说明、修复建议和最终解释，而不是底层的每一个传播步骤。
目前分工大致是：
B 阶段：记录结构化传播链 AI 解释模块：根据传播链生成解释和修复建议 前端插件：展示最终整理后的检测结果这样职责会清楚一些，也方便后续继续扩展。
五、测试情况与目前边界
这次补充了函数调用传播链相关测试，重点验证函数调用场景下能够记录：
source assign function_call parameter_bind sql_build sink运行命令为：
python-m unittest discover-s tests当前测试结果：
Ran 35 tests OK目前flow_trace主要还是服务 Python SQL 注入检测主线，已经可以覆盖普通变量传播、函数调用、参数绑定、返回值传播和executesink。
不过它还没有完整覆盖跨文件调用、类方法、对象属性、容器元素、高阶函数等复杂情况。这些后续可以继续通过补充新的EvidenceStep.kind或扩展字段来完善。
整体来看，这一轮改动不算大，重点也不是新增检测能力，而是让已有 SQL 注入检测结果更适合后续 AI 解释。之前后端更多是输出几个关键行号，现在则开始记录更细的传播链事实：
source -> assign -> function_call -> parameter_bind -> sql_build -> sink这样后续 AI 模块在生成漏洞解释时，就不需要只根据风险标签和行号进行推测，而是可以基于后端给出的结构化传播路径，生成更准确、更贴近代码实际执行过程的说明和修复建议。
