在微服务或命令行工具里，把日志级别放到 JSON 配置文件中是很常见的做法。但不少人在读取配置后，直接把字符串传给日志框架的 setLevel 方法，结果得到一条报错或者级别根本没生效。核心原因在于：JSON 反序列化出来的永远是字符串、数字、布尔等基础类型，而日志框架内部通常使用枚举或整型常量来表示级别，二者并不能自动划等号。
以 Python 标准库 logging 为例，级别实际对应整数：DEBUG 是 10，INFO 是 20，WARNING 是 30。如果配置里写的是 "info"，从 JSON 读出来就是普通字符串 "info"，直接调用 logger.setLevel("info") 会触发 ValueError，因为框架期望的是数值或合法的级别名常量，而不是任意字符串对象。
为什么不能直接用字符串字面量
很多初学者以为日志框架会帮我们做字符串到级别的智能转换，但事实并非如此。logging 模块在设置级别时，会检查传入值是否为整数，或者是否为已注册到内部字典中的级别名称。字符串字面量 "info" 虽然看起来像级别名，但它没有经过标准注册流程，直接传入会被判定为非法。
更严重的是，在某些封装过的日志库中，传入字符串可能静默失败：框架发现类型不对就忽略配置，退回到默认级别。这种问题在测试环境很难发现，等到生产环境出故障想查详细日志时，才发现一直都在用 WARNING 级别，DEBUG 信息全丢了。因此，从配置读取级别后做显式转换，是必须的步骤而不是可选项。
正确的读取与映射方式
最稳妥的做法是建立一份配置字符串到日志级别的映射表，或者使用框架自带的解析函数。Python 中可以用 logging.getLevelName 的反向逻辑，也可以自己维护字典。下面是一段推荐写法：
import json
import logging
# 读取 JSON 配置
with open('config.json', 'r', encoding='utf-8') as f:
cfg = json.load(f)
level_str = cfg.get('log_level', 'info')
# 方式一：使用标准库映射
level_num = logging.getLevelName(level_str.upper())
if not isinstance(level_num, int):
raise ValueError('无效的日志级别: ' + level_str)
logger = logging.getLogger('app')
logger.setLevel(level_num)
# 方式二：自定义字典（更可控）
level_map = {
'debug': logging.DEBUG,
'info': logging.INFO,
'warn': logging.WARNING,
'warning': logging.WARNING,
'error': logging.ERROR,
'critical': logging.CRITICAL
}
level_num = level_map.get(level_str.lower(), logging.INFO)
logger.setLevel(level_num)
上面代码展示了两种思路。第一种依赖标准库，但注意 getLevelName 对未知字符串会返回字符串本身而不是整数，所以必须加类型判断。第二种自定义字典方式更直观，也能兼容 warn 和 warning 这类同义写法，适合配置来源不可控的项目。
如果使用的是其他语言，例如 Java 的 Logback，JSON 配置里同样不能写裸字符串给 level 节点，而要通过 <level>INFO</level> 这类框架可识别的节点，或者借助配置绑定器把字符串转成 Level 枚举。原理完全一致：文本配置与运行时枚举之间必须有一层显式转换。
常见误区与排查建议
误区之一是相信 JSON 解析库会自动识别语义。实际上 json.loads 只负责把文本变成基础类型，它不知道日志级别是什么。另一个误区是大小写混用，有些框架只认大写，有些不区分，最安全的办法是在映射前统一调用 upper 或 lower。
排查时可以先打印从配置读出的变量类型和值，确认它是字符串且内容符合预期；再打印转换后的级别数值，看是否落在 10 到 50 之间。若程序启动后日志量异常，第一反应就应该是检查级别映射是否生效，而不是盲目调高框架输出量。
小结
从 JSON 配置读取日志级别，本质是一个字符串到枚举或整数的反序列化补充步骤。只要记住配置里的是文本、框架要的是常量，中间补一层映射或标准解析调用，就能彻底避开非字符串字面量应用失败的问题。把这段逻辑封装成独立函数，还能在多个服务间复用，减少重复踩坑。