pytest.toml 的 faulthandler_timeout 写数字，却报 expects a string

pytest.toml 已有正确的 [pytest] 表，只写了 faulthandler_timeout = 5，启动测试仍然报：

config option 'faulthandler_timeout' expects a string, got int: 5

这里的数字是合法 TOML，问题发生在 pytest 对这项配置的类型读取。相关入口虽然最终会把超时值转成浮点数，旧注册方式却没有把原生 TOML 数值列为允许类型。

保持超时值，先把这项配置写成字符串

对尚未包含类型读取修复的版本，可以在原来的配置位置改为：

# pytest.toml 或 .pytest.toml
[pytest]
faulthandler_timeout = "5"

若使用 pyproject.toml 的原生格式，对应位置是：

[tool.pytest]
faulthandler_timeout = "5"

不要同时新建多份配置来试。先看 pytest 启动信息中的 configfile，确认真正加载了哪一份；修复的是该选项的值类型，不是重新选择项目根目录。带引号的内容仍须是有效数值，例如 "5 seconds" 并不能被浮点转换接受。

INI 配置本来使用文本值，不应为了套用上述写法，把引号也当成值写进 pytest.ini。在 INI 中保持正常的 faulthandler_timeout = 5 即可。

这项回归不能靠“已经有 [pytest]”排除

缺失 [pytest] 会让原生 TOML 选项没有进入正确配置表；本题中，选项已被找到，报错甚至能指出它的名字和 int 类型，失败点不同。可核对的 pytest 9.1.1 正式源码仍是旧的注册方式，2026 年 10 月开发分支已经加入接受 float | str 的处理，但不能由开发分支合入推断正式补丁已经发布。

选择未来包含修复的正式版后，再验证数字形式能否按文档读取；不必为恢复数字写法就立即切换到开发版。

启动恢复后，确认诊断仍然覆盖实际测试

faulthandler_timeout 用于测试耗时超过阈值时输出线程栈，不是通用的业务超时取消机制。把值改成零可以避开部分行为，却也会关闭原本需要的诊断，不能算等价修复。

在原本允许执行测试的开发环境里，保留实际启动命令，核对测试确实被收集、配置中的秒数没有变，以及原先支持的超时栈输出仍正常。不要为了验证而在生产进程制造死锁。若配置读取已通过，随后仍出现挂起或诊断覆盖不到某个阶段，需要按测试生命周期另查，不应继续围着 TOML 引号修改。