直接用 request.node 获取测试元数据：request.node.name 为显示名，originalname 为原始函数名，cls 和 module 分别返回所属类与模块；读取标记需先判空再取值；fixturenames 不全因只列已声明未执行的 fixture，应优先用 getfixturevalue 检查；注意 get_closest_marker 兼容性及 node 对象生命周期。
pytest里怎么拿到测试函数的元数据
直接用 request.node，它是 pytest 提供的当前测试节点对象，所有元数据都藏在这里。别试图从函数签名或装饰器里硬抠，那不是 pytest 的设计路径。
常见错误是以为 request 是测试函数的参数就自动有“函数名”“所属类”这些信息——其实它默认只暴露基础属性，得主动访问子属性才能拿到真正有用的元数据。
-
request.node.name：测试项的显示名（比如test_login[valid]），含参数化后缀 -
request.node.originalname：原始函数名（如test_login），不含参数化标记 -
request.node.cls：如果在类里定义，返回该类对象；否则为None -
request.node.module：所在模块对象，可取__name__或__file__
如何安全读取 pytest.mark 标记的值
不能直接写 request.node.get_closest_marker("skip") 就完事——如果标记没加，会返回 None，后续调 .args 或 .kwargs 就崩。必须先判空。
典型使用场景是做条件跳过、打日志、或驱动 fixture 行为（比如按 @pytest.mark.env("staging") 自动切换 base_url）。
立即学习“Python免费学习笔记（深入）”；
- 用
request.node.get_closest_marker("env")获取标记对象 - 检查是否为
None，再取.args[0]或.kwargs.get("reason") - 注意：多个同名标记时，
get_closest_marker只返回最靠近的那个（就近原则），不是全部
request.fixturenames 为什么有时为空或不全
因为 request.fixturenames 只列出「当前测试作用域内已声明但尚未执行」的 fixture 名字，不是运行时实际注入的对象列表。它不反映动态生成的 fixture，也不包含被 autouse=True 隐式加载但未显式声明的。
想确认某个 fixture 是否真被加载了，更可靠的方式是直接尝试访问它（比如 request.getfixturevalue("db")），捕获 FixtureLookupError。
- 在 conftest.py 里定义的 autouse fixture 不会出现在
fixturenames中 - 参数化导致的 fixture 实例（如
@pytest.mark.parametrize("x", [1,2])）也不会体现 - 如果只是想判断 fixture 是否可用，优先用
request.getfixturevalue()+ 异常处理
性能和兼容性要注意什么
request 对象本身开销极小，但频繁调用 get_closest_marker 或反复访问 node.parent 可能触发内部缓存重建，在大规模参数化测试中会有轻微累积效应。
Pytest 7.0+ 把 node.get_marker 标记为 deprecated，统一用 get_closest_marker；旧版本（如 6.x）不支持 get_closest_marker，得回退到 get_marker。
- 跨版本兼容写法：
getattr(request.node, "get_closest_marker", request.node.get_marker) - 避免在 setup/teardown 阶段以外大量读取
node.keywords，它底层是动态构建的 dict - 不要把
request.node存到全局变量或长生命周期对象里——节点对象在 session 结束后失效
元数据不是静态快照，而是活的引用。改一个 node.add_marker，后续所有地方看到的都会变，这点容易被忽略。
