sys.sql_expression_dependencies 是唯一可靠入口，因其准确记录跨库跨schema引用，需过滤 referenced_class=1 并用递归cte展开嵌套链路，再结合 sys.dm_exec_describe_first_result_set 验证列有效性。
别用 sp_depends，它在 SQL Server 2016+ 已弃用，对嵌套视图返回空结果，查不到真实依赖链。
为什么 sys.sql_expression_dependencies 是唯一可靠入口
SQL Server 只有这个系统视图能准确记录对象间的引用关系，且支持跨库、跨 schema 引用。sp_depends 和 SSMS “查看依赖关系” 功能底层仍调用旧逻辑，遇到 WITH SCHEMABINDING 或动态 SQL 就漏报。
- 必须加
referenced_class = 1过滤——只保留表/视图/函数等用户对象，否则会混入索引、约束等干扰项 -
is_ambiguous字段为 1 表示存在同名对象（比如多个 schema 下都有v_base），需人工确认实际引用的是哪个 - 若
referenced_database_name不为空，说明是跨库引用，后续验证时必须把库名拼进查询字符串里，否则sys.dm_exec_describe_first_result_set会默认查当前库
怎么查清 v_report → v_summary → v_base 这种嵌套链路
单层查完只是起点，真正要还原完整路径得靠递归 CTE 向下展开，不能靠肉眼翻定义。
- 先跑基础查询：
SELECT referenced_entity_name, referenced_schema_name FROM sys.sql_expression_dependencies WHERE referencing_id = OBJECT_ID('v_report') AND referenced_class = 1 - 再用递归 CTE，关键条件是
WHERE d.referenced_class = 1和AND d.referenced_id IS NOT NULL，避免循环引用卡死 - 每层都要手动验证列是否存在：对
v_summary执行sys.dm_exec_describe_first_result_set(N'SELECT * FROM v_summary', NULL, 0)，检查返回列名是否匹配上层v_report的 SELECT 列表
查到依赖后，怎么判断列是否还有效
依赖存在 ≠ 列还能用。常见错误是基表字段被重命名或删掉，但视图仍能执行，只是返回 NULL 或运行时报错。
- 用
sys.dm_exec_describe_first_result_set第三个参数设为0（只解析不执行），能提前暴露列缺失或类型不兼容问题 - 如果视图用了
WITH SCHEMABINDING，那修改基表结构会直接失败，不用额外校验；但没绑定的视图就完全靠人工逐层核对 - 特别注意
SELECT *场景：一旦底层视图新增字段，上层视图会自动多出一列，可能破坏应用层字段顺序假设
嵌套超过 4 层时，递归 CTE 查询本身没问题，但人工验证成本陡增——这时候该想的不是怎么查得更全，而是要不要把中间层拆成物化视图或临时表，否则每次改一个字段都得重跑整条链。
