一、本次改动的背景

上一篇里，我主要补了函数调用传播和作用域处理，让 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。

例如下面这段代码：

def run_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 注入检测主线，已经可以覆盖普通变量传播、函数调用、参数绑定、返回值传播和 execute sink。

不过它还没有完整覆盖跨文件调用、类方法、对象属性、容器元素、高阶函数等复杂情况。这些后续可以继续通过补充新的 EvidenceStep.kind 或扩展字段来完善。

整体来看，这一轮改动不算大，重点也不是新增检测能力，而是让已有 SQL 注入检测结果更适合后续 AI 解释。之前后端更多是输出几个关键行号，现在则开始记录更细的传播链事实：

source -> assign -> function_call -> parameter_bind -> sql_build -> sink

这样后续 AI 模块在生成漏洞解释时，就不需要只根据风险标签和行号进行推测，而是可以基于后端给出的结构化传播路径，生成更准确、更贴近代码实际执行过程的说明和修复建议。