eval() 必然存在远程代码执行风险，syntaxerror/nameerror只是表象；ast.literal_eval()仅支持字面量且错误统一为valueerror；simpleeval需显式注入变量和注册函数，不防死循环，须进程隔离。
直接说结论：eval() 不是“可能出错”，而是只要输入不可信，就必然存在未预期异常和远程代码执行风险；它抛出的 SyntaxError 或 NameError 只是表象，真正危险的是静默执行恶意逻辑——比如删文件、发请求、读环境变量。
为什么 eval() 会触发未预期异常
这些异常往往不是语法写错了，而是运行时命名空间被污染或解析流程失控导致的：
-
eval("{'a': 1 + 2}")看似合法，但若locals中没有定义__builtins__，会抛NameError: name '__builtins__' is not defined，而非你预想的ValueError - 传入含 Unicode BOM 或尾部空格的字符串，
eval()会直接报SyntaxError，而你可能误以为是用户输错了表达式 - 当
globals被手动清空（如del __builtins__），攻击者仍可通过() .__class__.__mro__[1].__subclasses__()拿回os模块，此时异常不会出现，但命令已执行 - 在多线程环境下共享
locals字典，一个线程改了变量，另一个线程eval()就可能因变量状态不一致而抛KeyError或返回错误结果
ast.literal_eval() 的真实适用边界
它不是“eval 的安全开关”，而是完全不同的解析器：只认字面量，不走求值流程。用错场景照样报错，且错误类型统一为 ValueError：
- 支持：
ast.literal_eval("[1, 'x', {'y': True}]")、ast.literal_eval("None") - 不支持：
ast.literal_eval("1.5 * 2")（含运算符）、ast.literal_eval("a")（单字符无引号）、ast.literal_eval("[1, 2,]")（尾部逗号）、ast.literal_eval('{"key": null}')（JSON 风格的null，需先替换为None） - 配置加载时容易翻车：YAML/JSON 导出的
true/false必须转成True/False，否则直接ValueError - 它不校验嵌套深度，超深嵌套（如千层列表）可能触发
MemoryError，但不会执行任意代码
需要算术表达式？别硬塞 literal_eval，用 simpleeval
simpleeval 是唯一能兼顾安全与计算能力的轻量方案，它基于 AST 白名单，不依赖 eval 或 exec：
- 基础用法：
from simpleeval import SimpleEval; s = SimpleEval(); s.eval("2 * x + y", names={"x": 5, "y": 3})→ 返回13 - 必须显式注入变量：
names=参数只接受字典，传globals()或locals()会让白名单失效 - 函数需手动注册：
s.functions["max"] = max，默认禁用所有函数调用 - 不处理超时或内存限制，生产环境务必套一层
concurrent.futures.ProcessPoolExecutor并设timeout和max_workers=1 - 遇到非法调用（如
__import__）直接抛NameError，比手写 AST Visitor 更可靠
最容易被忽略的点：很多人把 ast.literal_eval() 当作“万能 JSON 解析器”用，结果在 API 入参里收到 "true" 就崩；或者以为 simpleeval 能防死循环，其实它不拦截 s.eval("while True: pass") —— 这种必须进程级隔离。安全不是加个函数名就能解决的事，得看输入来源、执行上下文、资源边界三者是否对齐。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
