上一章你已经会写最基础的增删改查了。
你现在已经能这样写：
cursor.execute("SELECT * FROM users WHERE id = 1")
也能这样写：
cursor.execute("INSERT INTO users (name, age, city) VALUES ('张三', 18, '北京')")
很多人学到这里，会自然进入下一步：
既然 SQL 语句可以写成字符串，那我是不是可以直接把变量拼进去
比如：
user_id = 3cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
或者：
name = "张三"age = 18city = "北京"cursor.execute(f"""INSERT INTO users (name, age, city)VALUES ('{name}', {age}, '{city}')""")
看起来好像完全能跑。
这恰恰就是很多初学者特别容易掉进去的一个坑：
能跑，不等于应该这么写。
而数据库里，这个坑非常重要。 因为它不只是代码风格问题。 它直接关系到：
安全性 稳定性 可维护性 数据正确性
这一章要讲透的，就是为什么数据库操作里，参数化查询几乎是必须养成的习惯。
一、什么叫参数化查询
先把这个词说得特别直白一点。
参数化查询，就是：
SQL 语句本身先写好结构，真正的值不要直接拼进字符串里，而是作为参数单独传给数据库驱动。
也就是说，你不是这样写：
sql = f"SELECT * FROM users WHERE id = {user_id}"cursor.execute(sql)
而是更像这样写：
sql = "SELECT * FROM users WHERE id = ?"cursor.execute(sql, (user_id,))
这两者表面都在查 id。 但本质完全不同。
第一种是字符串拼接。 第二种是 SQL 结构和参数值分开。
参数化查询的核心，就在这个“分开”。
SQL 负责表达逻辑。 参数负责提供值。
这就是数据库里一个特别基础、但又特别重要的安全边界。
二、为什么很多人一开始都会觉得拼字符串没问题
因为在最简单的练习场景里，它看起来确实能跑。
比如：
name = "张三"cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")
如果 name 就是普通的“张三”，看上去一切都正常。
所以很多人很容易形成一个错觉：
这不就挺方便吗 我变量一塞，SQL 就成了
但问题在于，真实数据从来没那么听话。
变量不是永远都像你想得那么干净。 输入也不是永远都来自你自己手敲。
很多时候它可能来自：
用户输入 表单提交 URL 参数 接口返回 文件内容 外部系统数据 甚至恶意构造的输入
一旦变量内容变复杂，字符串拼接就会迅速暴露出问题。
所以参数化查询的重要性，不是在“最简单场景下看起来更优雅”。 而是在“真实输入条件下更安全、更稳”。
三、最直接的第一个问题：引号一乱，SQL 就容易坏
先不谈什么高大上的安全问题。 就看一个最朴素、最容易踩坑的场景。
假设用户名不是“张三”，而是：
O'Brien
如果你继续用字符串拼接：
name = "O'Brien"sql = f"SELECT * FROM users WHERE name = '{name}'"print(sql)
你会得到：
SELECT * FROM users WHERE name = 'O'Brien'
这里马上就出问题了。
因为 SQL 里字符串本来就是靠单引号包起来的。 而你的值里面又带了一个单引号。 数据库在解析时，很可能会把结构理解错，直接报错。
这就是为什么很多人会遇到一种很烦的情况：
明明 SQL 看着没问题 一换输入内容就炸了
原因往往不是数据库抽风。 而是你把数据和值直接混进 SQL 字符串里了。
而参数化查询会把这个问题处理得自然很多。 因为值是单独传的，不是你自己手搓进 SQL 文本里的。
四、第二个问题更严重：SQL 注入
这就是参数化查询里最经典、也最必须认真理解的风险点。
所谓 SQL 注入，你可以先把它理解成：
用户输入的内容，原本只应该是“数据”， 但因为你用字符串拼接，把它变成了“SQL 语句结构的一部分”。
这就危险了。
比如你本来想查用户名为某个值的用户：
name = input("请输入用户名：")sql = f"SELECT * FROM users WHERE name = '{name}'"cursor.execute(sql)
如果用户正常输入：
张三
当然没问题。
但如果输入的是：
' OR 1=1 --
那拼出来的 SQL 可能会变成：
SELECT * FROM users WHERE name = '' OR 1=1 --'
这意味着什么。
OR 1=1 永远为真。 后面的 -- 在很多 SQL 方言里还是注释符。
结果就是，本来你想查“某个用户名”。 最后可能变成了：
把整张表全查出来。
这就是注入的基本危险逻辑：
输入本来只是值， 结果因为拼接方式错误，被当成了 SQL 逻辑的一部分。
你现在不必把它想成黑客电影场景。 先把最核心的一点记住：
只要你把外部输入直接拼进 SQL，就等于在给 SQL 结构开口子。
参数化查询的意义，很大一部分就是把这个口子堵上。
五、为什么说参数化查询本质上是在给“数据”和“指令”划边界
这一点特别重要。
数据库最怕的不是用户输入了奇怪字符。 而是数据库分不清：
这部分到底是数据 还是 SQL 指令的一部分
字符串拼接会让这条边界变模糊。
而参数化查询做的事恰恰是：
把 SQL 结构固定住。 把用户输入明确当作“值”处理。
比如：
sql = "SELECT * FROM users WHERE name = ?"cursor.execute(sql, (name,))
这里的 ? 是占位符。 数据库驱动会知道：
SQL 模板是固定的 后面的 name 只是一个参数值，不允许它越界去改变 SQL 结构
这就是为什么参数化查询不仅仅是“写法不同”。 它本质上是在建立一条非常关键的安全边界。
六、SQLite 里最常见的占位符，就是问号 ?
这一点你一定要先记牢。
在 Python 的 sqlite3 模块里，最常见的参数化写法是用 ? 作为占位符。Python 官方文档就是这样演示参数占位的：在 SQL 里写 ?，参数作为第二个参数传给 execute()。同时文档明确提醒，不要用 Python 的字符串拼接来组装 SQL，因为这会带来 SQL 注入风险。
最简单的例子：
user_id = 1cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
这里你要看懂两个点。
第一，SQL 里不再直接写具体值，而是写 ?。 第二，真正的值通过第二个参数传进去。
这个第二个参数要注意形式。 它通常是一个元组或序列。
哪怕你只有一个参数，也要写成：
(user_id,)
这个末尾的逗号不能忘。
为什么
因为：
(user_id)
只是普通括号，不是单元素元组。
这个坑新手特别容易踩。 一定要早点记住。
七、最基础的查询，参数化之后应该怎么写
我们先把最常见的查询改造一下。
比如以前你可能写：
user_id = 2cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
更稳的写法应该是：
user_id = 2cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))row = cursor.fetchone()print(row)
再比如查城市：
city = "北京"cursor.execute("SELECT * FROM users WHERE city = ?", (city,))rows = cursor.fetchall()print(rows)
这时候你会发现，代码结构其实并没有更难。 只是把“值”从 SQL 字符串里拆出来了。
但这一拆，安全性和稳定性就立刻提升了很多。
八、插入数据时，更应该立刻养成参数化习惯
查询当然重要，但插入数据时更应该早早改掉拼接习惯。
比如以前可能这样写：
name = "张三"age = 18city = "北京"cursor.execute(f"""INSERT INTO users (name, age, city)VALUES ('{name}', {age}, '{city}')""")
更稳妥的写法是：
name = "张三"age = 18city = "北京"cursor.execute("""INSERT INTO users (name, age, city)VALUES (?, ?, ?)""", (name, age, city))
这里有一个特别重要的习惯：
有几个值，就写几个 ?。 参数顺序要和 SQL 中占位符顺序一致。
这个写法你后面会反复用到。 几乎可以说，数据库项目代码里最常见的插入方式之一就是这个。
九、更新数据时，参数化同样不能少
更新语句特别值得早点养成参数化习惯。
例如把 id 为 1 的用户城市改为杭州：
city = "杭州"user_id = 1cursor.execute("""UPDATE usersSET city = ?WHERE id = ?""", (city, user_id))
你会发现参数化写法在这里特别清楚：
SQL 模板是固定的 新值是 city条件值是 user_id
你后面看这种代码，会明显比拼接字符串更容易读。 因为变量和 SQL 结构的边界非常清楚。
而且更重要的是，风险小很多。
十、删除数据时，也一样要参数化
删除数据时新手有时会偷懒，觉得：
反正就是个 id，直接拼进去不就完了
例如：
user_id = 3cursor.execute(f"DELETE FROM users WHERE id = {user_id}")
从习惯养成角度，更推荐始终统一写成：
user_id = 3cursor.execute("DELETE FROM users WHERE id = ?", (user_id,))
这样做的一个很大好处是：
你的代码风格会非常稳定。
查询是参数化 插入是参数化 更新是参数化 删除也是参数化
这样一来，后面你看到任何带变量的 SQL，都不会下意识回到 f-string 拼接的老路上。
这种统一习惯特别值钱。
十一、参数化查询除了安全，还有一个很现实的好处：省心
这一点很多人一开始没意识到。
他们会觉得参数化查询是不是只是为了防攻击，和我这种小练习没关系。
其实不是。
即使完全不谈攻击场景，参数化查询本身也更省心。
比如你不用自己操心：
字符串里的引号怎么转义 数字要不要加引号 None 怎么处理 特殊字符会不会把 SQL 搞坏
这些问题，数据库驱动会帮你处理很多。
也就是说，参数化查询不只是“更安全”。 很多时候，它还是“更不容易写出一堆奇怪边界 bug”。
所以哪怕你暂时还感觉不到安全风险，光从减少低级错误的角度看，它也很值得。
十二、那 None 怎么办，参数化能处理吗
能，这也是它的一个很实用的点。
比如你想插入一个没有年龄的用户：
name = "李四"age = Nonecity = "上海"cursor.execute("""INSERT INTO users (name, age, city)VALUES (?, ?, ?)""", (name, age, city))
这里的 None，在 SQLite 里通常会对应成 NULL。
这就比你自己拼字符串轻松很多。
因为如果你自己拼，很容易写出一些很别扭的东西，比如：
VALUES ('李四', None, '上海')
这在 SQL 里并不等于你想的那个“空值”。
而参数化方式会帮你更自然地处理这类类型映射。 所以它在真实业务场景里真的很省心。
十三、批量插入时，executemany() 特别好用
这是一个非常实用的干货。
如果你有很多条数据要插入，一条一条手动 execute() 虽然不是不行，但不够顺。
例如有这样一批用户：
users = [ ("张三", 18, "北京"), ("李四", 20, "上海"), ("王五", 22, "深圳")]
可以直接这样写：
cursor.executemany("""INSERT INTO users (name, age, city)VALUES (?, ?, ?)""", users)
然后：
conn.commit()
executemany() 的感觉很像：
同一条 SQL 模板，连续执行很多次，每次带不同参数。
它特别适合：
批量导入 爬虫结果入库 从 CSV/JSON 导入数据库 一次性初始化数据
这个方法你后面会经常用到。 因为真实项目里，批量写入远比一条一条手输更常见。
十四、为什么不建议把表名、字段名也当参数传
这一点要特别说清楚。
参数化查询主要是给“值”准备的。 不是给 SQL 结构里的表名、字段名准备的。
也就是说，下面这种想法是不对的：
table_name = "users"cursor.execute("SELECT * FROM ?", (table_name,))
数据库不会按你想的那样把它当作表名去替换。 因为参数占位符通常针对的是“数据值”，不是 SQL 结构本身。
这一点特别重要。
你可以先记成：
参数化用来传值 不是用来传 SQL 语句结构片段
如果表名、字段名要动态变化，那是另一类问题，需要额外非常谨慎地处理，不能简单套用参数化思路。
这也是为什么我一直强调，参数化查询的本质是：
把结构和数据分开。
如果你连结构本身都拿外部输入乱拼，那风险依然在。
十五、一个特别重要的职业习惯：绝对不要用 f-string 拼外部输入进 SQL
这句话你现在就要记住，而且最好记死。
凡是来自外部的数据，比如：
表单输入 用户输入 接口参数 文件数据 网页采集结果 命令行参数
都不要直接用 f-string 或字符串拼接塞进 SQL。
也就是说，像下面这种：
name = input("请输入用户名：")cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")
要尽快在脑子里自动判定为：
这写法不对。
正确思路应该是：
name = input("请输入用户名：")cursor.execute("SELECT * FROM users WHERE name = ?", (name,))
这个习惯非常值钱。
因为一旦你把它养成默认动作，后面很多安全和稳定性问题都会被你提前避开。
十六、参数化查询怎么和前面学的增删改查串起来
其实特别顺。
查询：
cursor.execute("SELECT * FROM users WHERE city = ?", (city,))
插入：
cursor.execute("INSERT INTO users (name, age, city) VALUES (?, ?, ?)", (name, age, city))
更新：
cursor.execute("UPDATE users SET age = ?, city = ? WHERE id = ?", (age, city, user_id))
删除：
cursor.execute("DELETE FROM users WHERE id = ?", (user_id,))
你会发现，一旦参数化习惯建立起来，整个 CRUD 风格会变得非常统一。
这就是为什么我说它不只是某个安全补丁。 它其实是一种更成熟的数据库写法。
十七、看一个更完整一点的小例子
下面我们用一个完整片段，把参数化查询真正串起来。
import sqlite3conn = sqlite3.connect("demo.db")cursor = conn.cursor()cursor.execute("""CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, age INTEGER, city TEXT)""")conn.commit()cursor.execute("INSERT INTO users (name, age, city) VALUES (?, ?, ?)", ("张三", 18, "北京"))cursor.execute("INSERT INTO users (name, age, city) VALUES (?, ?, ?)", ("李四", 20, "上海"))conn.commit()cursor.execute("SELECT * FROM users WHERE city = ?", ("北京",))rows = cursor.fetchall()print("北京用户：", rows)cursor.execute("UPDATE users SET age = ? WHERE name = ?", (19, "张三"))conn.commit()cursor.execute("SELECT * FROM users WHERE name = ?", ("张三",))print("更新后的张三：", cursor.fetchone())cursor.execute("DELETE FROM users WHERE name = ?", ("李四",))conn.commit()cursor.execute("SELECT * FROM users")print("当前全部用户：", cursor.fetchall())conn.close()
这段代码特别适合作为你脑子里的参数化查询模板。
因为它已经把：
建表 插入 查询 更新 删除
都用参数化方式串起来了。
你后面很多数据库代码，其实都能从这个骨架长出来。
十八、很多人以为参数化查询让代码变复杂了，其实恰恰相反
表面上看，好像以前一行 f-string 就写完了。 现在还要加 ?，还要传元组，似乎麻烦了一点。
但如果你真正做项目，很快就会发现：
参数化查询让代码更稳 更容易维护 更不容易出奇怪 bug 更适合真实输入 也更符合团队协作习惯
尤其当你的 SQL 稍微变复杂一点时，参数化写法反而更清楚。
比如：
cursor.execute("""SELECT * FROM usersWHERE city = ? AND age > ?ORDER BY age DESC""", ("北京", 18))
这比你自己用拼接一段段凑起来，要清晰得多。
所以你现在不要只看“是不是多打几个字符”。 要看：
这是不是更适合长期写、长期改、长期维护。
从这个角度，参数化查询几乎是更优解。
十九、这一章最容易踩的几个坑
第一个坑，是单参数时忘了写单元素元组的逗号。
比如错写成：
(user_id)
而不是：
(user_id,)
第二个坑，是把参数顺序写错。
例如 SQL 里先是 name, age, city，结果你传成了 (city, name, age)，那数据就会乱掉。
第三个坑，是误以为参数化可以替代一切字符串拼接。
不是。 它主要是安全地传值，不是让你把表名、字段名也随便当参数传。
第四个坑，是以为小项目就不用在意参数化。
这其实是个特别危险的想法。 越小的时候，越应该把习惯养对。
第五个坑，是改成参数化之后，commit() 反而忘了。
要记住，参数化和提交是两回事。 安全传值不等于自动保存修改。
二十、这一章真正要带走的，不只是语法，而是一条底线
到这里，你应该把这条底线真正立起来了：
SQL 结构和外部输入，必须尽量分开。
不要把用户输入直接拼进 SQL。 不要把爬虫采集结果直接拼进 SQL。 不要把表单值直接拼进 SQL。
只要是“值”，优先考虑参数化。
这不只是某种高级安全技巧。 它应该成为你从这一章开始就默认使用的数据库习惯。
当这个习惯真正建立起来，后面你写数据库代码时，很多问题都会自然少很多。
本章小结
参数化查询的核心，不只是“写法不一样”。 它真正解决的是：
把 SQL 结构和参数值分开，避免字符串拼接带来的安全风险、引号问题、类型处理问题和维护成本。
在 Python 操作 SQLite 时，最常见的参数化方式是使用 ? 作为占位符，然后把参数作为第二个参数传给 execute() 或 executemany()。Python 官方文档明确建议，不要用 Python 字符串拼接来构造 SQL，因为这会带来 SQL 注入风险。
这一章你最应该真正养成的习惯是：
查询时用参数化 插入时用参数化 更新时用参数化 删除时也用参数化
也就是说，参数化不应该是“等以后再优化”的额外步骤。 它从一开始就应该成为你写数据库代码的默认方式。
当你把这个习惯养稳之后，数据库这条线就开始真正从“能跑”走向“更像正式项目代码”了。
