静态分析

静态分析指在不实际运行程序的情况下对其进行检查，与之对应的动态分析需要实际执行代码才能观测行为

AI辅助测试可以生成测试场景、总结执行轨迹、分析截图、识别日志可疑模式并推测失败原因，但诊断在工程师验证前仅是假设

GitNexus在构建知识图谱时执行多层次静态分析：语法层面通过AST解析，语义层面通过符号解析追踪跨文件引用，模块层面分析import/require/include依赖声明

自动化验证闸门应设计为“拦截并转人工复核”，而非无条件阻断，以避免因误报拖慢低风险改动。

传统代码审查和静态分析工具（如 linter）擅长发现语法错误、代码风格问题和模式化缺陷，但对运行时行为一无所知。

传统静态分析工具（如ESLint、SonarQube、Semgrep）在AI编程场景下面临新问题：AI生成的代码量远超人工编写速度，且风格与模式高度多样，基于人工规则的检查容易遗漏。

AI辅助代码审计和基于LLM的静态分析等中级应用处于早期落地阶段，效果因场景而异。

类型系统通过代数数据类型和不可变性等机制把部分运行时错误转化为编译期错误；静态分析则借助数据流分析和抽象解释发现空指针、资源泄漏等模式。

静态分析工具和运行时检测（如ThreadSanitizer）可以弥补并发模型的不直观之处。

契约可以作为静态分析工具的输入，即使运行时检查被关闭，工具仍可基于条件声明推断潜在的空指针解引用或数组越界。

契约对静态分析的增益不是免费的，前提是分析工具能确信契约在运行时会被真正检查或被当作不可违反，否则会出现误报或漏报。

运行时验证能捕捉静态分析无法发现的问题，如数据库事务死锁、消息队列重复消费、外部 API 超时后的状态不一致、并发下的竞态条件等。

打包器默认只会把能被静态识别为被引用的模块纳入产物；动态拼接的模块名、条件加载、插件运行时按需 import 的包，都可能被误判为未使用而剔除

由于评测不执行代码，静态分析通过的构建方案在运行时仍可能失败。

静态分析的优势是速度快、可复现、结果确定，不依赖沙箱环境；代价是无法发现运行时才暴露的问题，如类型错误崩溃、异步时序问题或特定版本下的 API 行为差异。

Deslop 这类工具通常需要在规则严格度和误报率之间做权衡：规则越激进，越能清理冗余，但也越可能把人类刻意写下的安全代码标记为问题。

静态分析工具在不运行代码的情况下，通过解析抽象语法树（AST）和构建数据流来发现潜在问题，其优势是快、可自动化，但代价是缺乏运行时上下文，容易产生误报。

静态分析无法检测 Agent 技能的 TOCTOU 攻击，因为被分析的内容不是被执行的内容，替换可发生在扫描和下一次调用之间

静态分析无需执行程序直接解析可执行文件指令序列，覆盖全部代码路径，但面对加壳、虚拟化保护时难度急剧上升

静态分析无法完整覆盖 AI 代理依赖运行时上下文的涌现行为，因此 SafeAI 是第一道防线而非完整的安全保证