conan“标准库错误”实为python层配置错误，典型如大小写拼写错误（conanfile→conanfile）、settings/options类型不匹配、混用1.x/2.x导入语法、build_type理解偏差及windows多配置遗漏--config参数。
Conan 标准库错误不是标准术语，实际多指 conanfile.py 中类名、导入或配置项写错导致的 ImportError 或解析失败，根源几乎全在 Python 层面，而非 C++ 标准库本身。
ImportError: cannot import name 'Conanfile' from 'conan'
这是 Conan 2.x 最典型的“标准库错误”假象。报错看着像缺模块，实则是大小写拼写错误。
-
from conan import Conanfile（小写 f）→ 必报此错；正确写法必须是from conan import ConanFile（大写 F） - IDE 自动补全常误导你选
Conanfile，但 Conan 2.x 源码里只导出ConanFile类，不提供小写变体 - 哪怕
conan --version正常，这个 import 错误也照常发生——它和安装方式（.exe 还是 pip）完全无关
conanfile.py 里 settings 或 options 配置不合法
Conan 在加载 conanfile.py 时会静态校验字段类型和取值范围，非法配置直接中断解析。
-
settings = "os", "compiler"写成settings = ["os", "compiler"]→ 报错：expected str, got list -
options = {"shared": [True, False]}但default_options = {"shared": "yes"}→ 值类型不匹配，会提示 invalid value for option 'shared' - 使用了旧版 Conan 1.x 的
from conans import ConanFile导入方式，在 Conan 2.x 下会静默失败或触发奇怪的 AttributeError
build_type=Debug 不生效，下游依赖仍用 Release 二进制
这不是配置写错，而是对 Conan 构建维度的理解偏差——build_type 是 settings，不是 options，它天然参与 package ID 计算，但不会“传递”给依赖，而是决定“选哪个二进制”。
- 执行
conan install . -s build_type=Debug后，若远程没有对应 Debug 二进制，Conan 默认不回退，会报 missing binary 错误 - 想强制从源码构建，得加
--build=missing；否则即使本地有 Debug 构建逻辑，也会卡在找不到包这一步 - Windows 上用 MSVC 多配置生成器（如 Visual Studio）时，
-s build_type=Debug只影响 host profile，链接阶段还必须用--config Debug显式指定
真正容易被忽略的是：Conan 的配置错误往往不报“语法错”，而是在运行时表现为“找不到包”“链接失败”或“头文件路径为空”，此时第一反应不该是查 C++ 编译器或链接器，而是先验证 conanfile.py 是否能被 Python 正确 import、conan list 能否列出本地缓存中的目标包、conan graph info 输出的依赖图是否符合预期——这些才是配置生效与否的直接证据。
