f-string直接拼接用户输入构造SQL存在严重SQL注入风险，如f"SELECT * FROM users WHERE name = '{user_input}'"中，若user_input为' OR '1'='1，将导致查询逻辑被篡改；安全做法是分离SQL结构与数据，仅对白名单内的表名、字段名等可控内容使用f-string，其余参数必须通过数据库驱动绑定传入。
f-string 生成 SQL 查询时的变量注入风险
直接用 f-string 拼接用户输入进 SQL 语句，等于把数据库大门敞开——SyntaxError 还算轻的，sqlalchemy.exc.ProgrammingError 或更糟的 SQL 注入才是真实威胁。比如 f"SELECT * FROM users WHERE name = '{user_input}'"，一旦 user_input 是 "' OR '1'='1"，整条查询就失控了。
真正安全的动态查询，必须分离「结构」和「数据」：SQL 模板用字符串字面量写死（或从配置读），参数通过驱动层绑定传入。f-string 只该用于拼接**完全可控的、非用户来源的**部分，比如表名、字段名（前提是这些名来自白名单或硬编码枚举）。
- ✅ 允许：
f"SELECT {col} FROM {table_name}"，其中table_name来自["users", "orders"]这类有限集合 - ❌ 禁止：
f"SELECT * FROM users WHERE id = {user_id}"，哪怕user_id看似是数字——它可能被构造为1; DROP TABLE users; - ⚠️ 注意：
str.format()或%格式化同样不解决注入问题，只是换种写法而已
为什么 f-string 在构建日志/调试语句时是首选
日志和调试输出不需要防注入，但极度依赖可读性和性能。f-string 在这类场景下优势明显：表达式实时求值、无额外函数调用开销、变量名与上下文对齐直观。
比如调试一个 API 响应：f"[DEBUG] status={resp.status_code}, body_len={len(resp.text)}, elapsed={resp.elapsed.total_seconds():.3f}s" —— 所有值在打印瞬间计算，不用提前赋值，也不用记住占位符顺序。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 性能关键点：在高频日志（如每秒千次）中，
f-string比str.format()快约 20%，因为编译期已拆解为字节码指令 - 可读性关键点：看到
{resp.status_code}就知道取的是响应状态，不用翻到参数列表去核对第几个参数对应什么 - 陷阱提醒：别在 f-string 里塞耗时操作，比如
{requests.get(url).json()}——这会拖慢日志输出，且失败时整个日志语句崩溃
f-string 处理日期、数值格式化的实际约束
动态查询中的时间范围或金额条件常需格式化，f-string 支持内建格式说明符，但必须清楚边界：它只做字符串转换，不改变底层数据类型或精度。
例如生成时间条件：f"created_at >= '{start_time:%Y-%m-%d %H:%M:%S}'"。这里 start_time 必须是 datetime 对象，且 %Y-%m-%d %H:%M:%S 是其 __format__ 方法支持的 strftime 格式串。
- 浮点数陷阱：
f"price = {amount:.2f}"看似精确，但若amount是0.1 + 0.2，结果仍是"0.30"（四舍五入掩盖了0.30000000000000004），金融场景务必用Decimal - 整数补零：
f"user_id = {uid:06d}"安全，但uid若为None会抛TypeError，得先确保类型正确 - JSON 字段名含花括号？用双大括号转义：
f'{{"id": {uid}, "name": "{name}"}}'
多行 f-string 拼接查询模板的缩进坑
写长 SQL 模板时，有人试图用括号跨行：f"""SELECT {cols} FROM {table} WHERE ..."""，结果发现生成的 SQL 里多了大量空格和换行，数据库直接报错。
根本原因：f-string 中的换行符和缩进空格会被原样保留。括号续行不等于自动去除空白。
- 安全做法：用
textwrap.dedent()清理前导空白，再套 f-string：f"{textwrap.dedent(sql_template).strip()}" - 更推荐：拆成多个短 f-string 拼接，或用
join()组合列表（尤其当字段名来自变量时）："SELECT " + ", ".join(f"{col} AS {alias}" for col, alias in zip(cols, aliases)) + f" FROM {table}" - 绝对避免：在 f-string 内部手动加
\续行——可读性差，且容易漏掉末尾空格
真正难的不是写对一行 f-string，而是判断哪部分该让它动态，哪部分必须交给参数绑定，哪部分干脆不该用字符串拼接——边界模糊的地方，往往就是 bug 和漏洞藏身之处。
