PHP血缘分析必须用sql-parser等语法树解析器，而非正则；需结合php-parser处理变量流、人工标注动态SQL与存储过程，并统一跨栈字段命名以实现端到端血缘对齐。
PHP 本身不解析 SQL 血缘，必须依赖外部解析器；直接正则匹配 SELECT 或 FROM 字段会漏掉子查询、CTE、函数包裹等关键路径，血缘链必然断裂。
用 sql-parser 解析 SELECT 字段来源，别信正则
硬写 preg_match('/SELECT\s+(.*?)(?:FROM|$)/i', $sql, $m) 看似快，但遇到 SELECT COALESCE(u.name, '') AS name FROM users u 就无法识别 u.name 是源头，更别说嵌套 (SELECT id FROM logs WHERE user_id = u.id) 这类子查询。
- 必须用语法树还原字段真实归属：
sql-parser（GitHub 上活跃的轻量库）能把SELECT a.id, b.status FROM users a JOIN orders b ON a.id = b.user_id拆成明确映射：a.id → users.id、b.status → orders.status - 别名必须显式回溯：
FROM users u中的u不是表名，要查Identifier的getRealName()或getAlias()属性才能绑定到users - CTE（
WITH t AS (SELECT ...)）需递归展开，不能只扫顶层FROM；sql-parser目前不原生支持 CTE 展开，得手动遍历WithClauseNode并替换引用
PHP 脚本里的变量流怎么串起来
SQL 只解决「表→表」或「字段→字段」的静态依赖，但真实 ETL 链常是 $raw = db_query(...); $enriched = add_user_info($raw); $report = array_map(...) —— 这段逻辑在 AST 里根本没 SQL，sql-parser 完全看不见。
- 用
php-parser扫描 AST，重点捕获Expr_Assign（赋值）、Expr_FuncCall（函数调用）、Expr_ArrayDimFetch（数组取值），构建变量流向图 - 警惕引用传递：若函数内直接修改传入数组（如
function fill_status(&$row) { $row['status_text'] = map_status($row['status']); }），AST 里看不到字段新增，得靠人工注释// @propagates status → status_text补充 - 第三方封装（如 Laravel
collect()、ThinkPHPwith()）需单独建规则：例如识别$c->map(fn($x) => $x['amount'] * 1.1)并提取amount→revenue映射
字段别名和业务语义怎么对齐
报表层常做最后一层转换：formatStatus($row['status']) 返回 "已发货"，但血缘图若只记 status → status，下游就查不到真实语义。前端 JS 再加工（如 moment(row.created_at).fromNow()）更是完全脱离 PHP 血缘体系。
立即学习“PHP免费学习笔记（深入）”；
- 强制在 SQL 查询中加业务别名：
SELECT u.status AS order_status_code, format_status(u.status) AS order_status_text，让返回键名自带上下文 - PHP 函数需约定前缀打标：如
js:time_ago、ui:status_label，避免血缘系统把order_status_text当作原始字段 - 同一个字段在不同报表中含义可能冲突（如
orders.total在销售看板含税、财务看板不含税），血缘存储必须挂载上下文标签，不能只存source=orders.total
为什么视图和动态拼接 SQL 总是断点
CREATE VIEW v_user_orders AS SELECT u.name, o.total FROM users u JOIN orders o... 这种 DDL 里的依赖，sql-parser 能解析，但不会自动关联到 SELECT * FROM v_user_orders 的调用方——它不知道这个视图存在，更不会穿透到基表。
- 必须额外采集数据库的视图定义（如 MySQL 的
INFORMATION_SCHEMA.VIEWS或 PostgreSQL 的pg_views），并把视图 DDL 也喂给sql-parser做二次解析 - 动态拼接 SQL（如
"SELECT * FROM " . $table_name）彻底脱离静态分析能力，只能靠运行时日志采样 + 调度系统任务上下文补全（例如 Airflow 的task_instance.xcom_pull()获取实际表名） -
sql-parser不处理存储过程、触发器、PREPARE 语句，这些地方的血缘必须人工标注或跳过
字段级血缘真正的难点不在解析，而在跨栈语义对齐：SQL 里的 user_id、PHP 变量 $user['id']、模板中 {{ $user_id }}、前端 data-user-id，必须用统一命名规范或中间映射表串起来，否则每个环节都在“自说自话”。
