Python eval安全问题怎么解决？用ast.literal_eval更安全

Python 中的 `eval()` 函数存在严重的安全风险，因为它会执行任意代码，极易导致远程命令执行、数据泄露等漏洞；而 `ast.literal_eval()` 是其最稳妥的替代方案，仅允许解析数字、字符串、列表、字典、元组等无副作用的字面量，从根源上杜绝代码注入，但使用时需注意输入格式（如 JSON 需转为 Python 语法）、异常类型变化、空值与编码处理、嵌套深度限制等细节，真正安全的关键不仅在于换用该函数，更在于严格清洗输入、明确定义信任边界，并意识到它只解决执行风险，不替代业务层面的数据校验。

直接结论：不要用 eval() 处理不可信输入，改用 ast.literal_eval() 是最稳妥的替代方案——它只允许解析字面量（如数字、字符串、列表、字典等），天然免疫代码注入。

为什么 eval() 会触发 SecurityError 或更糟？

eval() 会执行任意 Python 表达式，包括 __import__()、open()、exec() 等危险操作。即使在沙箱环境里，也极难彻底封死所有绕过路径。某些安全加固的 Python 运行时（如某些嵌入式解释器或受限容器）会主动抛出 SecurityError 拦截调用；更多时候它根本不会报错，而是悄悄执行恶意逻辑。

常见错误现象：

• 用户提交字符串 "[1, 2, __import__('os').system('rm -rf /')]"，eval() 直接执行命令
• 配置文件中读取的 JSON-like 字符串被 eval() 解析，结果意外执行了构造的表达式
• Web 表单传入的 "{'a': 1} + {'b': 2}" 触发类型错误，但更危险的是 "{'a': 1}.keys().__class__.__mro__[1].__subclasses__()" 这类反射探测

ast.literal_eval() 能解析哪些内容？

ast.literal_eval() 只接受 Python 字面量语法，即编译器能静态确认“不带副作用”的结构。它不是万能 JSON 解析器，但覆盖绝大多数配置/数据场景。

支持的输入示例：

• "123" → 123（int）
• "'hello'" 或 "\"world\"" → "hello"（str）
• "[1, 2, 'a']" → [1, 2, 'a']（list）
• "{'key': True, 'val': None}" → {'key': True, 'val': None}（dict）
• "(1, 2, 3)" → (1, 2, 3)（tuple）

不支持的（会抛 ValueError）：

• "1 + 2"（运算表达式）
• "os.listdir('.')"（函数调用）
• "{'a': 1}.items()"（方法调用）
• "None.lower()"（属性访问）
• "b'bytes'"（字节字面量，Python 3.6+ 才支持，旧版本直接报错）

实际替换时要注意的兼容性细节

从 eval() 切到 ast.literal_eval() 不是简单替换函数名，需检查输入格式和异常处理逻辑：

• 输入必须是合法 Python 字面量，不能是 JSON 格式：JSON 的 true/false/null 要改成 True/False/None；双引号字符串在 Python 字面量中合法，但单引号更常见
• 异常类型变了：eval() 报 SyntaxError、NameError 等，而 ast.literal_eval() 只抛 ValueError 和 MemoryError（后者极少）
• 性能差异小，但 ast.literal_eval() 实际更慢一点（因要构建 AST 并校验），不过对普通配置解析可忽略
• 如果原逻辑依赖 eval() 的动态作用域（比如传入 locals），ast.literal_eval() 完全不支持——这反而是好事，说明你原来就有隐患

别忘了边界场景：空输入、嵌套深度、编码问题

ast.literal_eval() 对边缘情况很严格，容易踩坑：

• 输入为空字符串 "" 或仅空白字符，直接抛 ValueError；务必先 .strip()
• 超深嵌套（如 1000 层列表）可能触发递归限制，报 ValueError（非 RecursionError），可通过 sys.setrecursionlimit() 调整，但建议先检查数据合理性
• 如果输入来自文件或网络，注意编码：传入 bytes 会报错，必须 decode 成 str；BOM 头（如 \ufeff）会导致解析失败，建议用 input_str.strip('\ufeff')
• 不支持注释、尾部逗号（[1, 2,] 在 Python 中合法，但 ast.literal_eval() 要求严格语法，此写法会报错）

真正棘手的点往往不在函数本身，而在你如何清洗输入、定义信任边界、以及是否把“解析成功”默认等同于“数据可信”。ast.literal_eval() 只解决代码执行风险，不校验业务逻辑合法性。

今天关于《Python eval安全问题怎么解决？用ast.literal_eval更安全》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！