eval() 和 exec() 在生产环境几乎总该禁用，因其会执行任意字符串代码，导致远程命令执行等严重风险；应改用 ast.literal_eval()、白名单映射或 json.loads() 配合严格校验。
为什么 eval() 和 exec() 在生产环境几乎总该禁用
因为它们会直接执行任意字符串代码，只要输入可控（比如来自 HTTP 请求、配置文件、数据库字段），攻击者就能执行系统命令、读取敏感文件、甚至反向连接控制服务器。
常见错误现象：eval("os.system('id')") 看似无害，但一旦字符串含用户输入，就等同于把 shell 交出去；Django 或 Flask 中用 eval(request.args.get('expr')) 是高危模式。
- 替代方案优先用
ast.literal_eval()—— 它只允许基本字面量（dict、list、str、int等），拒绝函数调用和变量引用 - 真需要动态逻辑，改用明确的白名单映射：比如把用户传的
"add"映射到预定义的lambda a,b: a+b函数，而不是拼字符串再eval - CI/CD 流程中可加静态检查：用
pygrep或semgrep规则拦截eval(、exec(、compile(的调用
处理用户输入时，json.loads() 比 eval() 安全，但仍有边界条件
json.loads() 不执行代码，是解析 JSON 字符串的标准方式，但它不等于“完全免疫”。问题出在解析后的数据怎么用。
使用场景：API 接收前端传来的 {"user_id": "123", "action": "delete"}，你用 json.loads() 解析后，直接拿 data["user_id"] 去拼 SQL 查询？那就掉进注入坑了。
立即学习“Python免费学习笔记（深入）”；
- JSON 解析本身安全，但后续使用必须做类型校验：比如确认
user_id是int或符合 UUID 格式，不能是"123; DROP TABLE users;"（虽然 JSON 语法不允许分号，但若你用错了格式或混用其他解析逻辑，风险仍在） - 避免把解析结果直接传给
subprocess.run()或os.system()—— 即使值来自 JSON，也要过一遍shlex.quote()或改用参数化调用 - 注意编码陷阱：如果请求头声明
Content-Type: application/json; charset=latin-1，而你用 UTF-8 解码，可能触发异常或绕过校验（虽少见，但在老旧网关或代理下真实存在）
用 sqlite3 时，为什么参数化查询不是可选项，而是唯一合法写法
因为 SQLite 的 execute() 方法支持两种参数风格：? 占位符（推荐）和 :name 命名占位符（也安全），但字符串格式化（%、.format()、f-string）一律导致 SQL 注入。
错误示例：cursor.execute(f"SELECT * FROM users WHERE name = '{name}'") —— 只要 name 是 "' OR 1=1 -- "，整张表就裸奔了。
- 必须写成
cursor.execute("SELECT * FROM users WHERE name = ?", (name,))，注意元组单元素要加逗号 - 不要试图“手动转义”：SQLite 没有通用的转义函数，
sqlite3.escape_string()不存在，自己写正则替换引号极易遗漏边界 - 即使表名/列名需动态，也不能参数化（SQL 语法不允许），此时只能走白名单校验：
if table_name not in ["users", "orders"]:raise ValueError
subprocess.run() 的 shell=True 是什么情况下才敢开
几乎从不开。开 shell=True 意味着把整个字符串交给系统 shell 解析，所有 shell 特性（管道、重定向、变量展开、命令替换）全部激活 —— 用户输入哪怕一个 $PATH 或 `whoami`，后果不可控。
典型踩坑：为了图方便写 subprocess.run(f"curl -s {url} | jq '.name'", shell=True)，结果 url 是 "https://api.com?x=`rm -rf /`"。
- 绝对安全写法：设
shell=False（默认值），把命令拆成列表：subprocess.run(["curl", "-s", url], capture_output=True) - 如果真要管道，用 Python 分步调用，或通过
subprocess.Popen手动连接stdout和stdin，不依赖 shell - 唯一可考虑
shell=True的场景：脚本完全由运维写死、无任何外部输入、且运行在隔离容器内 —— 但这种需求本身就应该被质疑
最常被忽略的一点：安全不是某个函数的开关，而是数据流全程的约束。从 request body → JSON 解析 → 类型校验 → 数据库查询 → 外部命令调用，每一步的输出都可能是下一步的输入，任何一个环节松动，前面所有防御都归零。
