gitlab或jenkins等ci/cd平台本身不识别、不解析、也不校验yield语句是否被try-catch包裹，因其属于语言级语法，异常防护需依赖静态分析工具链（如ruff、pylint、roslyn）在ci中强制执行ast级规则并设为门禁失败点，而非流水线配置直接实现。
GitLab 或 Jenkins 等主流 CI/CD 平台本身不识别、不解析、也不校验 yield 语句是否存在 try-catch 包裹——因为 yield 是语言级语法（如 Python 的生成器、C# 的迭代器、Kotlin 的 suspend 函数），其是否被异常处理，属于静态代码分析范畴，而非流水线执行层的控制点。
换句话说：CI/CD 流水线不会、也不能“拦截裸露的 yield”，它只负责拉代码、跑脚本、发制品。真正能发现并阻断这类问题的，是集成在 CI 流程中的静态检查工具链，且必须配合明确的规则定义与门禁策略。
? 为什么“强行拦截裸露 yield”不能靠 CI/CD 配置直接实现？
-
yield本身不是错误，也不是运行时风险点；风险来自yield 所在函数可能抛出异常，而调用方未做防护。 - CI/CD 不解析源码 AST（抽象语法树），无法判断某处
yield是否处于try/except块内，或其上游调用链是否具备异常兜底。 - 即使你写个 shell 脚本去 grep
yield，也完全无法区分：-
def gen(): yield 1✅ 安全（无异常路径） -
def gen(): yield risky_io_call()❌ 风险（但 grep 看不出）
-
所以，“拦截裸露 yield”本质是工程规范 + 工具链 + 门禁三者落地的结果，不是点几下 UI 就能生效的配置项。
✅ 正确做法：用静态分析工具在 CI 中卡住不合规代码
1. 选择支持 AST 级规则的语言专用 Linter
| 语言 | 推荐工具 | 关键能力 |
|---|---|---|
| Python |
pylint + 自定义 checker 或 ruff + pyproject.toml 规则 |
可编写插件检测 yield 所在函数是否被 try 包裹，或是否声明了 raises 注释 |
| C# |
Roslyn Analyzer（自定义 Diagnostic） |
编译期扫描 yield return 方法体，检查外围是否有 try 或 ExceptionFilter
|
| Kotlin |
detekt + 自定义 rule |
分析 suspend 函数中 yield 调用上下文，结合 @Throws 声明做一致性校验 |
示例（Python + Ruff）：
在.ruff.toml中启用--select SIM108（简化 if/else）、--select PT014（禁止裸露yield），或通过ruff plugin注册新规则：[tool.ruff.rules] # 启用社区实验性规则（需 ruff v0.5+） extend-select = ["YIELD001"] # 假设 YIELD001 是你自研的 "yield must be in try block" 规则
2. 在 CI 中强制执行，并设为失败门禁
以 GitLab CI 为例，在 .gitlab-ci.yml 中加入检查阶段：
lint-yield:
stage: lint
image: python:3.11
before_script:
- pip install ruff
script:
- ruff check --select=YIELD001 --output-format=github src/
allow_failure: false
⚠️ 注意：allow_failure: false 是关键——它让该 job 失败时整个 pipeline 中断，阻止不合规代码合入。
3. 补充防御：类型注解 + 文档契约（防漏网）
即使静态检查有盲区，也可通过约定提升可检出率：
- 要求所有含
yield的函数必须标注@raises IOError, ValueError（用pydantic或sphinx-autodoc提取） - 在函数 docstring 中强制包含
Raises:段落，CI 中用pydocstyle校验完整性
? 别踩坑：这些“伪拦截”方案无效且危险
- ❌ 在
.gitlab-ci.yml里写grep -r "yield" . | grep -v "try"—— 完全不可靠，正则无法理解嵌套、注释、字符串字面量。 - ❌ 试图用
pytest --tb=no忽略 yield 报错 —— 这是掩盖问题，不是拦截。 - ❌ 在部署前加一段“运行时 wrapper”捕获 yield 异常 ——
yield不抛异常，抛的是其内部调用的异常，wrapper 层级错位。
? 最后提醒一句
真正的“强行拦截”，从来不是靠 CI 配置喊口号，而是：
- 把规则编译进 linter（机器可执行）
- 把 linter 绑定到 pre-commit 和 CI（执行必过）
- 把规则含义写进《Python 编码公约》第 4.7 条（人肉对齐）
三者闭环，才叫“强行”。
