URL参数编码完全不能防御SQL注入，真正有效的只有参数化查询；它将数据与SQL结构分离，使数据库不解析参数值为语法，ORM也需警惕raw查询、动态字段等绕过场景。
URL参数里拼SQL就是找死
直接说结论：对URL参数做编码/解码本身**完全不能防御SQL注入**。这是个常见误解——把“防止乱码”和“防止注入”混为一谈。URL编码（如 %27 代表单引号）只是让特殊字符能安全传输，服务端一解码，' 还是那个 '，该拼进SQL里执行还是执行。
真正起作用的是参数化查询
所有现代数据库驱动都支持参数占位符，这才是唯一靠谱的防线。它让数据和SQL结构彻底分离，数据库引擎根本不会把参数值当语法解析。
- Python + SQLite：用
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))，别用f"WHERE id = {user_id}" - Node.js + PostgreSQL：用
pool.query("SELECT * FROM users WHERE name = $1", [name])，不是`WHERE name = '${name}'` - Java + JDBC：必须用
PreparedStatement，调setString(1, name)，绝不用Statement拼接
注意：ORM（如Django ORM、Sequelize）默认走参数化，但一旦你写 raw()、extra() 或字符串格式化，防线就破了。
URL编码只在特定环节有用
它唯一该出场的地方，是「把用户输入作为URL的一部分发给第三方服务」时，防止链接被截断或解析错。比如跳转回来源页：redirect_to=/search?q=<code>encodeURIComponent(user_input)。但这和SQL安全无关。
- 错误用法：先
encodeURIComponent()用户输入，再在后端decodeURIComponent()，然后直接拼SQL → 注入照旧 - 正确顺序：URL编码 → 后端解码 → **再丢进参数化查询**
- 浏览器地址栏里看到
%27，不代表后端代码安全；看到干净的中文，也不代表有风险——关键看怎么进数据库
容易被忽略的边界情况
很多团队以为用了ORM就高枕无忧，结果栽在这些地方：
- 动态表名/字段名：参数化不支持，必须白名单校验，比如
if order_by not in ["created_at", "name"]: raise ValueError - IN 子句：不能只传一个参数，得动态生成占位符，如
"WHERE id IN ({','.join(['?'] * len(ids)})"，再展开传参 - JSON字段查询（PostgreSQL）：
data->>'name'里的name如果来自用户，也得白名单控制，不能直接插 - 日志里记录原始参数？没问题；但要是顺手把日志字段又拼进SQL做审计查询……就绕回去了
防御的关键从来不在URL怎么传，而在于数据落地前那一行 execute 怎么写。解码后的字符串，永远要当成不可信输入处理。
