第一章类型注解写对了却没生效揭秘mypy配置8大断点、pyright语言服务器3个隐藏开关以及CI/CD中类型检查失效的7种真实日志线索类型注解未触发预期检查往往并非代码有误而是工具链在静默绕过。以下直击三大高频失效域。mypy配置的8大隐性断点--follow-importsskip跳过未安装包的导入导致跨模块类型推导中断缺失pyproject.toml中[tool.mypy]顶层声明使配置完全不加载disallow_untyped_defs true被子目录mypy.ini覆盖而未继承使用from __future__ import annotations但mypy版本0.990无法解析PEP 563延迟求值plugins路径错误或插件未注册如mypy_django_plugin未启用时Django模型类型丢失源码编码非UTF-8如GBKmypy解析AST失败后降级为无类型扫描exclude正则意外匹配.pyi文件导致存根类型未参与校验Python目标版本python_version设为3.8但代码使用3.10的match语句类型联合语法引发解析器提前退出pyright语言服务器的3个隐藏开关{ python.analysis.typeCheckingMode: basic, python.analysis.autoSearchPaths: false, python.analysis.useLibraryCodeForTypes: true }注意typeCheckingMode: off常被VS Code设置同步覆盖autoSearchPaths: false需手动添加python.defaultInterpreterPath指向虚拟环境useLibraryCodeForTypes关闭后requests.Response.json()等第三方返回类型将退化为Any。CI/CD中类型检查失效的7种真实日志线索日志片段根本原因Skipping 12 files due to parse errorspyproject.toml中files路径含通配符语法错误No configuration file foundCI工作目录与配置文件路径不一致未用--config-file显式指定Found 0 type errors但本地报错CI缓存了旧版mypy未执行pip install mypy1.10第二章mypy配置失效的8大典型断点与修复实践2.1 mypy.ini/pyproject.toml 配置文件加载路径与优先级冲突分析配置文件搜索顺序mypy 按以下顺序查找配置文件**首个匹配即停止搜索**命令行指定的--config-file路径当前工作目录下的pyproject.toml含[tool.mypy]当前工作目录下的mypy.ini父目录逐级向上回溯直至根目录或首次匹配优先级冲突示例[tool.mypy] disallow_untyped_defs true plugins [mypy_django]若项目根目录存在pyproject.toml而子目录存在mypy.ini则子目录执行mypy .时仍加载根目录 TOML —— 因为搜索从当前目录开始且 TOML 优先级高于 INI。典型覆盖场景对比场景生效配置原因cd src mypy app/../pyproject.toml根目录 TOMLTOML 存在且路径可达mypy --config-file mypy.local.ini显式指定文件命令行参数最高优先级2.2 ignore_missing_imports 与 disallow_untyped_defs 的隐式覆盖关系验证配置冲突的本质当ignore_missing_imports true启用时mypy 会跳过未解析的导入检查但该宽松策略可能意外绕过disallow_untyped_defs true对函数签名类型的强制要求。典型触发场景模块 A 导入了尚未安装的第三方包如import polars as pl模块 A 中定义了无类型注解的函数def process(): ...mypy 因ignore_missing_imports忽略导入错误进而跳过对该函数的类型定义校验行为验证代码# mypy.ini [mypy] ignore_missing_imports true disallow_untyped_defs true该配置下mypy 不再报错未注解函数——ignore_missing_imports隐式禁用了部分严格模式检查链导致disallow_untyped_defs在涉及缺失导入的文件中失效。影响范围对比配置组合缺失导入文件中的 untyped def 是否报错ignore_missing_importsfalsedisallow_untyped_defstrue✅ 报错ignore_missing_importstruedisallow_untyped_defstrue❌ 不报错隐式覆盖2.3 plugins 配置错误导致 TypedDict 和 NewType 类型推导中断的复现与调试典型错误配置示例[tool.mypy.plugins] mypy_django_plugin.main {} # 缺少 typeddict_support true导致 TypedDict 被降级为 dict该插件未显式启用 TypedDict 支持时mypy 会跳过结构化类型检查将所有TypedDict视为普通dict[str, Any]进而影响下游NewType的类型守卫推导。影响范围对比配置项TypedDict 推导NewType 包装推导默认插件配置❌ 失效❌ 中断依赖 TypedDict 精确类型typeddict_support true✅ 完整保留字段名与类型✅ 正确识别包装/解包边界修复步骤在pyproject.toml中为插件添加typeddict_support true键重启 mypy daemon 或清除缓存mypy --clear-cache2.4 exclude 与 files 字段的正则匹配陷阱及 glob 模式失效案例实测常见配置误区许多工具如 ESLint、Webpack、Terraform将exclude和files视为路径匹配字段但实际解析逻辑差异巨大前者多用正则后者常依赖 glob —— 二者混用极易失效。实测失效案例{ exclude: [node_modules/**, .*], files: [src/**/*.ts, !src/test/**] }该配置在 TypeScript 项目中无法排除src/test/下文件因files字段不支持!取反语法仅部分 CLI 工具如globby支持TS 编译器原生忽略该规则。匹配行为对比工具exclude 类型files 类型支持 ! 取反TypeScript正则字符串转 RegExpglob无高级扩展否ESLintglob 正则混合glob支持 !是2.5 Python 版本目标python_version与类型语法兼容性断层排查如 PEP 604 Union | 语法PEP 604 语法的版本分水岭Python 3.10 引入 | 作为类型联合运算符如 str | int但该语法在 3.9 及更早版本中会触发 SyntaxError。pyproject.toml 中的 python_version 3.9 若搭配此类类型注解将导致静态检查失败。兼容性检测示例# pyright 或 mypy 在 python_version3.9 下报错 def parse_value(x: str | None) - int: return len(x) if x else 0此代码在 Python 3.10 合法在 3.9 需回退为 Union[str, None] 并导入 from typing import Union。主流版本支持对照语法特性Python ≥3.10Python ≥3.9str | int✅ 支持❌ SyntaxErrorUnion[str, int]✅ 兼容✅ 兼容第三章pyright语言服务器的3个隐藏开关及其行为差异3.1 typeCheckingMode: basic / strict / off 对泛型协变性检查的实际影响对比协变性检查行为差异不同模式下编译器对泛型类型参数的协变covariant使用合法性验证强度显著不同off完全跳过协变性检查允许不安全的向上转型如ArrayDog→ArrayAnimal可能引发运行时类型错误basic仅检查显式标注out的类型参数是否被合法使用即仅读取、未写入strict额外验证隐式协变场景如函数返回值中的嵌套泛型、高阶类型推导路径。代码行为对比interface Containerout T { fun get(): T // ✅ 协变位置 // fun set(t: T) {} // ❌ 编译错误即使 basic 模式也报错 }在typeCheckingMode basic下上述接口定义通过但若将get()改为fun get(): ListTstrict模式会进一步检查List是否自身协变是而basic不深入此层。模式影响速查表检查项offbasicstrict显式out参数非法写入✓ 忽略✗ 报错✗ 报错嵌套泛型协变传递性✓ 忽略✓ 忽略✗ 报错若违反3.2 enableTypeChecking 和 disableLanguageServices 的组合副作用分析核心冲突机制当enableTypeCheckingtrue与disableLanguageServicestrue同时启用时类型检查器仍会解析 AST 并执行语义校验但语言服务如自动补全、跳转定义、悬停提示被强制终止——导致类型错误可报告却无法定位或修正。典型配置示例{ enableTypeChecking: true, disableLanguageServices: true, typeCheckMode: strict }该配置使 TypeScript 编译器在构建阶段保留类型校验逻辑但 VS Code 插件层主动忽略所有textDocument/*LSP 请求造成 IDE 内“报错可见、交互失能”。副作用影响矩阵行为启用禁用编译时类型报错✅❌编辑器内悬停类型提示❌✅保存时自动修复❌✅3.3 typeAcquisition 与 types 字段在第三方库类型补全中的静默失败场景还原典型配置冲突示例{ compilerOptions: { typeAcquisition: { enable: true, include: [lodash] }, types: [node] } }当types显式声明后TypeScript 会**完全忽略**typeAcquisition自动获取的types/lodash且不报错、不警告。静默失败的根源types字段为白名单模式仅加载列表中指定的类型包typeAcquisition仅在types未设置或为空数组时生效验证行为差异配置状态是否加载 types/lodashtypes: []✅ 是typeAcquisition 生效types: [node]❌ 否完全屏蔽第四章CI/CD流水线中类型检查失效的7种真实日志线索与根因定位4.1 GitHub Actions 中 mypy --show-traceback 未启用导致的堆栈截断日志解析问题现象GitHub Actions 默认仅显示 mypy 错误摘要关键异常上下文被截断难以定位类型检查失败的深层调用链。修复方案在 workflow YAML 中显式启用完整堆栈追踪- name: Type check run: mypy --show-traceback src/--show-traceback强制输出 Python 原生异常栈帧暴露Callable类型推导中断点或泛型协变冲突源头。效果对比选项错误行数包含调用栈mypy src/1❌mypy --show-traceback src/8–12✅4.2 GitLab CI 缓存 .mypy_cache 导致 stale type info 的复现与清除策略问题复现路径当 GitLab CI 启用 cache:paths: 缓存 .mypy_cache/ 时跨分支/跨提交的类型检查可能复用陈旧缓存导致 mypy 报告已修复的类型错误或忽略新增的类型不匹配。缓存清除方案在 .gitlab-ci.yml 中为 mypy job 显式禁用缓存cache: { key: none }或使用带语义的缓存键如基于 pyproject.toml mypy.ini 哈希避免污染推荐配置示例mypy: script: - mypy --show-error-codes . cache: key: $CI_PROJECT_NAME-mypy-${CI_COMMIT_REF_SLUG}-$(sha256sum pyproject.toml mypy.ini | cut -d -f1) paths: - .mypy_cache/该配置确保缓存键随类型检查配置变更而失效避免 stale type info。sha256sum 输出哈希值作为唯一标识cut 提取首字段以适配 GitLab 缓存键长度限制。4.3 pre-commit hook 调用 mypy 时 PYTHONPATH 缺失引发的模块不可见日志特征识别典型错误日志模式当 pre-commit 执行 mypy 时若未正确注入 PYTHONPATH常见报错如下error: Cannot find module myproject.utils note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports该日志明确指向模块导入失败且不含路径解析细节——这是 PYTHONPATH 缺失而非代码语法错误的核心特征。根本原因与验证方法pre-commit 默认以项目根目录为工作目录但不继承 shell 的 PYTHONPATH 环境变量mypy 默认仅搜索 sys.path[0]当前文件所在目录及已安装包忽略本地源码树修复配置对比配置方式是否生效说明python -m mypy --python-path src/✅--python-path显式指定源码根env: {PYTHONPATH: src}in .pre-commit-config.yaml✅向 hook 进程注入环境变量4.4 Docker 构建阶段中 pyright CLI 与 VS Code 插件版本不一致的日志指纹比对问题现象定位Docker 构建时 pyright --verifyTypes 报出类型检查通过而 VS Code 中却高亮 Unknown import 错误。关键差异在于日志中 pyright --version 输出与插件启动日志中的 Pyright language server v1.1.321 不匹配。版本指纹提取脚本# 提取构建镜像中 pyright CLI 版本 docker run --rm -v $(pwd):/workspace my-python-app \ sh -c cd /workspace python -m pyright --version 2/dev/null | sed s/Pyright version //该命令在构建上下文中执行 CLI 版本查询规避 PATH 冲突2/dev/null 屏蔽警告干扰sed 精确剥离前缀输出纯语义化版本字符串如 1.1.319。双端版本比对表环境获取方式典型值Docker 构建阶段python -m pyright --version1.1.319VS Code 插件Output 面板 → “Pyright” 日志首行1.1.321第五章类型注解写对了却没生效揭秘mypy配置8大断点、pyright语言服务器3个隐藏开关以及CI/CD中类型检查失效的7种真实日志线索mypy常见配置断点follow_imports silent隐式跳过未安装包的类型检查导致from fastapi import Depends等导入不被解析缺失plugins [pydantic.mypy]时Pydantic v2模型字段类型推导完全失效pyright隐藏开关{ typeCheckingMode: strict, reportUnknownVariableType: warning, disableLanguageService: false }CI/CD中类型检查失效的关键日志线索日志片段根本原因Skipping .mypy_cache: not a regular file缓存目录被误设为符号链接mypy跳过全部增量检查Could not find module djangoCI环境未运行pip install -e .[dev]导致可选依赖缺失实战修复示例问题VS Code中pyright报告Union[str, None]但mypy无提示定位检查pyproject.toml中[tool.mypy]与[tool.pyright]是否共用同一python_version和platform配置
类型注解写对了却没生效？揭秘mypy配置8大断点、pyright语言服务器3个隐藏开关，以及CI/CD中类型检查失效的7种真实日志线索
发布时间：2026/5/18 5:16:17
第一章类型注解写对了却没生效揭秘mypy配置8大断点、pyright语言服务器3个隐藏开关以及CI/CD中类型检查失效的7种真实日志线索类型注解未触发预期检查往往并非代码有误而是工具链在静默绕过。以下直击三大高频失效域。mypy配置的8大隐性断点--follow-importsskip跳过未安装包的导入导致跨模块类型推导中断缺失pyproject.toml中[tool.mypy]顶层声明使配置完全不加载disallow_untyped_defs true被子目录mypy.ini覆盖而未继承使用from __future__ import annotations但mypy版本0.990无法解析PEP 563延迟求值plugins路径错误或插件未注册如mypy_django_plugin未启用时Django模型类型丢失源码编码非UTF-8如GBKmypy解析AST失败后降级为无类型扫描exclude正则意外匹配.pyi文件导致存根类型未参与校验Python目标版本python_version设为3.8但代码使用3.10的match语句类型联合语法引发解析器提前退出pyright语言服务器的3个隐藏开关{ python.analysis.typeCheckingMode: basic, python.analysis.autoSearchPaths: false, python.analysis.useLibraryCodeForTypes: true }注意typeCheckingMode: off常被VS Code设置同步覆盖autoSearchPaths: false需手动添加python.defaultInterpreterPath指向虚拟环境useLibraryCodeForTypes关闭后requests.Response.json()等第三方返回类型将退化为Any。CI/CD中类型检查失效的7种真实日志线索日志片段根本原因Skipping 12 files due to parse errorspyproject.toml中files路径含通配符语法错误No configuration file foundCI工作目录与配置文件路径不一致未用--config-file显式指定Found 0 type errors但本地报错CI缓存了旧版mypy未执行pip install mypy1.10第二章mypy配置失效的8大典型断点与修复实践2.1 mypy.ini/pyproject.toml 配置文件加载路径与优先级冲突分析配置文件搜索顺序mypy 按以下顺序查找配置文件**首个匹配即停止搜索**命令行指定的--config-file路径当前工作目录下的pyproject.toml含[tool.mypy]当前工作目录下的mypy.ini父目录逐级向上回溯直至根目录或首次匹配优先级冲突示例[tool.mypy] disallow_untyped_defs true plugins [mypy_django]若项目根目录存在pyproject.toml而子目录存在mypy.ini则子目录执行mypy .时仍加载根目录 TOML —— 因为搜索从当前目录开始且 TOML 优先级高于 INI。典型覆盖场景对比场景生效配置原因cd src mypy app/../pyproject.toml根目录 TOMLTOML 存在且路径可达mypy --config-file mypy.local.ini显式指定文件命令行参数最高优先级2.2 ignore_missing_imports 与 disallow_untyped_defs 的隐式覆盖关系验证配置冲突的本质当ignore_missing_imports true启用时mypy 会跳过未解析的导入检查但该宽松策略可能意外绕过disallow_untyped_defs true对函数签名类型的强制要求。典型触发场景模块 A 导入了尚未安装的第三方包如import polars as pl模块 A 中定义了无类型注解的函数def process(): ...mypy 因ignore_missing_imports忽略导入错误进而跳过对该函数的类型定义校验行为验证代码# mypy.ini [mypy] ignore_missing_imports true disallow_untyped_defs true该配置下mypy 不再报错未注解函数——ignore_missing_imports隐式禁用了部分严格模式检查链导致disallow_untyped_defs在涉及缺失导入的文件中失效。影响范围对比配置组合缺失导入文件中的 untyped def 是否报错ignore_missing_importsfalsedisallow_untyped_defstrue✅ 报错ignore_missing_importstruedisallow_untyped_defstrue❌ 不报错隐式覆盖2.3 plugins 配置错误导致 TypedDict 和 NewType 类型推导中断的复现与调试典型错误配置示例[tool.mypy.plugins] mypy_django_plugin.main {} # 缺少 typeddict_support true导致 TypedDict 被降级为 dict该插件未显式启用 TypedDict 支持时mypy 会跳过结构化类型检查将所有TypedDict视为普通dict[str, Any]进而影响下游NewType的类型守卫推导。影响范围对比配置项TypedDict 推导NewType 包装推导默认插件配置❌ 失效❌ 中断依赖 TypedDict 精确类型typeddict_support true✅ 完整保留字段名与类型✅ 正确识别包装/解包边界修复步骤在pyproject.toml中为插件添加typeddict_support true键重启 mypy daemon 或清除缓存mypy --clear-cache2.4 exclude 与 files 字段的正则匹配陷阱及 glob 模式失效案例实测常见配置误区许多工具如 ESLint、Webpack、Terraform将exclude和files视为路径匹配字段但实际解析逻辑差异巨大前者多用正则后者常依赖 glob —— 二者混用极易失效。实测失效案例{ exclude: [node_modules/**, .*], files: [src/**/*.ts, !src/test/**] }该配置在 TypeScript 项目中无法排除src/test/下文件因files字段不支持!取反语法仅部分 CLI 工具如globby支持TS 编译器原生忽略该规则。匹配行为对比工具exclude 类型files 类型支持 ! 取反TypeScript正则字符串转 RegExpglob无高级扩展否ESLintglob 正则混合glob支持 !是2.5 Python 版本目标python_version与类型语法兼容性断层排查如 PEP 604 Union | 语法PEP 604 语法的版本分水岭Python 3.10 引入 | 作为类型联合运算符如 str | int但该语法在 3.9 及更早版本中会触发 SyntaxError。pyproject.toml 中的 python_version 3.9 若搭配此类类型注解将导致静态检查失败。兼容性检测示例# pyright 或 mypy 在 python_version3.9 下报错 def parse_value(x: str | None) - int: return len(x) if x else 0此代码在 Python 3.10 合法在 3.9 需回退为 Union[str, None] 并导入 from typing import Union。主流版本支持对照语法特性Python ≥3.10Python ≥3.9str | int✅ 支持❌ SyntaxErrorUnion[str, int]✅ 兼容✅ 兼容第三章pyright语言服务器的3个隐藏开关及其行为差异3.1 typeCheckingMode: basic / strict / off 对泛型协变性检查的实际影响对比协变性检查行为差异不同模式下编译器对泛型类型参数的协变covariant使用合法性验证强度显著不同off完全跳过协变性检查允许不安全的向上转型如ArrayDog→ArrayAnimal可能引发运行时类型错误basic仅检查显式标注out的类型参数是否被合法使用即仅读取、未写入strict额外验证隐式协变场景如函数返回值中的嵌套泛型、高阶类型推导路径。代码行为对比interface Containerout T { fun get(): T // ✅ 协变位置 // fun set(t: T) {} // ❌ 编译错误即使 basic 模式也报错 }在typeCheckingMode basic下上述接口定义通过但若将get()改为fun get(): ListTstrict模式会进一步检查List是否自身协变是而basic不深入此层。模式影响速查表检查项offbasicstrict显式out参数非法写入✓ 忽略✗ 报错✗ 报错嵌套泛型协变传递性✓ 忽略✓ 忽略✗ 报错若违反3.2 enableTypeChecking 和 disableLanguageServices 的组合副作用分析核心冲突机制当enableTypeCheckingtrue与disableLanguageServicestrue同时启用时类型检查器仍会解析 AST 并执行语义校验但语言服务如自动补全、跳转定义、悬停提示被强制终止——导致类型错误可报告却无法定位或修正。典型配置示例{ enableTypeChecking: true, disableLanguageServices: true, typeCheckMode: strict }该配置使 TypeScript 编译器在构建阶段保留类型校验逻辑但 VS Code 插件层主动忽略所有textDocument/*LSP 请求造成 IDE 内“报错可见、交互失能”。副作用影响矩阵行为启用禁用编译时类型报错✅❌编辑器内悬停类型提示❌✅保存时自动修复❌✅3.3 typeAcquisition 与 types 字段在第三方库类型补全中的静默失败场景还原典型配置冲突示例{ compilerOptions: { typeAcquisition: { enable: true, include: [lodash] }, types: [node] } }当types显式声明后TypeScript 会**完全忽略**typeAcquisition自动获取的types/lodash且不报错、不警告。静默失败的根源types字段为白名单模式仅加载列表中指定的类型包typeAcquisition仅在types未设置或为空数组时生效验证行为差异配置状态是否加载 types/lodashtypes: []✅ 是typeAcquisition 生效types: [node]❌ 否完全屏蔽第四章CI/CD流水线中类型检查失效的7种真实日志线索与根因定位4.1 GitHub Actions 中 mypy --show-traceback 未启用导致的堆栈截断日志解析问题现象GitHub Actions 默认仅显示 mypy 错误摘要关键异常上下文被截断难以定位类型检查失败的深层调用链。修复方案在 workflow YAML 中显式启用完整堆栈追踪- name: Type check run: mypy --show-traceback src/--show-traceback强制输出 Python 原生异常栈帧暴露Callable类型推导中断点或泛型协变冲突源头。效果对比选项错误行数包含调用栈mypy src/1❌mypy --show-traceback src/8–12✅4.2 GitLab CI 缓存 .mypy_cache 导致 stale type info 的复现与清除策略问题复现路径当 GitLab CI 启用 cache:paths: 缓存 .mypy_cache/ 时跨分支/跨提交的类型检查可能复用陈旧缓存导致 mypy 报告已修复的类型错误或忽略新增的类型不匹配。缓存清除方案在 .gitlab-ci.yml 中为 mypy job 显式禁用缓存cache: { key: none }或使用带语义的缓存键如基于 pyproject.toml mypy.ini 哈希避免污染推荐配置示例mypy: script: - mypy --show-error-codes . cache: key: $CI_PROJECT_NAME-mypy-${CI_COMMIT_REF_SLUG}-$(sha256sum pyproject.toml mypy.ini | cut -d -f1) paths: - .mypy_cache/该配置确保缓存键随类型检查配置变更而失效避免 stale type info。sha256sum 输出哈希值作为唯一标识cut 提取首字段以适配 GitLab 缓存键长度限制。4.3 pre-commit hook 调用 mypy 时 PYTHONPATH 缺失引发的模块不可见日志特征识别典型错误日志模式当 pre-commit 执行 mypy 时若未正确注入 PYTHONPATH常见报错如下error: Cannot find module myproject.utils note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports该日志明确指向模块导入失败且不含路径解析细节——这是 PYTHONPATH 缺失而非代码语法错误的核心特征。根本原因与验证方法pre-commit 默认以项目根目录为工作目录但不继承 shell 的 PYTHONPATH 环境变量mypy 默认仅搜索 sys.path[0]当前文件所在目录及已安装包忽略本地源码树修复配置对比配置方式是否生效说明python -m mypy --python-path src/✅--python-path显式指定源码根env: {PYTHONPATH: src}in .pre-commit-config.yaml✅向 hook 进程注入环境变量4.4 Docker 构建阶段中 pyright CLI 与 VS Code 插件版本不一致的日志指纹比对问题现象定位Docker 构建时 pyright --verifyTypes 报出类型检查通过而 VS Code 中却高亮 Unknown import 错误。关键差异在于日志中 pyright --version 输出与插件启动日志中的 Pyright language server v1.1.321 不匹配。版本指纹提取脚本# 提取构建镜像中 pyright CLI 版本 docker run --rm -v $(pwd):/workspace my-python-app \ sh -c cd /workspace python -m pyright --version 2/dev/null | sed s/Pyright version //该命令在构建上下文中执行 CLI 版本查询规避 PATH 冲突2/dev/null 屏蔽警告干扰sed 精确剥离前缀输出纯语义化版本字符串如 1.1.319。双端版本比对表环境获取方式典型值Docker 构建阶段python -m pyright --version1.1.319VS Code 插件Output 面板 → “Pyright” 日志首行1.1.321第五章类型注解写对了却没生效揭秘mypy配置8大断点、pyright语言服务器3个隐藏开关以及CI/CD中类型检查失效的7种真实日志线索mypy常见配置断点follow_imports silent隐式跳过未安装包的类型检查导致from fastapi import Depends等导入不被解析缺失plugins [pydantic.mypy]时Pydantic v2模型字段类型推导完全失效pyright隐藏开关{ typeCheckingMode: strict, reportUnknownVariableType: warning, disableLanguageService: false }CI/CD中类型检查失效的关键日志线索日志片段根本原因Skipping .mypy_cache: not a regular file缓存目录被误设为符号链接mypy跳过全部增量检查Could not find module djangoCI环境未运行pip install -e .[dev]导致可选依赖缺失实战修复示例问题VS Code中pyright报告Union[str, None]但mypy无提示定位检查pyproject.toml中[tool.mypy]与[tool.pyright]是否共用同一python_version和platform配置
