最稳妥替代eval()的方案是ast.literal_eval()，它仅解析安全字面量如数字、字符串、列表、字典等，杜绝代码注入；不支持运算、函数调用、属性访问等危险操作，且需注意输入格式、异常类型、空值及编码等兼容性细节。
直接结论：不要用 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 解析器，但覆盖绝大多数配置/数据场景。
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
支持的输入示例：
-
"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() 只解决代码执行风险，不校验业务逻辑合法性。
