声明：本文仅为思想脚手架推演，不具备直接现实落地能力，不可替代硬件安全兜底。如有现实落地需求，请使用者自行综合评估、考量全部安全风险，自行承担全部相关责任。
本文是「空圈容错」系列的代码层落地篇。此前系列文章已将 CMP-D 应用于 BEV 感知、LLM Agent、ROS2 机器人场景，本文则从 Python 源码层面，用 SAST 工具对真实开源项目进行容错缺陷初筛。
摘要：本文介绍一款单文件 AST 表层 SAST 初筛工具【空圈 CMP-D】，不追求漏洞终审，聚焦软件容错、异常收容反模式、代码维护负担，对 Django、PyTorch、TensorFlow 三大工业级 Python 项目做统一口径横向扫描，挖掘不同框架在异常捕获编码习惯上的显著差异；同时讲解工具设计思路、实测数据、源码来源、工具边界与局限性。
目录
- 背景：为什么需要专门面向「容错」的轻量初筛工具？
- 工具介绍：空圈 CMP-D 单文件 SAST 初筛原型
- 检测规则设计（PY 系列容错反模式 + 复杂度维护负担指标）
- 实验环境与扫描口径说明
- 三大框架实测扫描结果 & 画像解读
- 重点高危文件人工抽样核验方案
- 工具短板与客观边界（非常重要，避免过度夸大）
- 工具源码使用教程、命令示例
- 总结与后续迭代计划
1. 背景：为什么需要专门面向「容错」的轻量初筛工具？
市面上成熟 Python 静态分析工具非常多：Ruff、Pylint、Radon、Bandit、Semgrep、SonarQube。
但现有工具存在一个现实缺口：
- Ruff/Pylint：侧重语法规范、PEP8 规范，虽然可以检测裸 except、BaseException，但不会把「except-pass 静默吞异常」作为核心规则；
- Radon：只计算圈复杂度、函数行数，不关心异常容错编码；
- Bandit：主打安全漏洞（注入、硬编码密钥），完全不关注异常收容、重试配置；
- Semgrep：可以写自定义规则，但需要维护规则库，没有原生支持多项目批量扫描 + 横向画像对比；
- SonarQube：重型平台，需要部署数据库、Java 环境，无法单文件开箱即用。
核心痛点：缺少一款轻量、开箱即用，专门聚焦【软件容错风险】的初筛工具，用来批量扫描多个开源大项目，输出容错风险画像做横向对比。
我们这套「空圈 CMP-D」L1 原型工具定位非常清晰：
定位：容错风险初筛工具，不是漏洞审计终审工具。输出风险候选池，告警不等于 bug，必须人工复核，用来快速把大项目里面高嫌疑代码捞出来，交给人二次确认。
【砍三刀·降档声明】 （工具内置强制输出）第一刀（归纳谬误）：检测器发现问题 ≠ 必须修复 → 仅生成候选，人工确认
第二刀（概念窄化）：结构问题 ≠ 仅复杂度超标 → 策略含增强收容/引入冗余
第三刀（范畴错误）：CMP-D 评分提升 ≠ 代码质量提升 → 仅反映容错性维度
2. 工具介绍：空圈 CMP-D 单文件 SAST 初筛原型
版本 ：kongquan_cmpd_allinone_v1_rev3_7.py（代码质量精修版）
核心特点：
- 单文件 All-In-One，SAST 模块零第三方依赖 ：SAST 扫描模块只依赖 Python 标准库
ast，拿到.py脚本直接运行；- 注：整体脚本含可选依赖------算子评估模块需
torch，配置扫描 YAML 解析需pyyaml；缺失时对应子命令自动降级，不影响 SAST 主功能；
- 注：整体脚本含可选依赖------算子评估模块需
- 基于 Python AST 抽象语法树表层模式匹配；
- 内置
batch批量子命令：一次性扫描多个项目，输出 CSV 横向汇总表； - 告警自动捕获源码片段 snippet，JSON 导出携带上下文；
--quiet汇总模式：大项目扫描优先输出统计汇总，不会被几万行明细刷屏；- 告警自动分级三区：高置信度 / 需人工判断 / 维护负担，报告顶部给出分级统计；
- 报告末尾自动给出抽样建议：告诉用户从哪里开始复核；
- snippet 智能回溯 ：except 类告警回溯到
try:行，展示完整的 try-except 块（Rev3.7 已加固为行首精确匹配，避免误停在注释/docstring）； - 支持配置扫描、算子评估、多域模拟器（配套 CMP-D 容错理论，本次实验主要使用 SAST 源码扫描模块）。
成熟度：L1 设计原型，仅 AST 表层扫描，无数据流分析、无跨文件分析。
Rev3.7 修复记录（相对 Rev3.6，代码质量精修）：
- 清除
write_csv_summary中的死代码 ：原为writer = csv.DictWriter(csv_path and f, ...) if False else csv.DictWriter(f, ...)的恒假分支混淆写法，简化为csv.DictWriter(f, fieldnames=headers)； try:回溯改为行首精确匹配 ：原为if anchor_keyword in lines[i]子串匹配，会误停在含try:字样的注释/docstring；改为startswith("try:")/startswith("try :")，回溯锚点准确落在真正的 try 语句行；- 配套
verify_rev37.py回归验证脚本：覆盖 CSV 写入与try:精确匹配两项修复，后续迭代可直接跑脚本确认修复未被破坏。
Rev3.6 修复记录（相对 Rev3.5）：
- snippet 上下文默认 2 → 5 行；
- except 类告警（PY000/PY001/PY001-BE）的 snippet 向上回溯到
try:行，让用户看到完整 try-except 块； - 告警分级分区输出：高置信度区（PY001-BE/PY002/PY003）+ 需人工判断区（PY000/PY001）+ 维护负担区（FUNC-LEN/NEST-DEEP），顶部给出分级统计；
- 报告末尾自动给出抽样建议：分三级优先级，指导用户高效复核；
- 明细里每条告警末尾追加
<<< 高置信度或<<< 需复核标记。
Rev3.5 修复记录（相对 Rev2）：
- 全部 emoji 降级为 ASCII 标签，消除 Windows GBK 控制台崩溃源；
- config 扫描后缀白名单扩展：增加
.properties/.java/.go/.env/.xml/.ini/.cfg； - GitLab CI 判定改用
yaml.safe_load做 job 级扫描，消除单行匹配误报； batch子命令报告输出到_cmpd_reports/，不再污染 benchmark 根目录；main()开头做 stdout 编码兜底；- 文件读取由
errors="ignore"改为errors="replace"，防止字节丢失导致行号错位； - 源码内容读到内存后复用，避免重复读盘；
- GitLab CI job 是 list 时增加防御。
3. 检测规则设计
分为两大类别：容错反模式 ERROR 规则 、维护负担 WARNING 复杂度指标。
ERROR｜容错反模式（异常收容风险）
| 规则 ID | 规则含义 | 风险说明 |
|---|---|---|
| PY000 | except XXX: pass 定向捕获异常后直接 pass 静默吞异常 |
捕获异常直接丢弃上下文，故障会被无声掩盖，排查困难 |
| PY001 | 裸 except: 广谱捕获全部异常 |
无差别捕获所有异常，包含 KeyboardInterrupt Ctrl-C、系统退出 |
| PY001-BE | except BaseException: 捕获基类异常 |
显式拦截系统终止异常，会导致程序无法正常 Ctrl-C 退出 |
| PY002 | @retry 无括号 / 缺少 stop 终止策略 |
tenacity 重试装饰器没有终止条件，死循环风险 |
| PY003 | @retry 重试配置拦截系统终止异常 |
重试逻辑捕获 KeyboardInterrupt 等，无法终止 |
| PY004 | @retry 缺少 wait 退避策略 |
无退避疯狂重试，引发重试风暴 |
WARNING｜维护负担指标（不等于 bug，代表维护风险升高）
| 规则 ID | 规则含义 |
|---|---|
| FUNC-LEN | 函数行数 > 50 行，函数过长 |
| NEST-DEEP | 代码嵌套深度 > 4 层，嵌套过深 |
说明：函数长、嵌套深不等于代码有 bug；但这类代码出现异常收容疏漏的概率显著提升，属于维护负担风险候选。
补充说明：本次三大框架扫描结果中，PY002/PY003/PY004 重试相关规则命中为 0；原因是三个项目业务源码几乎没有引入 tenacity 库，少量 retry 使用仅存在于被排除的 tests 测试目录中；该组规则适合扫描大量使用 tenacity 的业务项目，本实验数据集无法体现该规则效果。
4. 实验环境与扫描口径说明
实验环境
- Python 版本：Python 3.10+（本次实测环境以实际运行终端为准；推荐 3.10/3.11/3.12 稳定版本）
- 工具 ：空圈 CMP-D
kongquan_cmpd_allinone_v1_rev3_7.py
源码来源说明
本次实验所用 Django、PyTorch、TensorFlow 源码下载自 Gitee 社区镜像组（mirrors） 同步的 GitHub 上游开源仓库快照副本，属于真实工业级开源项目源码，并非人为编写的模拟 Demo 脚本。镜像存在同步时间差，评测结果仅代表该次下载快照的代码状态，不代表项目未来版本，也不代表这些项目官方 GitHub 仓库当前状态。
被测对象
- Django（完整仓库主业务源码）
- PyTorch（
torch/模块业务源码） - TensorFlow（
tensorflow/python/模块业务源码）
⚠️ 粒度说明 ：三者扫描范围粒度不同 ------Django 是完整仓库，PyTorch 和 TensorFlow 是其核心业务子目录。因此横向对比的绝对告警数仅供参考 ，不可作为严格等量对比。本文更侧重观察三者在异常捕获编码习惯上的差异，而非绝对数量。
统一扫描口径
- 仅扫描
.pyPython 源码；C/C++、CUDA、头文件全部跳过； - 仅完整文件夹名称等于
tests/test才排除整个文件夹； test_util、testing这类名字带 test 的业务文件夹全部保留扫描；*_test.py测试文件（文件，不是文件夹）不会自动过滤，全部参与扫描，需要人工区分业务代码和测试用例；- 使用
--quiet汇总模式，输出统计汇总； - 不启用
--exclude额外过滤，全部使用工具内置默认过滤策略。
补充 ：扫描 TensorFlow 源码时控制台会输出若干 SyntaxWarning 非法转义序列警告，该警告来源于 TensorFlow 项目自身源码字符串写法，并非本工具脚本缺陷，不影响告警统计结果，可以直接忽略。
⚠️ 复现实验避坑提示（重要） ：PyTorch、TensorFlow 官方源码压缩包解压后会生成双层同名外壳文件夹，Django 不会。正确路径如下：
| 项目 | 正确扫描路径 |
|---|---|
| Django | ./django-main（单层） |
| PyTorch torch | ./pytorch-main/pytorch-main/torch（双层） |
| TensorFlow python | ./tensorflow-master/tensorflow-master/tensorflow/python（双层） |
扫描命令示例
powershell
# 单项目扫描
python kongquan_cmpd_allinone_v1_rev3_7.py sast ./django-main --quiet
# 批量扫描多个项目输出 CSV 汇总
python kongquan_cmpd_allinone_v1_rev3_7.py batch ./benchmark --quietRev3.7 回归验证说明
Rev3.7 的两处代码修复（死代码清除、try: 精确匹配）已通过配套的 verify_rev37.py 回归验证脚本确认；同时以 Rev3.7 脚本重新扫描三大框架，六项核心指标（ERROR/WARNING 各三项）与 Rev3.6 完全一致 ，证明代码质量修复未引入新增误报或漏报：
| 项目 | 指标 | Rev3.6 | Rev3.7 | 结论 |
|---|---|---|---|---|
| Django | ERROR / WARNING | 189 / 544 | 189 / 544 | ✅ 一致 |
| PyTorch | ERROR / WARNING | 337 / 5695 | 337 / 5695 | ✅ 一致 |
| TensorFlow | ERROR / WARNING | 220 / 3266 | 220 / 3266 | ✅ 一致 |
说明：回归验证建议使用命令行重定向将完整报告写入文件（见第 8 节编码避坑），避免 PowerShell 窗口行数上限导致输出被截断、数字漏读。
5. 三大框架实测扫描结果 & 画像解读
完整统计总表
| 指标 | Django(main) | PyTorch(torch) | TensorFlow(tensorflow/python) |
|---|---|---|---|
| ERROR 总数 | 189 | 337 | 220 |
| WARNING 总数 | 544 | 5695 | 3266 |
| 告警合计 | 733 | 6032 | 3486 |
| PY000 except-pass | 187 | 283 | 177 |
| PY001 裸 except | 0 | 8 | 42 |
| PY001-BE BaseException 捕获 | 2 | 46 | 1 |
| FUNC-LEN 函数过长 | 395 | 4552 | 2793 |
| NEST-DEEP 嵌套过深 | 149 | 1143 | 473 |
数据验证说明 ：以上 21 项核心指标已通过 kongquan_cmpd_allinone_v1_rev3_7.py 本地复现，与初次扫描结果（Rev3.6）完全一致，并经 verify_rev37.py 回归验证确认。
各项目容错风险画像解读
5.1 Django
ERROR=189，WARNING=544，总告警 733。
工具自动分级：
- 高置信度（PY001-BE）：2 条
- 需人工判断（PY000）：187 条
- 维护负担（FUNC-LEN / NEST-DEEP）：544 条
具体表现：
- ERROR 几乎全部来自 PY000 except XXX: pass；
- 业务源码裸 except（PY001）= 0，BaseException 仅 2 处；
- 函数过长、嵌套过深数量在三者中最低。
画像总结：Django 容错编码约束最严格，开发规范尽量禁止裸 except，极少显式捕获 BaseException；主要容错风险来自定向捕获异常之后直接 pass 丢弃异常上下文，故障会被静默掩盖。整体代码维护负担最轻。
5.2 PyTorch torch 模块
ERROR=337（三项目最高），WARNING=5695，总告警 6032。
- PY000 except-pass：283；
- PY001 裸 except：8；
- PY001-BE BaseException 捕获高达 46 处，遥遥领先另外两个框架；
- 复杂度告警爆炸：FUNC-LEN=4552，NEST-DEEP=1143；
- 全局最高风险单点文件：compile_worker/subproc_pool.py（单文件 29 个 ERROR）。
画像总结：PyTorch 容错编码风格参差不齐。除普遍 except-pass 静默收容之外，大量代码显式捕获 BaseException，存在拦截 Ctrl-C 系统终止信号的高危反模式；同时巨型长函数、深层嵌套数量巨大，维护负担最重。
5.3 TensorFlow python 模块
ERROR=220，WARNING=3266，总告警 3486。
- PY000 except-pass：177；
- PY001 裸 except 高达 42 处，是三者裸 except 数量最多的项目；
- PY001-BE BaseException 捕获仅 1 处；
- 长函数数量庞大，部分文件嵌套深度最高达到 8 层；
- TF 头号高危文件：framework/ops.py（单文件 13 个 ERROR）。
画像总结：TensorFlow 非常喜欢直接写裸 except: 广谱捕获全部异常，但是很少显式写 except BaseException:；也就是说：大量无差别吞异常，但很少主动去拦截系统终止异常。except-pass 数量适中，长函数问题突出。
横向对比核心发现
- 裸 except（PY001）：TensorFlow >> PyTorch > Django（Django 业务源码 0 处）
- BaseException（PY001-BE）高危风险：高度集中在 PyTorch
- except-pass（PY000）：是三大工业 Python 框架共同普遍存在的现状
- 代码维护负担（长函数 + 嵌套过深）排序：PyTorch >> TensorFlow > Django
注意：反模式 ≠ 必然是 bug，部分框架会刻意采用此类写法实现特殊容错逻辑；工具仅标记嫌疑，最终需要人工结合上下文判定是否需要修改。
6. 重点高危文件人工抽样核验方案
⚠️ 重点：告警 ≠ bug！ 本实验采用抽样核验策略，不做全量告警逐条人工复核；except XXX: pass、裸 except 有一部分是框架作者业务刻意设计的容错收容写法；我们工具只产出嫌疑候选池，必须人工打开源码区分三类结果：
- OK 真实命中反模式（建议评估修复）
- ? 业务有意设计（保留，不需要修改）
- X 误报（工具规则缺陷）
工具报告的抽样建议
Rev3.6 起，工具在报告末尾自动给出三级抽样建议：
- 第 1 优先：高置信度告警（PY001-BE / PY002 / PY003）→ 误报率低，建议逐条打开源码确认；
- 第 2 优先：需人工判断告警（PY000 / PY001）→ 抽样看 Top 5 文件即可；
- 第 3 优先：维护负担告警（FUNC-LEN / NEST-DEEP）→ 按需优化，不必单独排优先级。
抽样清单
| 项目 | 文件路径 | ERROR | WARNING | 备注 |
|---|---|---|---|---|
| PyTorch | compile_worker/subproc_pool.py | 29 | 1 | 全局风险最高 |
| PyTorch | distributed/distributed_c10d.py | 10 | 51 | |
| TensorFlow | framework/ops.py | 13 | 31 | |
| TensorFlow | static_analysis/liveness_test.py | 8 | 0 | 注意：该文件为测试用例 |
| Django | models/expressions.py | 5 | 0 | |
| Django | models/query.py | 4 | 18 |
路径说明 ：以上路径为脚本输出的末两段简写（工具 _short_name() 取路径最后两段，避免 Windows 长路径刷屏）。完整路径按扫描根目录拼接如下：
- PyTorch：torch/_inductor/compile_worker/subproc_pool.py、torch/distributed/distributed_c10d.py
- TensorFlow：tensorflow/python/framework/ops.py、tensorflow/python/static_analysis/liveness_test.py
- Django：django/db/models/expressions.py、django/db/models/query.py
抽样记录表模板
| 项目 | 文件路径 | 行号 | 告警编码 | 源码原文 | 判定 | 备注 |
|---|---|---|---|---|---|---|
| PyTorch | compile_worker/subproc_pool.py | |||||
| PyTorch | distributed/distributed_c10d.py | |||||
| TensorFlow | framework/ops.py | |||||
| TensorFlow | static_analysis/liveness_test.py | 测试文件 | ||||
| Django | models/expressions.py | |||||
| Django | models/query.py |
小提示：
*_test.py测试文件出现大量裸 except，大概率属于测试场景刻意编写，判定为业务有意。
7. 工具短板与客观边界（写文章务必完整公开，拒绝夸大效果）
本工具是 L1 原型 AST 表层 SAST 初筛工具，不是商用重型静态分析引擎。
- 仅 AST 语法树表层模式匹配，没有数据流分析、没有跨文件过程分析、没有符号执行；
- @retry 系列 PY002-PY004 规则只识别字面量装饰器 @retry()；如果做别名封装
my_retry = retry(...)，再使用@my_retry会漏报； - FUNC-LEN、NEST-DEEP 是维护负担指标，不等于代码 bug；它们的 snippet 显示的是函数定义行附近，看不到嵌套结构本身，这是规则的固有局限；
- 只扫描 Python .py 源码；C/C++、CUDA 内核完全不分析；
- 不会自动过滤
*_test.py测试文件，测试代码告警需要人工区分； - 输出全部为风险候选池，不能直接作为最终缺陷结论，必须人工抽样复核；
- SAST 模块零第三方依赖，但整体脚本含可选依赖（算子评估需 torch，配置 YAML 解析需 pyyaml）；缺失时对应子命令自动降级，不影响 SAST；
- 三大框架横向对比粒度不统一：Django 是全仓库，PyTorch 和 TensorFlow 是核心子目录，绝对告警数仅供参考，不可作严格等量对比；
- Rev3.7 的
try:行首精确匹配显著降低 snippet 回溯误停在注释/docstring 的概率，但仍属于表层启发式，不能保证 100% 锚点准确。
8. 工具源码使用教程
8.1 获取脚本
脚本文件名：kongquan_cmpd_allinone_v1_rev3_7.py
单文件全部源码，Python 标准库即可运行 SAST 模块，无需额外 pip 依赖。配套回归验证脚本：verify_rev37.py。
8.2 基础命令
powershell
# 【推荐】先设置编码为 UTF-8，避免中文乱码（Rev3.7 已内置兜底，双保险更佳）
chcp 65001
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$env:PYTHONIOENCODING="utf-8"
# 单项目初筛 --quiet 汇总模式（推荐大项目使用）
python kongquan_cmpd_allinone_v1_rev3_7.py sast ./项目目录 --quiet
# 导出完整 JSON 报告，JSON 携带告警行号、源码 snippet 片段
python kongquan_cmpd_allinone_v1_rev3_7.py sast ./项目目录 --out report.json
# batch 批量扫描 benchmark 文件夹下多个子项目，输出 CSV 横向汇总表格
python kongquan_cmpd_allinone_v1_rev3_7.py batch ./benchmark --quiet
# 【重要】大项目输出行数极大，务必用重定向保存完整报告，避免窗口截断
python kongquan_cmpd_allinone_v1_rev3_7.py sast ./项目目录 > report.txt 2>&1⚠️ 编码 & 截断避坑提示（必须看）：
- 中文乱码 ：PowerShell 默认编码与脚本 UTF-8 输出不一致时，报告中文会乱码。先执行
chcp 65001切换代码页即可正常显示；乱码不影响统计数字准确性。 - 输出被截断 ：PyTorch/TensorFlow 告警量达数千上万行，PowerShell 窗口缓存上限会截断头部输出 ，直接复制会漏读汇总。务必使用
> report.txt 2>&1重定向到文件，再用Get-Content report.txt -Tail 20读取末尾汇总统计。
复现实验避坑提示（必须看）
PyTorch、TensorFlow 官方源码压缩包解压后会生成双层同名外壳文件夹，放入 benchmark 前需要把内层真实源码目录提取出来，否则 batch 扫描会读取不到 Python 源码，输出 0 告警；Django 解压为单层目录，无此问题。
正确路径速查：
- Django：
./django-main - PyTorch：
./pytorch-main/pytorch-main/torch - TensorFlow：
./tensorflow-master/tensorflow-master/tensorflow/python
回归验证用法
拿到 verify_rev37.py 后，确保其与被测脚本 kongquan_cmpd_allinone_v1_rev3_7.py 位于同一目录，直接运行：
powershell
python verify_rev37.py脚本会自动：找到同目录被测脚本 → 测试 CSV 死代码修复 → 测试 try: 回溯精确匹配。全部通过输出 ✅ Rev3.7 修复完整，未被破坏；任何一项失败会明确提示是哪处修复被破坏。修改了 write_csv_summary 或 _snippet_from_lines 后建议跑一遍再发版。
子命令完整说明
| 子命令 | 用途 |
|---|---|
| sast | Python 源码 AST 静态容错扫描（本次实验核心） |
| config | 配置文件扫描：Redis 连接池、双向同步、GitLab-CI 配置风险 |
| operator | Op-Edges 算子评估演示（CMP-D 理论配套） |
| simulate | 多域模拟器（Agent/ROS2/BEV/爬虫等场景仿真） |
| batch | 批量多项目扫描输出 CSV 横向对比，报告输出至 _cmpd_reports/ |
参数说明
--quiet / -q：只输出汇总统计，折叠明细，大项目必备；--exclude：手动追加需要排除的完整目录名；--out xxx.json：输出结构化 JSON 告警报告，附带源码片段。
报告输出结构说明（Rev3.7）
每次扫描报告分四部分：
- 顶部总结：总数 + 分级统计（高置信度 / 需人工判断 / 维护负担）；
- 分区打印：三个区分别给出规则统计 + Top 5 文件；
- 抽样建议：三级优先复核指引 + 总体统计；
- 完整明细 （不加
--quiet时）：按文件分组，每条告警末尾标注<<< 高置信度或<<< 需复核。
9. 总结与后续迭代计划
9.1 实验总结
自研单文件 AST 容错初筛工具「空圈 CMP-D」可以完成大项目快速初筛；SSD 磁盘环境下百万行级别 Python 项目扫描耗时 1 分钟出头，机械硬盘会有明显耗时增加。
在统一扫描口径下，对 Django、PyTorch、TensorFlow 三大工业级 Python 框架完成容错风险画像量化对比；
量化观测到关键差异：Django 严格限制裸 except；PyTorch 大量 BaseException 捕获；TensorFlow 裸 except 数量最多；except-pass 是三者共同普遍现状；
工具定位是初筛候选池，告警不等于缺陷，需要人工对 TOP 高危文件抽样核验；
Rev3.6 起工具自带告警分级和抽样建议，用户拿到报告即知道从哪里开始复核；Rev3.7 进一步清除死代码、加固 try: 回溯精确匹配，并配套回归验证脚本，工具链可维护性提升。
注：本评测结果基于本次下载的 Django、PyTorch、TensorFlow 对应源码快照，框架后续版本会持续修复代码，结果不代表项目永久状态，也不代表这些项目官方 GitHub 仓库的当前状态。
末尾补充
- 工具成熟度：L1 原型，仅供技术研究、开源项目初筛学习使用，不建议直接用于生产门禁。
- 实验数据集：Django、PyTorch-torch、TensorFlow-python 官方开源源码（Gitee 社区镜像快照）。
- 回归验证 ：本文数据基于
kongquan_cmpd_allinone_v1_rev3_7.py扫描产出，21 项核心指标经本地复现验证与 Rev3.6 完全一致，并经verify_rev37.py回归验证确认。
附件
预设 FAQ
Q：为什么不用 Ruff / Semgrep / SonarQube？
A：上述工具单项规则可以实现，但缺少面向容错画像、多项目批量横向对比的完整工作流；本工具定位是细分场景 L1 初筛原型，不是替代成熟商用 SAST。
Q：为什么部分 except-pass 不直接判定为 bug？
A：很多开源框架会刻意使用 except XXX: pass 实现容错收容逻辑，工具仅标记候选嫌疑，最终必须人工结合业务上下文确认。
Q：为什么 PY002-PY004 重试规则本次扫描全部为 0？
A：Django、PyTorch、TensorFlow 业务源码几乎没有使用 tenacity 库，相关代码仅存在于被排除的 tests 测试目录，该组规则适合业务大量使用 tenacity 的项目。
Q：扫描 TensorFlow 出现 SyntaxWarning 报错是不是脚本 bug？
A：不是脚本问题，警告来自 TensorFlow 源码内部非法转义字符串，不影响统计结果，可以忽略。
Q：测试的是模拟 Demo 脚本吗？
A：不是，实验源码来自 Gitee 社区镜像组（mirrors），是 GitHub 上游真实工业开源项目快照副本，并非人为编写的测试 Demo。
Q：复现时 PyTorch/TensorFlow 扫出 0 告警怎么办？
A：大概率是路径少了一层。这两家的官方压缩包解压后都是双层同名外壳文件夹，正确路径见第 4 节"复现实验避坑提示"。
Q：报告里的"高置信度 / 需人工判断 / 维护负担"三区是什么意思？
A：这是 Rev3.6 起的告警自动分级------高置信度（PY001-BE/PY002/PY003）误报率低，优先复核；需人工判断（PY000/PY001）部分可能是业务有意设计；维护负担（FUNC-LEN/NEST-DEEP）不代表有 bug。报告末尾有三级抽样建议。
Q：Rev3.7 改了什么？会不会影响之前的扫描数据？
A：Rev3.7 只做了代码质量精修（清除死代码、try: 回溯改为行首精确匹配），配套 verify_rev37.py 回归验证，并以 Rev3.7 重新扫描三大框架，六项核心指标与 Rev3.6 完全一致，未引入误报或漏报，可放心替换。
Q：跑验证脚本报 FileNotFoundError 路径错误？
A：那是验证脚本里的源文件路径还指向开发环境。把 verify_rev37.py 与被测脚本放在同一目录 即可自动发现，或把脚本内 SRC 改成你的本地实际路径。
Q：PowerShell 输出全是乱码 / 数字对不上？
A：先 chcp 65001 切 UTF-8；大项目务必用 > report.txt 2>&1 重定向保存完整报告再读末尾汇总，避免窗口缓存截断头部输出导致漏读。
重要声明
本文档全部为逻辑推演 + 由作者+元宝+千问 +豆包+deepseek多AI 交叉校验完成，未经同行评审验证。借用体系已逐项标注出处，不整合项已声明理由。