eval() 危险因动态执行不可信代码，应改用 json.loads() 或 ast.literal_eval()；requests 必须设 timeout 防雪崩；浮点比较须用 math.isclose()；日志配置应封装函数并单次调用。
为什么 eval() 在审查中总被标红
因为它是运行时动态执行字符串代码的唯一入口，相当于把解释器的控制权直接交出去。只要输入不可信，就等于给攻击者开了个 shell。
常见错误现象：eval(input()) 被用于“快捷配置”或“调试命令”，上线后被传入 __import__('os').system('rm -rf /')；或者用 eval() 解析前端传来的 JSON 字符串，结果绕过类型校验直接执行任意代码。
实操建议：
- 一律改用
json.loads()处理 JSON 字符串——它只解析标准 JSON，拒绝执行、不支持单引号、不接受尾随逗号 - 若真需表达式求值（如规则引擎），用
ast.literal_eval()替代，它只允许基本字面量（str、int、list、dict等），遇到函数调用或变量名会直接抛ValueError - 绝对不要拼接用户输入进
eval()，哪怕加了白名单过滤——正则绕过、Unicode 归一化、编码混淆都可能击穿
requests.get() 缺少超时参数的后果
默认不设 timeout，请求会无限挂起。线上服务一旦依赖的下游接口卡住或 DNS 解析失败，线程/协程就永远卡死，连接池耗尽，整个服务雪崩。
立即学习“Python免费学习笔记（深入）”；
使用场景：调第三方 API、内部微服务间 HTTP 调用、定时任务里拉取配置文件。
实操建议：
- 必须显式传
timeout，推荐拆成timeout=(3, 7)—— 3 秒连不上就放弃，连上后最多等 7 秒响应 - 别用单个数字如
timeout=10，它只限制总耗时，网络抖动时可能连不上也等满 10 秒，不如分设 connect/read 更可控 - 配合
requests.adapters.HTTPAdapter(pool_connections=10, pool_maxsize=20)控制连接复用，避免短连接风暴
用 == 比较浮点数为什么总出错
因为二进制无法精确表示大多数十进制小数，0.1 + 0.2 == 0.3 返回 False 是确定行为，不是偶然误差。
常见错误现象：金融计算里判断余额是否归零失败；单元测试里断言 result == 0.5 随机失败；循环里用 while x != 1.0: 导致死循环。
实操建议：
- 比较浮点数一律用
math.isclose(a, b, abs_tol=1e-9)，明确容忍范围 - 涉及金额、计数等必须精确的场景，用
decimal.Decimal替代float，初始化时传字符串（Decimal('0.1')），别传 float（Decimal(0.1)已经失真） - 科学计算中若需高性能，可用
numpy.allclose()，但注意它的默认容差比math.isclose()宽得多
全局变量 LOGGING_CONFIG 被多次导入引发的冲突
Python 的模块缓存机制导致 import logging_config 第一次执行时完成日志配置，后续再 import 只是返回缓存模块对象，但若该模块里有顶层代码（比如 logging.basicConfig()），就会在每次导入时重复执行，覆盖已有 handler、重复添加 formatter。
使用场景：Django/Flask 项目里把日志配置抽成独立模块，在 settings.py 和 manage.py 中分别导入；或多个包共用同一份配置模块。
实操建议：
- 把日志配置逻辑封装进函数（如
setup_logging()），模块顶层只定义配置字典，不执行任何logging.*调用 - 在应用启动入口（如
main.py或wsgi.py）中显式调用一次setup_logging() - 避免在
__init__.py或工具函数里隐式触发日志配置，尤其不要在except块里临时调用logging.basicConfig()
真正难处理的是跨进程日志（比如 Celery worker 和主进程共用一个 RotatingFileHandler），这时候文件锁、权限、路径一致性全得手动兜底——多数人根本没意识到这点。
