VSCode的Pylance仅提供本地增量提示，无法替代CI中的mypy/pyright：它不检查跨文件导入、循环引用、未使用变量，也不阻断PR合并；真正可靠的类型安全必须通过GitHub Actions等CI平台在统一环境中运行严格配置的静态检查。
VSCode本身不执行CI流程，它只负责本地编辑和预检；真正的静态扫描必须交由CI平台（如GitHub Actions）在远程环境中运行mypy或pyright，否则类型错误可能被本地配置掩盖、漏检。
为什么不能只靠VSCode的Pylance提示做CI？
Pylance是语言服务器，依赖缓存与增量分析，对跨文件导入、未打开的模块、动态构造的类型（如getattr、eval）支持有限；它也不会检查__init__.py缺失、循环导入警告、未使用变量等mypy/pyright能捕获的问题。更重要的是：Pylance的提示不会阻断PR合并——而CI里的mypy失败会直接让流水线红掉。
- VSCode中绿色高亮 ≠ 类型安全，只是“当前视图下没发现明显矛盾”
-
pyrightconfig.json里的"typeCheckingMode": "strict"只影响Pylance，不影响CI命令行行为 - 团队成员本地可能禁用Pylance、用不同Python版本、甚至没装Pylance——唯一可信的是统一CI环境
GitHub Actions里跑mypy的最小可行配置
在.github/workflows/ci.yml中，关键不是“能不能跑”，而是“跑得准不准”。以下参数决定扫描深度：
- 必须显式指定
--show-error-codes，方便定位规则编号（如misc、arg-type） - 加
--disallow-untyped-defs才能强制函数签名注解，避免“写了hint却漏了某个参数” - 用
--exclude "tests/|venv/|__pycache__/"排除干扰路径，否则mypy会报测试文件里故意写的类型错误 - 不要省略
--python-version 3.10（按项目实际），否则默认按最新版检查，可能误报旧语法兼容问题
name: Static Type Check
on: [push, pull_request]
jobs:
typecheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.10'
- name: Install dependencies
run: pip install mypy
- name: Run mypy
run: |
mypy --show-error-codes \
--disallow-untyped-defs \
--exclude "tests/|venv/|__pycache__/" \
--python-version 3.10 \
src/
pyright比mypy更适合CI吗？
不是“更适合”，而是“用途不同”：pyright快、启动快、对PEP 604联合类型（int | str）支持更早，但默认不启用严格模式；mypy慢一点，但规则更细、社区插件多（如mypy-boto3）、错误码语义更明确。CI中选哪个，取决于你是否已用它做本地开发：
立即学习“Python免费学习笔记（深入）”；
- 如果VSCode用Pylance（底层是pyright），CI也用
pyright，能保证提示一致，但需手动加--type-check-only和--skip-unimplemented避免误报 - 如果团队已写
mypy.ini配置了[mypy.plugins.mypy_boto3]，CI就必须用mypy，否则插件失效 - 二者都支持
--output-format=github，可直接在PR评论里标出具体行号
真正容易被忽略的点是：CI扫描路径必须和python.testing.pytestArgs里指定的测试路径隔离。比如pytestArgs设为["tests", "-x"]，但mypy若误扫tests/，就会因测试文件里大量def test_xxx()无类型注解而批量报错——这个坑90%的人在第一次CI失败时才意识到。
